I'm sure there is something that I'm missing but I'm blind at the moment. Using the Arduino mega, I have built an autonomous robot that I would like to record the steps that it has taken. So in other words, my question really is, how can I record the amount of time and actual duration that the wheels moved for a certain period of time. I'm a programmer by trade and the technique that I'm sort of trying to accomplish is more like a macro. So I would use a remote control to maneuvers a robot through a given path but while I'm moving I would like the robot to record every single step that it has taken so that I can place it on the same start location and it would perform the same steps.
What methodology/recording would I go about doing that? I've been racking my brain on this one and it seems like google does not have anything to offer or I'm just too dumb to ask the right question.
I believe you would use an encoder or a sensor for rotations then multiply circumference of your tire. You have mentioned "steps" and "wheels". How does your robot move?
The robot has four wheels and as of this moment I have encoders and I preprogrammed it to be controlled with a remote control. What I would love to do "record"(for the lack of a better term) every move that I have made the robot do. In other words, if the robot moves 5 feet forward at a given speed I would like to know that so that I can then have it repeat the steps, without me controlling it using a remote control.
bump. just wondering if anyone else can offer a tip on this subject.
Read the wheel encoders and store the positions at regular intervals.
jremington:
Read the wheel encoders and store the positions at regular intervals.
AHHH! yes, that is a great idea. I guess I'm too close to the problem, that just was not coming to me.
Thanks a ton jremington
The recording's the easy part I think. All very well to know that at time t you had encoder values a & b, but how will you drive the motors to ensure you reproduce those come playback time?
ardy_guy:
The recording's the easy part I think. All very well to know that at time t you had encoder values a & b, but how will you drive the motors to ensure you reproduce those come playback time?
umm, good point, I'm not too familiar with wheel encoders yet, but I would imagine that using wheel encoders I can record the speed at which the wheels are moving?... Again I'm making an assumption, however, I'm all ears. My end goal would be to basically pass the "path" (route) as a function to the autonomous robot and therefore it would travel the path in the same exact manner it did when I recorded it?...
It will be almost impossible to "travel the path in the same exact manner it did when I recorded it" because the wheels slip, batteries discharge, things go bump in the night, etc.
The most general approach is to navigate between known points, which also requires you to have a pretty good idea where the vehicle is at any time. It is not a simple problem!
One place to start reading about odometry using wheel encoders is here: A Tutorial and Elementary Trajectory Model for The Differential Steering System
Could something like Electronic Compass Module Three Axis Magneto Resistive Sensor help correct turns and wheel slippage?
Forgot to link the datasheet too.
Magnetometers often aren't very useful on small robots, because magnetic fields from metal braces, wiring and the motors add to the Earth's magnetic field in unpredictable ways.
The rate gyros in standard IMUs can help make accurate turns, but they drift and have to be frequently reset.
Thank you guys it looks like I still have a whole lot more to consider. I was hoping there was a process in which this could be accomplished if followed. JREMINGTON, thanks for that link I have some homework todo.
Thanks
Again
miguel83:
I would imagine that using wheel encoders I can record the speed at which the wheels are moving?...
Yeah but you need to know how you got to that speed. You can't get to time t and look up the speed you should be at, because it's too late to adjust it at that time.
So you would also perhaps need to record "throttle settings" so to speak, and playback the analogWrite()s to the motors since some epoch, at which epoch you were deemed to be at position (0,0) pointing in the right direction.
But then, as pointed out, with a battery being more or less charged than before an analogWrite() won't give the exact same wheel speed. Even if it did, a bit of wheelspin....
Not to gainsay your project by the way: I think it's an important and interesting piece. It's just not as easy as it might first seem. Idea for my weekend project.... resurrect my tracked robot, hardcode some random analogWrite()s and delay()s, and see how close it gets to the first endpoint on subsequent runs.
I promise I am not trying to confuse things 
. Just asking for my own clarification.
Why do we need speed?
If you are just trying to get it to go say 10 ft forward, then turn left, and go another 2 feet. You could do it by distance per time (which is why I think you guys are talking about speed - not sure)
Would it not be easier to do it wheel rotations multiplied by wheel circumference?
So instead of saying it went 2mph for 3.5 secs then it turns left and goes 3mph for .75secs...
It would be a wheel with a circumference of 1' rotates 10.0 times then robot turns left and rotates 2 more.
birddog:
Why do we need speed?
Depends on your objective I guess: if you want to model the trip completely, you might want (as distinct from need) to have it running at the same speed at the same point in space and time.
But even without speed, your method might not be up to the job, since slippage will come into play, and 10 rotations today might not be the same distance traveled in 10 rotations tomorrow. That will be especially important if there's differential steering involved, where a slippage on one side but not the other will also throw direction not just distance.
It's worthy of investigation though. If I can find my Pololu Zuma I might do some playing this weekend. It doesn't have encoders (I know some do; mine doesn't) so I'll experiment with analogWrite()s and time.
Sorry did not mean to hijack the thread, but I was thinking of this project as well as a stepping stone to something bigger down the line.
ardy_guy:
But even without speed, your method might not be up to the job, since slippage will come into play, and 10 rotations today might not be the same distance traveled in 10 rotations tomorrow. That will be especially important if there's differential steering involved, where a slippage on one side but not the other will also throw direction not just distance.
Yea, I was thinking using circumference multiplied by rotations for the forward and reverse only, while using ...
Electronic Compass Module Three Axis Magneto Resistive Sensor
For turning initially, until jremington corrected me with a better idea...
jremington:
Magnetometers often aren't very useful on small robots, because magnetic fields from metal braces, wiring and the motors add to the Earth's magnetic field in unpredictable ways.The rate gyros in standard IMUs can help make accurate turns, but they drift and have to be frequently reset.
What are you thoughts. I expect that "calibration spots" would need to be well placed like finding a corner of a wall upon room entry or something to occasionally correct any error tolerances.
miguel83, I do not mean to take over your thread. Tell me to shut-up and I will.
Bird dog great questions! The beauty about your questions is that I'm also learning so please ask away, Those would have been my follow-up questions. At the moment I'm trying to get the PID algorithm figured out myself. It is a bit difficult for the sheer reason that I have no idea how to adjust the speed on the wheels based on PID. I'm also trying to figure out to turn right just enough that is not more than 180 degrees. I have a long road ahead of me but a rewarding one I'm sure.
I have no idea how to adjust the speed on the wheels based on PID
The PID output is used as the PWM value (analogWrite()) to control the wheel speed.
The critical step to make this work is the proper selection of the values for Kp, Ki and Kd in the PID algorithm. Read up on "PID tuning".
@JREMINGTON
Thanks, here is another question that is perplexing my mind now that I'm working on PID. I have 4 wheel robot, with 4 encoders, but my motor controller only has two inputs. In other words, I can only move the 2 left wheels or the 2 right wheels at once. So two questions. Are there any motor controllers that have 4 inputs?(so I can control each wheel independently) are they worth it? it would seem to make PID a whole lot more complicated. Secondly, which encoders should I be reading? I have 2 wheels on the left side of the robot, 2 wheels on the right side of the robot. Which ones do I read the encoders value? It would seem dumb to read all 4 encoders since the motor controller is sending current to two wheels at a time.
Sorry, If I just sound more and more confused but this small project is turning to be a bit more onerous that I imagined, yet I just can't let go.