I have a Duemilanove and a Motor Shield for a robot project. It'll have 2 DC motors and 2 sensors (in which I have yet to decide whether it'll be infrared or ultrasonic).
The route the robot take is as follow;
The (relative) positioning of the sensors and motors are as follow;
*Sensor 2 is FRONT end, motors REAR end.
The robot will start from the start point (deliberately angled from the start) , travel to point A and turn away from the edge as detected by the sensor.
It'll travel to point B, stop for a few seconds, before reversing to point C.
Then, it'll make a 135-degree (or approx.) and continue on straight to point D. The sensors will detect the edge, turn and continue to the end point before stopping indefinitely.
I just want to check whether this is the correct pseudo code for the above mentioned task.
- Full power from motors A and B
- Sensor 1 detects edge, motor B zero power. (This should ensure the robot to make a tight turn, yes?)
- Sensor 1 re-detects surface, both motors A and B back to full power
- Sensor 2 detects edge at point B, zero power to motor A and B for a few seconds (using the 'pause' function), for the robot to stop
- Motors A and B reverse direction to point C
- (I'll guess this needs to be timed) Motor A zero power, Motor B maintains full power.
- Back to full power for both motors to continue to point D
- Sensor 1 detects edge, motor A zero power. (To make the robot turn)
- Sensor 1 re-detects surface, both motors maximum power
- Sensor 2 detects edge, whole system switches off for good
I would prefer to 'program' it in such a way that it's all one-way traffic. No loops, or that kind.
Another thing, can the memory of the chip store this much of information?
(I'll guess this needs to be timed) Motor A zero power, Motor B maintains full power.
There's a period at the end of that sentence, but not on any of the other lines in the list. Any decent pseudo-code compiler will generate an error for that.
can the memory of the chip store this much of information?
No problem, there is plenty of memory for code and static data. Only the variable space is a bit small, but you won't need much of it.
A complete and clear problem description (for a change) that's good.
I see no "error" in the pseudocode, but I think you have made a number of assumptions that may not be true. I have interpreted your sensors as detecting edge of table or such like, to make sense of the wording "detects edge" ... "redetects surface".
Step 3 - I think your vehicle will turn too much before sensor 1 is "above" the table again.
Step 4 - there is no need to pause, unless you want to. Just switch to full reverse at once.
Step 5 - you need a timing here, too (or where you going to measure the distance travelled from point B to C and just do the same?)
Step 9 - same as 3
Your "no loops" requirement is a bit hard, how else to implement "keep running until " constructs? Each step would have to be like :
/* Step 1 */
digitalWrite( turning motors on) ;
/* Step 2 */
while (digitalRead(sensor) /* do nothing in this loop - we're running fine */ ;
digitalWrite ( turn one Motor off ) ;
So you enter a small dummy loop for each step in your pseudeocode, while waiting for the expected sensor change to happen. (Your desired 130 degree turn would use a
delay(nn) instead of the
This way of doing it your main program will only need to run once. You should put it all in the
void setup() part of your sketch, and leave
void loop() empty. Unusual, but workable.
Step 3 - I think your vehicle will turn too much before sensor 1 is "above" the table again.
I'll try to keep that in mind. But I've tried with a simple test rig (no motors, sensors etc. just two independent tires) and it could make the turn.
Theoretically, if the inner tire (to the direction of turn) is to be stationary, and the outer tire to keep on moving, it should be able to turn on a dime, right?
Then again, I'll still double check just in case I've missed out on something.
Step 4 - there is no need to pause, unless you want to. Just switch to full reverse at once
It's not a hobby project, it more of an assignment. The robot does need to pause at that point. Apologies for leaving that bit out.
The reason I don't like loops is I am not too familiar with them, and since there is not many 'tasks' I wouldn't mind writing each task line-by-line.
I have never worked with C or C++, only MATLAB. This is my very first time seeing C++. How far is it with the programming language of MATLAB?
How far is it with the programming language of MATLAB?
I dont know MATLAB so I cant say. The basic develoipment software you have has plenty of examples - just look at them and you get an idea of the syntax.
Okay, I have simplified the route for the robot, it'll be something like this;
The robot will move from the start point (point A), travel to point B and back to point A.
Linear motion, that's all. No turning of the motors.
The sensors would be in the same position, 1 at the front, 1 at the end.
The new pseudo code would be as follows;
- Motors move forward to point A
- Front sensor detects edge
- Motor reverse back to point B
- Rear sensor detects edge, stop
The sensors I'll be using are the Sharp IR Sensors (4-30cm). What I plan to do is take the readings from the sensor, and as soon as it passes a certain value (reaches the edge), the motor will pause.
I am yet to decide whether to use logical operators or IF loop. My main issue here would be;
- Programming (zero knowledge of C++, but I can still learn!)
- The sensor reading might clash within the code itself.
At the starting point, sensors A and B would read high, motor would move forward. At point A, sensor A would read low, and the motor would stop.
When it wants to reverse, both sensor A and B reads high. BUT, I fear that the there would be a conflict of coding, since initially, when both sensor A and B read high, the motor will move forward.
I appreciate any form of help and guidance here.
This post is intended as a "searching" or "roving" functionality. It is what I used as a basis to create a "Sumo Robot". I see that you have already worked out you "static" functionality
Also, an LDR can make a cheap alternative to find a different surface under your robot[/edit]
If you detect a front left line sensor, you should stop, back up, turn right, and then continue forward.
Just turning right might lead to your left wheel going off the table (think about when the angle is close to 90deg with the end of the table). Also, if you don't back up, you may end up with your sensor going past the white line, robot thinks it's fine and keeps going forward (fail).
Noted. And by 'Sumo Robot' do you mean this?
Gotta love Stampy! Yes that is it!
For one of my subjects at Uni, we had a 3 round tournament which included:- (Qualifying) finding a box in an "arena" and pushing it out
- (Qualifying) a defensive mode, where it had to evade that same box chasing it around on a bit of string
- and then the tournament where you needed to push the other robot out of the ring
Restrictions where 1000g (2.2lb?) and AU$160. You couldn't use kits either (well sort of: You could get a motor and gearbox kit).
It's in bits and pieces now.
Interesting unit in your uni!
And I never knew Stampy was that famous.
I created the following basic pseudo code with MATLAB.
sensor_read=input('Enter sensor reading:');
disp('Motor full power')
This is as basic as I can think at the moment. The input (sensor_read) are those numerical values that come off from the sensors.
It goes through the IF statements, and fall accordingly.
Hopefully I'm going in the right direction with that code.
What's going to happen when sensor_read == 200?
Whoops. My bad.
A reading of sensor_read == 200 should ensure that the motor still moves.
I've found the code for 'Stampy' adapted for the Arduino board.
* Copyright (c) 2009 Jeff Florek <email@example.com *
* Based off of code found at http://www.societyofrobots.com/ *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License version 2 as *
* published by the Free Software Foundation. *
* Alternatively, this software may be distributed under the terms of BSD *
* license. *
* $50 Robot with Arduino MCU and Sharp IR using Stampy Technology, *
* May 2nd, 2009 *
* Simple case-based method for a robot to do edge detection. *
int distance = 0; //holds value from IR scanner
int scan_threshold = 0; //threshold for detecting an object
int scan_angle = 90; //angle that the scanning servo is at
int led_pin = 13; //pin that status LED is connnected to
int scanner_pin = 0;
//scans for target
distance = analogRead(scanner_pin);
if(distance > scan_threshold) //object detected
if(scan_angle > 0) //overflow protection
scan_angle -= 1; //turn scanner left
else //no object detected
if(scan_angle < 180) //overflow protection
scan_angle += 1; //turn right
scanner.write(scan_angle); //set servo angle to scan_angle
void auto_calibrate() //automatically find the target sensing threshold
scan_threshold = analogRead(scanner_pin);
//Turn LED on to signal autocalibration,
//wait 2 seconds, autocalibrate, then turn LED off
//if object detected on left, turn left
if(scan_angle <= 50)
//if object detected on right, turn right
else if(scan_angle >= 130)
//object is centered, go strait
delay(15); //small delay to prevent crazy oscillations
Would there be any difference if there was a motor shield attached to the Arduino?
Sorry about the late reply.
Although you might not get too much of an issue with that code, I did have quite a lot of trouble with the sensor inputs.
Basically, your analogue input is going to be the correct value +/- a random value (noise). There was a few ways in which people got around this: 2 that comes to mind are:
- Take 10 (or more) samples and take the average. (Or just make your threshold 10 times bigger)
- Or what I did was have a variable that incremented every time the sensor value was above threshold value (until it got to 10), and decremented when it was below (until it got to 0). When ever the variable was above 5, it was considered on, and when it was below, it was considered off.
My advice is to NOT overlook this problem.