A Simple Improvement to Driving

[generalbrando]

This may be common knowledge, but I couldn't find it searching, so I post away.

Our drive train (basic tank drive, two joy sticks) is very powerful but unbalanced because it's us building it. We put a large caster on the back recently to make it drive on any demonstration surface. When driving it now, you have to be a good driver to control it because there's a bit of swerving, requiring lots of correction. I'm used to this because that's how all the bots I've driven have been, but I wanted to fix this.

My thought was to program it so it would go straight easier and be more intuitive for new drivers. Here's what I thought of: (in non-tech terms so all crowds can enjoy )

Find the average of the two y values of the joy sticks. This is half way between each of them, reguardless of which one is greater. Now average each y value with the average. Those two averages will be 1/4 way from the original values toward the other joy stick. The result, if you can visualize, is that if you push both sticks forward, but you don't do it in perfect sync, the program will minimize the difference and the robot will go straight forward instead of swerving a lot.

For the techies:
pwm01=(p1_y+((p1_y+p2_y)/2)/2)
pwm02=(p2_y+((p1_y+p2_y)/2)/2)

A fun result is that if you push one joy stick, both wheels move and you get a very smooth curve. I found in testing however that if you push one stick far enough, the other wheel will stay still because there is too much torque needed to push out of the spin(?). This may just be an oddity of our drive train though.

[Andrew Schuetze]

[quote=generalbrando]This may be common knowledge, but I couldn't find it searching, so I post away.



Those two averages will be 1/4 way from the original values toward the other joy stick. The result, if you can visualize, is that if you push both sticks forward, but you don't do it in perfect sync, the program will minimize the difference and the robot will go straight forward instead of swerving a lot.

For the techies:
pwm01=(p1_y+((p1_y+p2_y)/2)/2)
pwm02=(p2_y+((p1_y+p2_y)/2)/2)

I have not seen this posted before but have not looked at drive algorithms much in the past. I appretiated your program line codes as the paragraph description then made sense.

Question: What is the result with one stick full forward and the other full reverse? Does it still do a zero degree spin albeit just slower? The spin factor in a traditional tank steer is where a lot of loss of control causes problems. The other being the swerving during a forward motion that you mentioned.

Checking my logic, both sticks in maximum deflection in the same direction results in the averages being the actual stick positions??


Thanks for posting,

APS

[Tytus Gerrish]

why dont you just practice driving? that always seems to be the best way for new drivers to get better

[J Flex 188]

sometimes there just isnt time before shipping day or not enough resources to build a second practice platform =T. practice can definitely come in the practice rounds on thursday

[generalbrando]

My thinking exactly. Back in Hammond I was backup driver to the awesome Kevin (bow). Even as backup I drove many many hours and now I can still drive well enough to make it look easy.

My team this past year only got about....an hour? We didn't have time to drive it much considering it didn't move until week 4 or 5 (next year will be better!).

Another thought was that when doing demonstrations, it's great to reel people in by letting them drive a little. Usually they fly all over and get nervous and it gets worse. Compensations like this should help that.

Another simple improvement I tried out - find the absolute value of the difference between the two sticks. If it's less than a specified constant (let's say 15) then average the sticks and send that out to the motors. That way when they are very close to the same value, the robot will in face drive forward.

[generalbrando]

[quote=Andrew Schuetze]

Originally Posted by generalbrando

This may be common knowledge, but I couldn't find it searching, so I post away.



Those two averages will be 1/4 way from the original values toward the other joy stick. The result, if you can visualize, is that if you push both sticks forward, but you don't do it in perfect sync, the program will minimize the difference and the robot will go straight forward instead of swerving a lot.

For the techies:
pwm01=(p1_y+((p1_y+p2_y)/2)/2)
pwm02=(p2_y+((p1_y+p2_y)/2)/2)

I have not seen this posted before but have not looked at drive algorithms much in the past. I appretiated your program line codes as the paragraph description then made sense.

Question: What is the result with one stick full forward and the other full reverse? Does it still do a zero degree spin albeit just slower? The spin factor in a traditional tank steer is where a lot of loss of control causes problems. The other being the swerving during a forward motion that you mentioned.

Checking my logic, both sticks in maximum deflection in the same direction results in the averages being the actual stick positions??


Thanks for posting,

APS

Well if you work through the math, it should be 0 and 256 averaged=128. Then average between that and the originals...64 and 194. Technically 127 is center (right?) so that's a tiny bit off, but the results is a slower spin. I thought there might be a quirk where I would need to handle an exception for such a thing like this, but in testing, I found it works fine all around.

Am I making sense? (it's 1am and my brain took the weekend off several hours ago).

[stephenthe1]

would it be better to do this.

pwm01=((p1_y+((p1_y+p2_y)/2))/2)
pwm02=((p2_y+((p1_y+p2_y)/2))/2)

this way the value is a little closer to the appropriate y-value for the port,
but it still compensates for the difference between the 2 pwms.

[Jaine Perotti]

Originally Posted by generalbrando

Well if you work through the math, it should be 0 and 256 averaged=128. Then average between that and the originals...64 and 194. Technically 127 is center (right?) so that's a tiny bit off, but the results is a slower spin. I thought there might be a quirk where I would need to handle an exception for such a thing like this, but in testing, I found it works fine all around.

Am I making sense? (it's 1am and my brain took the weekend off several hours ago).

generalbrando,

I like your ideas.

However, the one thing that came to my mind was this slow turn that you mentioned above. Are you planning on incorperating this feature solely into robots used for demonstrations?

The reason I'm asking is if you were to use this on your competition robot, I am not sure if this slow turn would be the best thing in the heat of a match when you need to move fast around the field. A slow turn with the joysticks in full forward and back position might not be responsive enough when you are trying to pivot and maneuver quickly when needed.

I think this is an excellent idea, don't get me wrong, but will it hinder your ability to change direction fast enough on the playing field?

[Squirrelrock]

Originally Posted by BurningQuestion

I am not sure if this slow turn would be the best thing in the heat of a match when you need to move fast around the field. A slow turn with the joysticks in full forward and back position might not be responsive enough when you are trying to pivot and maneuver quickly when needed.

I just discussed this with our other driver (Scitobor 617) and we agree that the robot will tun too slowly in the heat of a match for any good use outside of demonstrations. Even if you put one joystick forward, then both wheels move forward, and you turn on an arc.

However, if you really wanted to, you could put that code in your code ( ) and add a switch on the controll board that would effectivly "comment out" the extra code, allowing you to turn more quickly.

Just a thought from the middle of US and Virginia History.

[generalbrando]

It's true that you're going to have half the turning speed and that you'd end up arching when pushing one stick.

That code mentioned above is correct I believe - my version is a bit more cluttered but hopefully either gets the idea across.

Anyway, in defense of the argument that it'll turn too slow, you're going to have to agree that we can't generalize. Slower turning on 246's 2004 bot is better because of the balance of the weight to the non-drive side means that it has a heavy tail - it's tough to control at times. And yet, it still allows for quick enough maneuvering in this case. Different robots will benefit from different programming.

This isn't something for every 'bot, but if a team wanted this effect but didn't want to lose their turning speed, you could include another piece of code downstream of this. It would check to see (for example) if the sticks were each pushed in opposite directions past the 3/4 (or half...you'd have to tweak it probably) point. For those familiar with code, you'd check if one stick was under 64 while the other was above 192 or vise versa. If it is, then you'd tell it to send the values of the ports directly to the pwm outs (as usual).

But yes, it's valid to say that it would be a bad idea for some skilled drivers who are used to that absolute non-interpretive control, not to mention the turning being potentially a problem.

[Matt Attallah]

Team 5 use to used tank drive for the 1998, 99, 00, and 01 years. Rember - when you take the motors and flip them opposite of eachother (So when moving foward - one motor thinks it's running in reverse) these motors seem to have a (?)Reverse bias? It's in the way the brushes think.

We just took care of that in programming. Just take away from the more powerful side that kept pushing the robot to be crooked...

[krhs_programmer]

My teams first robot used tank drive but with two drive wheels and two spining casters which made it very unstable at times and like you guys have said, it doesn't like to go in straight lines. Although this could be do inpart to the fact that one of the motors was slightly weaker that the other, but still that idea should work for us. After read the thread and seeing the drawbacks to it i came up with this idea:
If you were to designate one of the buttons on your joystick as a toggle switch and used it to toggle that function on and off depending on whether you want to be accurate or quick when driving.

first set up code so when you push the button it switches a variable between 2 values. (you'll have to do this on your own because i don't know how. sorry )
Then just use if statements:

if ( toggle == 1 ) /* toggle = var. controlled by button */
{
pwm01=(p1_y+((p1_y+p2_y)/2)/2);
pwm02=(p2_y+((p1_y+p2_y)/2)/2);
}

else
if ( toggle == 0 )
{
pwm01 = /* what ever your normal code is */ ;
pwm02 = /* what ever your normal code is */ ;
}

in theory that should work if you wanted to do that. thats what we did for our compressor last year to override the pressure sensor to build enough pressure to do the pull up on the bar.

[Jeff K.]

Originally Posted by Matt Attallah

Team 5 use to used tank drive for the 1998, 99, 00, and 01 years. Rember - when you take the motors and flip them opposite of eachother (So when moving foward - one motor thinks it's running in reverse) these motors seem to have a (?)Reverse bias? It's in the way the brushes think.

That's because they're drill motors. The drill motor gear box turns one way faster than the other. One way you can fix that is by not having one drive train mirror the other, but actually build it, so that it looks exactly like the other side. Example- Our drivetrain is in an L shape, what we have to do is make it into an upside down 'L' Shape, so that the motor is in a different position, not right next to the other one. It should sorta look lik a demented 'H' right next to each other. That should fix your problem, that is if you're using drill motors. If you're using another kind of motor, then I don't know.

[greencactus3]

Originally Posted by Stonefan5271138

That's because they're drill motors. The drill motor gear box turns one way faster than the other. One way you can fix that is by not having one drive train mirror the other, but actually build it, so that it looks exactly like the other side. Example- Our drivetrain is in an L shape, what we have to do is make it into an upside down 'L' Shape, so that the motor is in a different position, not right next to the other one. It should sorta look lik a demented 'H' right next to each other. That should fix your problem, that is if you're using drill motors. If you're using another kind of motor, then I don't know.

one thing. maybe you just phrased it confusingly, but the gearboxes do not turn anything faster in one direction than the other, it is as Matt Attallah says. the brushes are timed advanced in one direction. which means the brushes are not centered from the permanent magnets

[Jeff K.]

Oh, my bad, sorry, I thought it was in the gearboxes.