Driving Straight with a Dual Differential Drive

Martin_H

Driving straight is the bane of all open loop differential drive robots (eg BOEbot, Scribbler 1, and Stingray). Up to now I thought either wheel encoders or a synchro-drive were the only fix. While I think encoders are probably still the best solution, they do consume I/O pins and require software to monitor them. But I recently saw another solution which works, requires no wheel encoders and is mechanically much simpler than a synchro-drive.

It's called a Dual Differential drive and uses two differential gears as a mechanical mixer for the output of two motors. One motor becomes the forward back motor, while the second becomes the rotation motor. The motors can be used alone or their outputs mixed in arbitrary amounts. Here's a picture of the drive done in Lego:

http://groups.csail.mit.edu/drl/courses/cs54-2001s/dualdiff.html

Now this system only fixes the variable output from two different motors. It would still suffer from repeatability problems in distance or rotation angles as motors lose power from weak batteries. Still the ability to drive straight without encoders seems worth while. Plus a compass sensor and a beacon navigation system would fix those problems while being more reliable then dead reckoning.

agfa

Thats pretty cool!· Have you seen the differential drive in the BigTrak?· It uses magnets to couple the motors, very simple and effective.· I used the gear box out of one to make a bot.· It would drive a straight line, do zero radius turns and single wheel turns, but·it was impossible to make large radius turns.·

http://www.thebigtrak.com/legacysites/robotprojects/

Thanks for posting.

agfa

Martin_H

agfa, I haven't seen how the magnetic clutch on the big track worked. That's a neat idea too as it is more amenable to mass production than the dual differential drive.

erco

Martin:·Robo-Rats is·one of my favorite websites, the videos are excellent. Trouble is, the dual diff drive (DDD) uses too many parts. It's expensive, but more importantly, there's a LOT of mechanical backlash that creeps in that introduces error·and undoes the·good that it does.·I·used to be convinced that a DDD was the only way to drive straight, until I built some diff drive robots with encoders (Scribbler and Retrobot) that proved that even a vanilla BS2 is up to the task for reasonable speeds & resolutions. At the risk of restating the obvious, have a peek at my videos, which use BS2s for everything.

scribbler: http://www.youtube.com/watch?v=5r2En4hLUBI

retrobot: http://www.youtube.com/watch?v=Trv682XZ_8c

Mechanical accuracy & simplicity, coupled with a robust motor controller, can achieve a lot. BTW,·my 2-speed,·4-state relay·motor controller in the Retrobot is superior (for driving a robot) to the Scribbler's full digital proportional solid state·motor speeds controls, mainly because·it provides full dynamic braking. In addition, Scribbler and Stingray are geared· too high (fast) for accuracy/repeatability. I have yet to see a stock Stingray demonstrate·repeatable dead reckoning (yes, that's a direct challenge for you Stingray lovers!).

Edit: a DDD could make use of a single encoder effectively to track position, if· rotation or translation are used individually and not mixed together. This does·reduce processor overhead significantly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Post Edited (erco) : 7/4/2010 5:26:33 PM GMT

Martin_H

Erco, I·agree that the BS2 is up to using wheel encoders and they're great for driving straight.· I have them on my hacked Scribbler and the CBA robot and love them.· While the results are great, they are intrusive to use.

The trouble is that I/O pins and RAM are in short supply and·I'm using up two pins,·two bytes for encoder counts, and four bits for encoder state (previous and current).· Today I was trying to see if I could use the encoder to check for motor stall, but that will use even more RAM and I couldn't think of a reliable way to figure out if a pulse should have happened by now.

I suppose a steering drive like the Arrick ARobot has an advantage here.· But you lose the ability to turn in place.

erco

Funy, I just got a used Arobot of Craigslist locally. There's a lot of slop in the steering linkage, typical of most R/C cars. I haven't tried it yet, but I'm sure it will have issues with accuracy & repeatability. Servos aren't perfectly repeatable (hysteresis & deadband) and the error increases through the sloppy linkage.

BTW, I used just one sensor (hence one I/O pin) per encoder, which is technically called a "tach sensor", as opposed to a 2-sensor (two I/O) quadrature encoder. The tach sensor route uses fewer pins and a lot less processor overhead.

I've had surprisingly good results with these sensors and 36-segment encoder disks. I expected to need 72 segments or more, but I'm sticking with 36.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·"If you build it, they will come."

Martin_H

Erco my son and I build Lego robots and everything looks incredibly precise compared to the play in Lego linkages! Experienced builders claim you can use a rubber band to hold gears together to reduce backlash. Still a used ARobot sounds like a great score. A new one is way to expensive for where the market is now, but the mechanics of the device look interesting.

I'm using one sensor with 24 segments and that seems to work well for smaller wheels. I need two bits per wheel because I sample the current encoder values and compare them to prior encoder values. After I calculate my movement count bytes I move the saved current values into the old values. My thinking is that if I kept checking the current sensor values I might get different values from the first and second operation due to robot momentum. That would cause dropped counts and erratic movement.

But a magic go straight drive would be really nice because I could avoid all that fiddling!

Right now I'm working on wall following using the Ping. If I could detect the stall condition with the encoders I could avoid the need for a bumper and using yet another I/O pin. I was using the Ping to check for free space in front and then pinging to the side, while not moving forward more than the known free space. But when something unexpected happened the robot ground against the obstruction which wasn't a good idea.

Post Edited (Martin_H) : 7/4/2010 11:45:11 PM GMT