Robot doesnt run straight...

[mastah84]

Hi,

My friend is currently working on a little sumo robot, but he has problems with it running straight line, aka it slightly turns right.

Project consists of:
1. Arduino Uno
2. Pololu motor driver based on DRV8833 on Arduino pins 3+11, 9+10
3. 2x 18650 nimh accus
4. 2x Pololu HP 50:1 DC motors, without any parallel capacitance

We have measured voltages on DC motors and despite PWM frequencies and duty cycles are the same on each channel, we can see slight differences between output signals - see attached images (one image per dc motor, voltage is offset by ~-4V). We checked it on two different pololu DRV8833 drivers. We dont know exactly what is the cause of this slight turning but AFAIK during installation of wheels there was some amount of force put into the axles (its really hard to push pololu wheels on pololu motors axles...) - maybe just too much force? We would like to descope any non-mechanical faults before he buys new motor(s). Maybe it is just a matter of quality dispersion of these motors? Maybe this weird voltage drop on one engine is responsible for different RPMs?

Thanks in advance for any suggestions.

[exapod]

With "cheap" motor and an open loop control is almost impossibile to make a robot run straight.
Try tweaking the PWM values.

[benjamin545]

in high school i use to build lego robots on a team that competed against other schools. one of the first things that you start to learn when trying to do accurate movement is that a standard brushed c motor does not have the same efficiency in its reverse direction as it does in its forwards. on a standard "tank" setup where you have both motors out each side of the chassis each connected to a wheel or a set of treads, one motor is moving in a forward direction, one motor is moving in its reverse.

the solution is to either put rotary encoders on the wheels to keep them in lockstep with each other. this is the best method. the other is to do some drift measurements and set the output power on each motor, in each direction, to some percentage of max power in order to keep the motor running in forward direction at a lower energy than the one running in reverse.

[Excavatoree]

This is a problem with construction equipment as well.  For slow machines, like excavators, there is no feedback.  The deviation is so small that the driver can make small corrections, and there's usually a need to turn anyway.  For faster vehicles, like bull dozers, we use a feedback system with encoders.

[Mechatrommer]

We would like to descope any non-mechanical faults before he buys new motor(s). Maybe it is just a matter of quality dispersion of these motors? Maybe this weird voltage drop on one engine is responsible for different RPMs?

you can buy 1000 motors and you will still have this problem sooner or later, even if you perfectly tune it the first time. you are looking for a perfectly matched motors and circuits and mech assy and wheathers which is pretty impossible in real world. what you need is a close loop feedback (rotary encoder and mcu processing et al), even stepper motor cannot guarantee you this (miss step).

[electr_peter]

Don't worry, humans cannot walk/drive/cycle straight either. There are only few things that are straight (somewhat) in general by design - light, falling mass due to gravity, equipment on straight rails/edges and similar stuff. Everything else needs feedback to correct the position in order to move straight.

Also, this issue depends strongly on definition of "straight". 1cm in 0.5m or 1mm in 10m? The better you measure, the worse "straightness" will be. DC motors should not be expected to be symmetrical. Use encoders/photo-sensors/mouse sensors to get estimate of true position and calibrate motors.

[mastah84]

Ok, Guys (and maybe Girls), thank You for all Your feedback.

From whole this discussion I see that there is only one right way to go and it is implementing closed feedback loop with uC dynamicaly adapting PWM duty cycle to counted pulses sent by encoder. I see lots of work ahead, again, wrrr...

Thanks again for Your responses,
Cheers!

[BlueBill]

I used optical encoders on the gear train on a robot kit I used to sell. The blue gears at the front are IR transparent and I used a bit of foil to interrupt the light sensor pair when the wheels were turning. I used a SN754410 to drive the Tamiya motors using two PWM channels.

[mastah84]

Did it work well for you?

As far as I can imagine and theoretically evaluate such solution (counting pulses on the gearbox) I find it insufficient in some cases. There must be two requirements fulfilled to make this closed loop working as expected:
1. produce as many controlling impulses as your uC counter can store/count in time unit (depending on how many impulses you can produce, you can use counter overflow or just poll and reset counter values in fixed intervals)
2. read counted values as frequently as you can, so you can adjust pwm duty cycle as soon as possible

If you mix these two requirements you will come with conclusion that if your feedback loop produces many-many control impulses, you can shorten intervals between subsequent read & pwm adjust stage without losing precision. Eventually, your uC can make more conscious decision whether to speed up/down and by how much one of the dc motor channel. On the other side, if you produce few such impulses, you need more time to collect them or make decissions based on low counter values.

If your counting solution is located so far from the engine, and by far I mean it at the end of the speed down gearbox, you can lose precision, so eventually your robot cant make smooth corrections - is starts to fluctuate/pluck left, right, left, right or is unable to correct pwm duty cycle fast enough...

Cheers!