Help correcting veer on track based robot

Other Hardware Robotics
1

I am building a robot as a personal project of mine and have been using the Dagu Rover 5 chassis which can be found here: Pololu - Dagu Rover 5 Tracked Chassis with Encoders

I am using an Arduino Mega and a four channel motor controller shown here: 4 Channel instruction manual.pdf - Google Drive

I have the version of the Rover 5 chassis with 4 encoders and 4 motors and I intend to use them all. I have the encoders hooked up to the encoder mixing circuitry on the board and I am getting good encoder count readings on the Arduino. However the robot has a veer in it's drive and I would like to correct this. I'm unsure how to use the encoder count to correct the veer. Any help in figuring out this problem would be appreciated.

2

If you have separate encoders on each track, then in order to drive a straight line, you drive the motors so that the number of encoder counts per time period is the same for each track.

This almost always means that the PWM values for the two track motors will be different. To determine those values, trial and error often works OK.

3

jremington:
To determine those values, trial and error often works OK.

Does it? I suppose it probably does. It seems like if there are quadrature encoders then the "proper" way to do this is with some sort of a PID algorithm (though usually P is enough)

I have two Rover 5 bots. Here's a thread about my Rover 5 with treads. I eventually got the bot to behave well.

My other Rover 5 has Vex Mecanum wheels on it. The robot behaved terribly before I added feedback from the encoders to the control algorithm.

There used to be some great encoder tutorials from the guy who designed the Rover 5 on Let's Make Robots. The new owners of the site deleted these tutorials when the author wouldn't agree to the sites new terms of service. It's really sad how many great articles have been deleted.

There are several techniques for computing speed with encoders. One way is to count the encoder transitions within a set period of time and the other way is to compute the speed from the time between encoder transitions.

You'll have a target speed you want to maintain. You subtract your current speed from this target speed to find your error. You adjust your PWM value an amount proportional to this error.

This sort of proportional feedback control is usually enough to get a robot to drive reasonably straight.

The performance of the robot can often be improved by adding a correction for error over time (integral) and a correction for how fast the value is changing (differential).

These three types of correction is known as PID. A PID algorithm is a very common motor control technique. I know there is PID code for the Arduino. I haven't used it myself but it shouldn't be too hard to find.

My two Rover 5 projects use a Propeller microcontroller.

4

Hi,
Are you aware that not all the PWM outputs are at the same frequency.
For the UNo.

pins 5 and 6 PWM Frequency = 62500Hz
pins 3, 9, 10, 11 PWM Frequency = 31250Hz

This means that if you drive a pair of motors with say pin 5 and pin 3, the speed response may be different due to the motors impedance.
So if you feed you motors with the same duty cycle they may not run at the same speed.
If you use PID to control them, then the PID parameters will be different for each motor.

So you need to drive pairs with 5 and 6 , or 3 and/or 9,10,11.
This will ensure even control.

Tom....... :slight_smile:

5

It seems like if there are quadrature encoders then the "proper" way to do this is with some sort of a PID algorithm (though usually P is enough)

I certainly agree, but a beginner has to start somewhere. Early on, many are surprised that "identical" motors and wheels or tracks behave differently.

Sad about the "Let's Make Robots" guy. He should be encouraged to post the material elsewhere.

6

jremington:
I certainly agree, but a beginner has to start somewhere. Early on, many are surprised that "identical" motors and wheels or tracks behave differently.

I agree. Controlling motors with encoder feedback is really cool but your method will likely get the bot up and running (straight) sooner.

jremington:
Sad about the "Let's Make Robots" guy. He should be encouraged to post the material elsewhere.

For those of us who were active on the site it was a disaster. Hackaday called it a "kerfuffle". Their article on it didn't provide much information but the comments fill in some of the details.

Russell Cameron (aka OddBot) now participates with RobotRebels.org and still has lot of cool robot videos on his YouTube channel.

I also had a lot of projects and posts on Let's Make Robots. These have all been deleted.

TomGeorge:
Are you aware that not all the PWM outputs are at the same frequency.
For the UNo.

pins 5 and 6 PWM Frequency = 62500Hz
pins 3, 9, 10, 11 PWM Frequency = 31250Hz

I believe those figures are the fastest possible frequencies. According to this page the default frequencies are 976.5625Hz and 490.20Hz.

A lot of h-bridges have trouble with high PWM frequencies. It would be a good idea to experiment a bit with various frequencies to see which frequencies get the best results. Of course it's always a good idea to see what the datasheet on the h-bridge suggests.

I use 200Hz on my Rover 5 bots. The 200Hz growl is much less annoying than the higher pitched whines some frequencies produce.

If an h-bridge supports ultrasonic frequencies then ultrasonic frequencies can be used. I'm almost certain the board used by the OP doesn't work well with ultrasonic frequencies. Russell Cameron also designed the 4-channel h-bridge.

The treads between the two motors on each side will do a lot towards synchronizing these motors. I personally monitor all four encoders on both my Rover 5 bots but I don't think monitoring only one set per side would reduce performance much. I should try this sometime and compare the performance against monitoring all four encoders.

I know the encoder version of the Wild Thumper only uses one set of encoders per side. All three motors are controlled based on the feedback from this single encoder.

7

Hi,
Sorry, been a long day, you are right.

But please note that two PWM frequencies are produced from the many arduino PWM pins.

pins 5 and 6 PWM Frequency = 976Hz
pins 3, 9, 10, 11 PWM Frequency = 490Hz

Tom.... :slight_smile:

8

For those of us who were active on the site it was a disaster. Hackaday called it a "kerfuffle".

Wow! Very interesting reading. Thanks for posting the link. RobotShop has always made a poor impression on me, so I will continue to avoid them.

Let RobotRebels.org be as successful as the LMR forum was!