Turning Accuracy

[nxtdoug]

Hello,

I'd like to create a "My Block" for turning accurately (pivoting in place with one motor going the reverse of the other). I've determined the number of degrees that one must use to make a 360 degree pivot in place. The problem is that I get inconsistent results.

My first attempt was to use a Move block with the slider all the way to one side. The robot will not pivot a consistent amount though (and the wheels are not slipping). Next I added [NXT-G] code to read how far each rotation sensor has rotated during a pivot and display the result on the screen. When doing this, motor B always rotates the prescribed amount (+/- 1 degree), but motor C will rotate more than the prescribed amount, sometimes significantly more (in the opposite direction of course). When the robot is not under load (when I hold it in my hand and run the program) both encoders will typically come up with the correct answer. It was my understanding that the Move block syncs motor B and C such that they will move exactly the same amount - so what is the deal?

The next thing I tried was to use separate motor blocks for motors B and C. When I started them in serial I get the same lousy results. When I start them on parallel sequence beams AND I also put a short delay after the completion of the action such that both motors have the chance to complete their rotations, then I finally get both motors to rotate the prescribed amount. The problem here is that motors B and C are no longer synced, and depending on the actual motor, one can take longer to rotate than the other and consequently, the robot will not be in the same position after the rotation.

So my question is "what is the move block actually doing?" It doesn't seem to sync the motors in this case. Is there a way using NXT-G to make a more accurate turn?

Thanks
-Doug

[hassenplug]

I would suggest you try with the move block, the same thing you did with the motor blocks. After the move block, put a delay for some time (like 1 second). Make sure the block is set to "Brake".

You should see that after motor B & C reach the desired location, the momentum of the robot may cause C to drive farther. With the delay, the motor will move back to the desired location, but only if the program is not trying to do something else.

Steve

[nxtdoug]

Steve,

thanks for the suggestion. I tried that and a number of other things and nothing seems to change that behavior. If I write a "0" to the steering data port, then the motors B and C stay synced whether there is a load or not. However, when I write a "-100" or "+100" to the data port, only motors B or C respectively go the prescribed rotation while the other motor is way off, obviously not sync'ec. I've tried delays and delay/stop blocks, reseting the motors etc and nothing seems to keep the motors sync'ed. At this point I've given up - it seems the only way do a turn accurately is with motor blocks.

-Doug

[HaWe]

to my observation, no firmware function and no customized or API function (based just on encoder data like, e.g., motor blocks) is or was ever able to make a vehicle turn exactly/accurately.
The only thing that really helped for accurate turning was using additional sensors like Gyro or Compass sensors - or, best of all, both of them combined with odometry data by a statistical - or - even better - by a stochastical filter (plus adding an additional acceleometer for going straight and for slip detection).

The method is well-known among roboticists as "sensor fusioning".
The following (a very simple statistical method) was an approach I did some years ago:

http://www.mindstormsforum.de/viewtopic.php?f=70&t=6746

(Navigation, localization and particularly dead reckoning is one of the most challenging issues of robotics, because they need incredible accurate data which can not be provided by individual sensor measurements, e.g. like odometric encoder data, and so one has to move on the "black ice" of probability, plausibility, coincidence, statistics, and stochastics !)

Maybe you wish to google keywords like
odometry
sensor fusion
dead reckoning
Kalman Filter
Particle Filter
(Sequential) Monte Carlo Filter

if you want to have a look at what motor synchronization, odometry, and stochastical filters are able to to (and what they can't achieve) maybe look at this:

http://web.archive.org/web/200808040230 ... wyeth/NXT/
no filter: http://web.archive.org/web/200808040230 ... filter.wmv
with filter: http://web.archive.org/web/200808040230 ... filter.wmv

if you want to have a look how commercial companies are approaching this problem, maybe you wish to read this (using 2 Kalman Filters):

Improvement of Dead Reckoning Accuracy of a Mobile Robot by Slip Detection and Compensation using Multiple Model Approach.pdf

(684.07 KiB) Downloaded 475 times

[circuitmage]

Don't give up!

There are several ways to tackle this problem. It is good to learn the things you have, even as limitations.

In addition to the suggestions above, there may be other things you can do. It is a good idea to use other sensors to verify rotation or limits. Another idea is to set up "stops" (depending on your application) so that you can only rotate so far or know where you are as it rotates (like the old wheel encoder trick).

You may have it in your head that it "should" work a certain way, but that does not mean it will. It usually needs a bit of tweaking to get where you want to be.

Also, imagine a "perfect" world where this is possible. Do you really want your world to be based on such assumptions? Imagine a world full of robots that all work perfectly, and move as expected, then one day something happens that throws them off by 0.0001 degree. The last thing we need is a world full of robots that are slightly off! So, improving the system is a better approach than expecting things to work. It would make things easier to have motors that behaved perfectly, but it is better to have a system that ensures things are moving the way they should.

I've had too much coffee this morning, or not enough.