Some questions about motion control

[growler]

I'm working on my first robot, and although I am quite pleased with the results this far I have some questions ideas/algorithms for greater motion control, i.e. driving in pretty curves to arrive at a set destination.

Some background on my setup:

I've built an ugly little board (that somehow works!), that includes an atmega168, a dual h-bridge IC, and a couple IR led/photodiode pairs.

I'm using the Tamiya double gearbox, http://www.pololu.com/catalog/product/114, and fortunately the gears are transparent to IR, but Chaos Black paint is not.

As a result I have encoders of the non-quadrature variety (not sure on the terminology) at 24cpr and to my surprise it works pretty well for gathering speed information.

The gearbox is driving two tank treads, also from Tamiya and with the encoders plus an 38khz ir module I can drive it from my remote and it goes straight (finally), at the desired speed when I tell it to.

My questions involve the software I am using to keep track of and adjust the motor speeds to effect motion about my floor.

My initial software, I have come to learn, was an attempt to essentially make a pair of servos such that I could request a position and have the shaft rotate to that position and stop through a PID loop, and then implement some kind of position profiling. As I feared this didn't work so well as I only have speed and velocity information for the shaft rotation and all the interesting stuff happens around the zero velocity point where I am least able to "guess" the velocity.

I've tried just incrementing the counts when I'm driving the motors one direction and decrementing when driving the other but the errors still are very apparent when trying to settle on the position. My first questions, does anyone have any thoughts on this issue? Is it one you have experience with? Do i just need quadrature encoders to make this work?

In response to these problems I have changed my method of control/feedback to look at speed instead of position, and this works well since I can set the direction and then let the PID loop set the speed. I may be crazy but at this point I think I've arrived at some solid velocity info as I know the direction, the speed, and the internal friction of the tracks and gearbox keeps it from rolling backward on moderate slopes anyway.

So I arrive at my final question, assuming I'm willing to accept a lot of error due to the low resolution of the encoders, would it make sense to attempt some sort of velocity profiling motion control system, or maybe integrate my velocities for a rough sense of position and position profile off that?

Sorry about the long post, I've been working alone on this and would love some feedback other than my wife who just kind of tunes out when I start rambling.

If you would like more information, please ask!

[mstacho]

Hm...you don't NEED quadrature encoders if you're willing to guess that when you are driving your motors backwards, they are actually moving backwards when the encoder ticks.  If they are just DC motors, this may not necessarily be the case -- you might be sending a backwards signal, but you're on a hill or something and are in fact rolling forwards, just slower because your motor is providing a counter torque.  But except in situations like that, quadrature just tells you the direction -- but you should know that given how you're driving the motors, so it's not needed.

(that being said, quadrature is useful :-P)

When you say "the errors are very apparent", what do you mean?  I have a feeling that this is what's happening: you tell the motors to go to 45 degrees.  They move, but either they overshoot, undershoot, or "hunt" around the right value.  Is that correct?  If so, then it's just a problem with the gains in your controller.  Undershoot/overshoot: increase the integral gain (I REALLY hope you don't have this problem, because integral gain always makes the motor oscillate).  Hunting is easier: increase the Derivative gain.

Now, keep in mind you have really low resolution encoders, so your derivatives will be HUGE -- the assumption that the encoder provides a "close" analog to the actual wheel rotation is only valid when you have lots of ticks.  But playing with the gains is what I would recommend anyway.

 To answer your final question: no, it does not make sense to integrate the velocity to get the position.  In theory you'll get the exact same information from integrating the velocity compared to just sensing the position.  Problem is you'd need an exact timer, which you almost definitely don't have.  Luckily, that same "in theory" says that if you can sense the position, do it, because using the velocity gives you no increase in information.

Your velocity control law is fine, though, since for the most part you aren't really controlling position of the wheels -- you're controlling the position of the robot.  So here's your real question (I think.  If I'm wrong, forgive me for the next few rambling paragraphs):  How do I control the position of the ROBOT if all I can do is control the velocity of the WHEELS?

Well...you can't do that without lots of error, given your set up (buy better sensors!  :-P but for now...) your wheels have a constant circumference, so you know that one encoder tick gives you 1/24 of that circumference of forward or backward motion (correct this for the gearbox, of course).  Assuming your wheels don't slip (and don't let anyone tell you that this is a serious problem unless you're trying for absurdly accurate positioning that a 24 cpr encoder won't give you anyway), you just keep track of how many ticks you have and therefore position. 

You then implement another PID control loop on that position information.  That PID loop gives you the desired speed to feed into your motor speed control loop, and (in theory) bob's your uncle (see the asterisk * below for a discussion on WHY this works).

The problem is you'll actually have to compute the robot's direction, which is accomplished by the wheels turning at different rates (I assume?).  But this is accomplished with some relatively basic computations (if wheel A turns twice and wheel B turns 3 times, and they are opposite each other on the robot, then you're turning in some radius).

*why this works: to a motor, torque and speed are duals of each other.  the motor torque translates, through the wheels, into a force on the robot.  Thus with a speed controller on the motors, you actually have a torque controller (well...) and thus a force controller on the robot!

Did...that help?

MIKE

[growler]

Mike, first off thanks for the reply and it does help at least to confirm some of the thoughts I've had since posting the initial question.

I know I need to get better sensors, or rather more of them but that is going to have to wait for the next robot, I'm just trying to get as much experimenting out of this hardware as possible to highlight pitfalls I can avoid next time around.

When I say the error is very apparent what I mean is that if I overshoot on a particular position correction the error introduced into my encoder counts start to increase rapidly as I have to guess whether the next tick is forward of backward at the same time as trying to change direction on the motor. Since I'm stuck with speed information and my code is not that good at guessing the direction I can't really nail the target position.  I'm not sure if I'm explaining well.

Upshot, I can get it to settle quickly maybe 5 times out of 8 but when it does overshoot it goes into some crazy oscillations and I can see the encoder count misbehaving in the serial debug out I've got set up. As far as I can tell this is what happens.

Overshoot occurs, drive tries to reverse, takes a little time to overcome intertia and actually rotate back.
During that time, if I hit another tick, it might be in one direction, before the motor has overcome inertia, or the other direction once the directional change has taken place. Of course now the count is off, and it might start oscillating trying to get to a count that in some cases in effect "runs away" from where it thinks that it is.

Anyway, my pid loops aren't looking at centering around a position anymore, and are now simply holding the speed (error = targetspeed - ticks/unit time, output pwm to H-bridge enable) constant while I manage the direction seperately. Sign magnitude drive control setup.

I'm getting decent results with this setup, as expected most error creeping in when crossing the zero velocity mark for a given motor.

My motivation for integrating the velocity is due to my inability to directly sense the position and I feel like the only solid info i have is speed and the direction I've set which is pretty reliable as a velocity and I suppose I didn't communicate my intentions with the velocity integration well enough.  I was simply planning to add my speed information to a running total since I know how often my speed is being calculated, which in essence will just give me the number of encoder ticks I've traveled over the period I'm looking at. I guess I'm just trying to keep it conceptually clear to myself that my encoder information alone is not a valid piece of positional data since I can't get direction out of it. I already have the speed calculation taking place at interrupt driven time intervals so I think I can get away with this.

I'm not to concerned about rollback and counter torque messing with my calculations since currently its sitting on some tank treads that hold still on as big of a slope as I've got in my house and I would need to redesign a lot of things before I wanted to take it outside.

Again, thanks for your thoughts.

[mstacho]

I see the problem more clearly now, and it seems to me that the only robust solution IS to get quadrature encoders or some other sensor for direction -- you simply don't have the direction information that you need.

However there are some workarounds that should at least do SOMETHING to help. 

1) If you're using a PID, switch instead to just a PD controller, then increase the D gain.  You want to avoid overshoot in the first place, so that your direction estimate is accurate.  the I gain makes it overshoot, and the D gain stops that overshoot.  However, a larger D gain makes the controller respond slower, no I gain makes the controller have a steady state error, and your P gain might need to be adjusted.

2) The problem really only occurs around zero velocity.  So with a bit of coding you can set it up so that your system cuts all power when the velocity is below a threshold.  Wait until the encoder ticks stop coming (indicating the robot is stopped, of course), and then continue.  You'll still have errors but you'll have a bit more control.  This will make the robot jerky, and will make any control of the motors below the threshold velocity impossible.

3) If you have the materials and the space, make a quadrature encoder.  You just mount a second IR sensor on each one in such a place that the direction information is maintained.

4) NOTE: This option is absurd and should never be attempted by anyone :-P It's just here because it represents the easiest way I can think of to get direction information without quadrature/other sensors: your DC motor runs way faster than your gears.  Put a magnet on its shaft, before it attaches to the gears, and wind a acoil of wire and let the shaft rotate around inside the coil.  Toss that voltage through a circuit with two diodes, oriented opposite each other, in parralel -- whichever one has voltage on it is the direction you're going.  Read that voltage through your ADC ports on your microcontroller (with a suitable resistance to avoid burning it out!)

I know how much the excitement of making a robot RIGHT NOW can make you avoid getting a better sensor that might take a while to arrive, but you'll definitely thank yourself for doing it in the long run.

MIKE

ps: I should also point out that option 4 can actually also be used as an analog speedometer, which is exactly how your car does it, and thus can allow you to circumvent the encoders entirely.  Except don't do it :-P

[Billy]

So with a bit of coding you can set it up so that your system cuts all power when the velocity is below a threshold.  Wait until the encoder ticks stop coming (indicating the robot is stopped, of course), and then continue. 

He may be able to use this method to reduce the occurrance of the issue, but encoders will have spurious transitions at the edge of a line. An encoder that is stopped may have one of the quad lines toggling high and low. If his code interprets that as encoder ticks he will have continuing issues.

As mstacho has already stated, you really need quad encoders and a quad decoder. That way a toggling line will be read as +1 -1 +1 -1 +1 -1, instead of the +1 +1 +1 +1 +1 you have now.   

[growler]

Thank you both, I've considered option #2 from Mike as the best solution I can come up with, I think I'll just keep with the current setup as its working and I can drive the motors at a set speed.

I don't think I'll be able to get anymore sensors into the gearbox without pretty much redesigning the whole board.

Guess I'll just have to add that to the list of things to do better with the next one.

[mstacho]

That's usually how it happens with my robots: I start by building little test platforms that do one thing, then once I've learned just about all I can from that platform, I'll use all my experience and start again, building a better platform, use it to its max, and just keep going.  The hand I'm building right now is currently in its third generation and probably has at least two or three more to go before it has all the functionality I'm looking for.

So keep playing until you're ready to move on!

MIKE

[growler]

If his code interprets that as encoder ticks he will have continuing issues.
   

Bingo, couldn't think of a solution to this.

[growler]

That's usually how it happens with my robots: I start by building little test platforms that do one thing, then once I've learned just about all I can from that platform, I'll use all my experience and start again, building a better platform, use it to its max, and just keep going.  The hand I'm building right now is currently in its third generation and probably has at least two or three more to go before it has all the functionality I'm looking for.

So keep playing until you're ready to move on!

MIKE

Test platform was design goal one for this project so it is a total success in that regard.  I actually have it doing everything I had in mind when I started building it.

It follows lines, slowly, and I can drive it around at a couple feet per second with an IR RC helicopter remote I modded a little. And finally, it drives in a straight line at the speed I want which was by far the hardest thing to get working, both mechanically and hardware wise. Lots of fun so far.

[Gertlex]

This is totally not helpful, but I approve of Chaos Black paint usage