Motor Control for Dummies
This is the second of the posts I mentioned before, please forgive the pictures- I drew it myself =(
The rats life ePuck robots, even though they are simulated, are controlled just like real robots in real life, so we have to control each wheel individually rather than give commands like moveForwardOneBlock. So a very simple intro to motor control: (I think it should be self explanatory, forward & reverse mean power given to the wheels)
(more post after the picture)
Ofcourse the robot is a *little* more complicated than that, such that you can adjust the speed and that you have wheel encoders measuring the position of wheels. The picture below contains the sensor data, the speed/power given to each wheel are the two red numbers in the middle, (ignore all the numbers on the side, they are the IR based distance sensors). The sample code seems to imply that the maximum speed is 300 but I have been unable to find the exact value in the reference material, and it is unclear elsewhere as i've seen references to a speed of 1000. In practice the battery level which is supposed to be linked to the motor speed doesn't seem to decrease any faster at 1000 but the robot *does* travel faster. This is a bug I think, or at least it is one on client side (there was talk of the competition environment locking certain variables..).
(wheel encoders and slippage is after the pic, keep reading)
The green number beneath the red ones is the wheel encoder data. It measures how far forward or back the wheel has gone since it started (or when you last told it to reset). This is very useful if we were to use the dead reckoning method, especially since the manual claimed that the wheels don't slip. However in practice I have found that applying a power of 300 until the encoder reaches 1000 on each wheel, will leave the robot in a different place when nothing was blocking it compared to when something blocked it temporarily. This implies that slippage is there to some extent, and thus makes relying on the encoders harder if you try to use dead reckoning.
(Note: can be solved with obstacle detection but still..).
Also, forgot to mention in the last post that I had chosen to continue with the grid/square-movement method as opposed to fluid with dead reckoning. This discovery with slippage further supported that choice.
Mapping: Still has problems, hopefully will be fixed by later in the week and I will have a nice video to show you!
Update: Apparently a book titled 'Braitenberg vehicles' is a must-read with reference to this stuff, although the closest I could find is this, the quicker explanation is at wiki: http://en.wikipedia.org/wiki/Braitenberg_vehicles
The rats life ePuck robots, even though they are simulated, are controlled just like real robots in real life, so we have to control each wheel individually rather than give commands like moveForwardOneBlock. So a very simple intro to motor control: (I think it should be self explanatory, forward & reverse mean power given to the wheels)
(more post after the picture)
Ofcourse the robot is a *little* more complicated than that, such that you can adjust the speed and that you have wheel encoders measuring the position of wheels. The picture below contains the sensor data, the speed/power given to each wheel are the two red numbers in the middle, (ignore all the numbers on the side, they are the IR based distance sensors). The sample code seems to imply that the maximum speed is 300 but I have been unable to find the exact value in the reference material, and it is unclear elsewhere as i've seen references to a speed of 1000. In practice the battery level which is supposed to be linked to the motor speed doesn't seem to decrease any faster at 1000 but the robot *does* travel faster. This is a bug I think, or at least it is one on client side (there was talk of the competition environment locking certain variables..).
(wheel encoders and slippage is after the pic, keep reading)
The green number beneath the red ones is the wheel encoder data. It measures how far forward or back the wheel has gone since it started (or when you last told it to reset). This is very useful if we were to use the dead reckoning method, especially since the manual claimed that the wheels don't slip. However in practice I have found that applying a power of 300 until the encoder reaches 1000 on each wheel, will leave the robot in a different place when nothing was blocking it compared to when something blocked it temporarily. This implies that slippage is there to some extent, and thus makes relying on the encoders harder if you try to use dead reckoning.
(Note: can be solved with obstacle detection but still..).
Also, forgot to mention in the last post that I had chosen to continue with the grid/square-movement method as opposed to fluid with dead reckoning. This discovery with slippage further supported that choice.
Mapping: Still has problems, hopefully will be fixed by later in the week and I will have a nice video to show you!
Update: Apparently a book titled 'Braitenberg vehicles' is a must-read with reference to this stuff, although the closest I could find is this, the quicker explanation is at wiki: http://en.wikipedia.org/wiki/Braitenberg_vehicles
posted by thavidu at
11:57 AM
0 Comments:
Post a Comment
<< Home