Best Driving scheme?
 

This is obviously subjective to opinion and different schemes work better on different robots, but do you guys use the default drive code or a variation? We have used tank driving so the last few years the default code seemed sufficient, but last year our robot was really jerky. I decided that I would write some code to smooth the acceleration out a bit.

My first scheme used the old code to set the value, but it also retained the old pwm out puts. Instead of outputting the new output from the general code it would output the old pwm value plus an increment that was initialized at one. The value of the increment could be increased or decrease with the joystick auxiliary buttons. So it was like a linear increase

My second scheme was similar to the first, except that it would set the needed increment by looking at the difference between the old and new pwm values and multiplying it by a constant. So the increase in the pwm value in this case was proportional to the difference. I could be wrong, but I think this is logistic acceleration because if you put it into a differential equation, it looks like Newton’s law of cooling.
y= pwm value t= time
(dy/dt)= k(N-O)
Where k is the constant you set N is the new value and O is the old value, except for the fact that O is not constant and it might change with every loop.

My third scheme was to use the second to set the values, but also to use input from the encoders to change the pwm values so the speeds of the wheels are the same. I only use the encoders though while the person is trying to drive straight.

So I guess my questions are
What driving scheme do you use? (Not necessarily one above)

If you were to use my third scheme...
How often would you adjust the pwm values? I have it so it changes it about every half a second. I haven’t got the opportunity to test it out, but instinct tells me that will be too slow, but isn't it true that as the sampling rate of the speed increases, so does the error in speed calculation unless you have a great amount of interrupts in one revolution?

Re: Best Driving scheme?
 

In the past we have used an exponential curve that is put into a lookup table. We started with an excel spreadsheet and experimentally created an exponential curve that we felt provided good slow speed precision, but still went full speed when the joystick was pushed all the way. Graphing the curve helped to visualize this. From excel we created a lookup table that created a pwm value for each joystick value from 0-254.

Re: Best Driving scheme?
 

It really depends on the preference of your drivers. Comfortable drivers means good driving, which means more matches won. :) Last year, for example, our team had several different programming strategies for motor control. They let the drive team pick which one(s) seemed most intuitive and easy to use to them. In fact, they offered that if not all the drivers agreed on a strategy for control, we could program one of the switches on our OI to allow us to switch between modes, so when different drivers used the robot they could customize it to be however they wanted. Luckily for the programmers, however, all of the drivers agreed on one method, so they didn't have to do that.

The method we ended up using last year was a curve, very similar to the one described in the last post. However, I am not on the programming team, so I'm not sure exactly how the code worked. Hope that helped!

Re: Best Driving scheme?
 

from my experience, when you try to damp or smooth the controls from the operator to the motors, all you end up doing is making the robot response sluggish and spongy

if the robot is twitchy and jerky then it requires a smooth and steady hand on the controls.

The motion of the robot is not linear. if you map the joystick inputs to the actual motion of the robot, you will discover the static and kinetic friction effects, when you start from a stand still it takes considerable input to get the bot to move, then once it starts moving it takes less input to hold a steady or low speed

but if you damp or average the driver inputs, then when the bot starts to move it will take some time before the driver can get the motors to back off.

The control of the robot is a closed loop feedback system. For the simplist robots the feedback is the drivers eyes, and the control is his brain: the driver moves the joystick, sees what the robot does (visually) and then makes adjustments

damping the response only makes the robot sluggish. If your driver has practice and is good, then he can make a fast, twitchy, responsive robot dance across the floor precisely

the answer to your question is to put sensors on the robots, and make the feedback control electro-mechanical, so that the robot itself can 'see' how fast its moving (through sensors) and compair that to what the operator is asking for, and make the corrections itself.

The reason this works better is the controller on the robot can respond in about 1/30th of a second to sensor feedback. The best a human driver can do, using eye to hand coordination, is about 1/10th of a second. And thats his best. The controller will response in 1/30th of a second to every sensor or driver input, consistanly and accurately.

Closed loop feedback. PID control loop. Thats the best way to control a FIRST robot.

Re: Best Driving scheme?
 

After much experimentation with many crazy control schemes, i have come to pretty much the same conclusion as Mr. Wittlief. If you do anything to smooth the controls, they no longer do exactly what you tell them too. Doing exactly what you tell the bot to may or may not be a good thing depending on the experience level of your driver. There is no substitute for a skilled driver. I have found that there are really only two things that are alot of help:

*a nonlinear curve that is used to map joystick values to PWM values. This compensates for various oddities of unknown origin which are discussed at length here.

*The second thing that helps is closed loop feedback as mentioned above. If you search these forums or google for "PID" you will find a massive wealth of information.

There is one final thing that i have implemented in cases where inexperienced drives will be driving the bot and that is acceleration limiting. This prevents people from doing stupid things.

Re: Best Driving scheme?
 

one of the hardest things to do with most FIRST bots is to get them to make small moves, to turn slightly, or to nudge ahead just an inch or so

a simple way to implement this is know as 'jogging'. You have a separate pushbutton on the driver control panel, and when you push it, it sends out one high level pulse to the motor: puts out 254 for one SW loop, then goes back to 128.

The effect is like tapping the robot with a hammer to get it to move 'just a little'. If you want, you can have the jog function auto-repeat, say at one second intervals

this is especially usefull for turning bots with tank steering - you can have a JOG-LEFT and JOG-RIGHT button on the control panels. Try it, its really amazing how well it works

and its very simple to implement in the code. If 254 jogs the bot too much, back it off to 225 or 200 till you get the effect you want.

Re: Best Driving scheme?
 

Thats a nifty idea, I think i am going to try it.