Hello everybody! Here is my first robot. It is so sweet:) I love it! :) At the moment it is not autonomous, but in the future it should be. It was not so easy to fit all the components into this little chassis, that’s why there are so many cables and wires. Actually in my plans was to attach ipcam on it, but now there are no place for the cam. Maybe I will build one floor more, or some how else fit the cam on it. Like you saw on the video I`am controlling the robot via Xbee, but in the future I will control it thru the internet(ethernet shield). Adaptive mapping is all so very interesting..:) So the hardware is done and now is start for software:) More pictures you can see here: http://www.instantgallery.de/i/mtik3j/20046216
Update 28.02.2012
Hello everybody, I have a little problem with my robot. The problem is that it doesn't goes straight forward. Sometimes it change direction by it self.. I wrote the code that I’m using and I shoot a video how it looks like in reality. Maybe someone has a better solution(code) how to get it working. My encoder wheel has 12 counts for one rotation, so every 30 degrees comes a count. Thank you very much!
Update 08.03.2012
First try that the watcher drives alone:) It was more front sensors test than autonomous driving:)
Hi this is a very good begin! But, i dont understand one thing, what’s the function of all those sonar? and sorry for my english, i naturaly speak spanish
at the values that L_forward_esc_counter and R_forward_esc_counter contain? It may be that your information is either bad or wrong, thereby causing your robot to arc rather than travel in a straight line.
The other bit I notice is that you are using numbers that are set in stone rather than using the encoders to adjust the speed of the motors.
I would suggest:
void forwardesc() { if(L_forward_esc_counter == R_forward_esc_counter) { //If the left and right wheels has the same counts forward(); //We go forward with both wheels } else if(L_forward_esc_counter > R_forward_esc_counter) { // If left wheel has more turns then the right analogWrite (MOTORAF, (speedo * R_forward_esc_counter / L_forward_esc_counter)); //Slow down left wheel digitalWrite(MOTORAB, LOW); analogWrite (MOTORBF, speedo); //Move right wheel at commanded speed digitalWrite(MOTORBB, LOW); } else { //else if right wheel has more turns then the left analogWrite (MOTORBF, (speedo * L_forward_esc_counter / R_forward_esc_counter)); //Slow down right wheel digitalWrite(MOTORBB, LOW); analogWrite (MOTORAF, speedo); //Move left wheel at commanded speed digitalWrite(MOTORAB, LOW); } }
**My notes/chicken scratch on figuring this out:
If the left motor is moving at the commanded speed, then the right motor needs to be increased. If the right motor can not move any faster, then full speed must be limited to the speed at which the right motor can move.
150L 100R // These are the encoder counts that are read. and the left wheel is turning faster speedo * 100 / 150
there are always different 1-2 counts between left and right
Thanks for your replay! I have tried the code below, but it doesn’t work better. My code (forwardesc) actually works better. I think speed up on the other side must be. There are reason for that:
150L and 100 R this different between wheels can not be, because if different 8 counts, the robot turns 90 degrees left or right. So when it goes straight forward there are always different 1-2 counts between left and right.
Example:
So 102L and 100R. //Right wheel has more counts, so we must turn right. To turn right we need to slow down right wheel
Speedo = 150.
So = speedo * R / L
150 * 100 / 102 = 147;
analogWrite (MOTORBF, 147); //Move right wheel at new speed
analogWrite (MOTORAF, speedo); //Move left wheel at commanded speed
Now you see the different between speedo and right wheel is only 3. And this is not enough, maybe it will work if robot will drive forward couple hundred meters, but not 1-2 meters.
I believe my thinking is correct, still. Is there any chance you can put higher resolution encoders on your wheels? If they are just printed sheets, there are ways that you can get higher count encoder wheels as an image that you can then cut out after you print them. My thinking is that maybe(?) your encoders are too coarse to get a good read on how far the wheels are off and therefore you can only get close with driving the robot straight.
I am only shooting in the dark here. I have no practical experience.
Yes, I will cut new encoders wheels. Old encoder wheel has 12 counts for 360 degrees. And new encoders will have 16 counts for 360 degrees. But I think it will be still not enough… I made now a new calculation - speed. So now when the robot goes forward I know the speed. Minimum speed about 10cm/sec. and maximum speed is about 145cm/sec. I think this data is more important then speedo. What you think?
