Our programmers need help and guidance in programming a swerve drive with Pot feed bnack
| \ \ |
\ \
joystick
\
thats pretty much how its set up
all the wheels are linked up by one chain and a Window motor. there is aidler nylon sprocket on the chain witha potentiometer.
we want the pot to give us the angle of the wheel and want the wheels to turn to the position where the joystick is pointed to.
I hope those illustrations help.
If team who have tackled this type of problem befoer please help us out. aka wildstang or anyothers would be great.
Have you tried a PID loop? We faced a similar problem with our arms. We needed to drive the motors just enough to reach a position and fight gravity, but not enough to overshoot. The trick is to set your motor value proportional to the distance you want to go.
A solution (run through this every so often with timers):
Find the difference between your current pot position and your target position. This is your error value.
You want your motor value to be proportional to the error. Multiply the error by a constant (you’ll have to figure it out through experimentation). This gives you your proportional value.
As your wheels approach the right orientaion, your motor value will decrease more and more. To compensate for this, integrate the error (ie add the current error to a running total). Multiply this by another constant (again, you’ll have to figure it out). This will give you your integral value.
Add the two values together to get your motor value.
It sounds a little complicated, but the code is actually pretty simple. The object does tend to overshoot some, and then oscillate a little. This can be minimized by adjusting the constants.
This system may allow you to plug in a certain angle and have your wheels find that position automatically. On our robot, we use this to create preset arm positions. You might be able to do the same with wheel positions.
EDIT: On second thought, using an integral probably wouldn’t be best for you. Instead, you might want to just use a proportional value. To get the wheel to its target position when the proportional drops too low, you could have a range close to the target with a different constant (to multiply by).
You are probably going to need a trig table in order to interpret the x and y axes of the joystick. This can be a slow process and dramatically slow down your performance, the same (or worse) as using floating point numbers. I don’t really know all the machinations of EEPROM (Ajay knows more than I), or much about swerve, but you are going to need to find that angle if you want to get anywhere…
From there I would use a proportional value to move the motors that decreases as you close on the right position.
Akshay, if you could have Rebecca IM me sometime in the next week or two, I’ll do everything I can to help you out with your system.
Pretty much, if you can determine the arctangent of the joystick position, you can determine the angle you want your wheel modules at, and using the Pythagorean Theorem, you can determine magnitude of your drive motors.
Because of the fact that you cannot rotate your wheel modules around completely, I think that if the sine of your joystick value is negative (id est, less than or equal to 127) you should invert the cosine value and the magnitude, in order to have the wheel modules only travel 180degrees, total.
This could prove to be a problem when you make the transition from some small positive angle from normal to an angle just below normal (300+degrees), in which case your wheel modules would have to traverse almost all of 180 degrees in order wind up pointing in the proper direction.
There’re many other considerations when you’re programming a system like this, and I’m really more than willing to help you guys out with anything I can. I really want to say that I’m sorry that I didn’t get to help you at Sacramento, this weekend.
<edit>
About PID control, we used a P control loop on our swerve, last year (with the BasicStamp-based control system), so I don’t think that getting too far (farther than P) into feedback control systems is very necessary.
</edit>
If you need help getting the wheels to servo to angle, I can give you the PID code for our arm. We use a window motor to servo it to a pot angle. Works like a charm (after a adjusting the constants to hell).
It’s much easier to try to map joystick values to pot values than to try to determine the angle and everything. The end effect is just the same, and it’s much easier to code. Here’s some pseudo code to start you out:
Compare joystick to pot:
JOYSTICK > POT + LEEWAY: Check to see how far apart
JOYSTICK > SET RANGE > POT + LEEWAY:
Power motor fast
SET RANGE > JOYSTICK > POT + LEEWAY:
Power motor slower
POT - LEEWAY <= JOYSTICK <= POT + LEEWAY:
Set motor Neutral
POT - LEEWAY > JOYSTICK:
JOYSTICK < SET RANGE < POT - LEEWAY:
Set motor fast opposite dir
SET RANGE < JOYSTICK < POT - LEEWAY:
Set motor slower opp dir
ELSE
Set motor neutral
If you’re keeping the joystick in a set position (like a dial for example), then it’s silly to use proportional speeds. Just make sure that the slower speed is slow enough for it to stop without much drift. The friction between the tires and the floor should take care of the rest. Last year we had unidirectional drive with a dial-control, and used almost the exact same code (IIRC, we used two set ranges instead of one)
He is using a potentiometer, the one built into the joystick. Have you ever tried driving a robot with a pot? It’s not easy. It’s essential to have a controller that bounces back to the neutral position, exactly like the joystick does.
The controls may not be a 1:1 mapping, in most cases for crab/swerve it is not. We map the full range of the joystick to 180 degrees of motion - full left to full right. That ends up being about 66% of the full pot range. Besides the scaling, we calibrate the crab pot such that 127 does not have to be the center position, this makes putting the pot in its place much easier.
with crab steering I would think you would want a pot that stays where you left it - because the bot does not turn in an arc like a car or a bot with conventional 2 or 4 wheel drive - it goes where you point it
why would you want your bot to always default to pointing straight down the field?
It’s not a bot that defaults to pointing straight down the field, it’s a bot that defaults to wheels pointing straight ahead. Our driver doesn’t want to mess around with centering a pot when he wants to drive straight forward. He wants to let the springs in the stick find the center point for him & have the wheels snap to straight ahead without much effort or thought.
Here is the code we used 2 years ago in pBasic. It was the identical setup to yours with a 4 wheels linked and one pot and one steering motor. When the top joystick button was pressed, the wheels followed the joystick around, when released they went forward and steered like a tank.
hi everyone,
thanks for all ur answers to the swerve program! i think the table i made for inverse tangent was incorrect. also, when i compared and displayed the pot value and the value the pot should be at according to the joystick, printf displays garbage. but when i use it in an equation, it works, so maybe its something with printf, although both variables are signed ints, so it should be ok. anyways, i used the taylor power series expansion to find inverse tangent, and used the difference between pot and where pot should be to find a variable speed of rotation, so the code works. thanks again everyone, and check out mvrt 115 in silicon valley.
rebecca
If you use only a P term you should be careful of resonance. That may not be an issue becaue the wheels don’t have much momentum when they start turning, but if they start shaking back and forth it means you need a D term.
Update: We tried a lookup table, and it was causing us some trouble. Now we’re using floating-point math (gasp!) and the arctangent maclaurin series, with up to the x^7 term. It runs fine.
At Silicon Valley, we found our potentiometer working fine, but instead, our speed was messed up, and often our wheels were going in the wrong direction entirely. Obviously, this was not good, and we ended up reverting to simple manual drive.
if you want some real help keep in contact with my team team 1011 team crush. we used swerve this is our second year and we made it to the semi finals but i would say look for brian on team 1011 or eric on team 1011 or korbin on team 1011
well thanks everyone for help again. we figured out how to make it work before SVR this year. Sadly we will not be goin to nationals this year . I will post the documentation about the drive and code soon. thanks again
the documentation and code is really long, so there will be a link soon on monta vista’s website: www.mvrt.com. id like to thank everyone again for his or her help. the swerve was working perfectly by the end of friday, so we were swerving on saturday and in finals. the speed function wasnt working because i was trying to use the greater of |p1_x | and |p1_y| so the robot would move the fastest sideways and straight. however, near 45 degrees the handoff wasnt smooth. anywas, check out the website if u are interested, or email me at [email protected]. thanks
rebecca
electrical officer
mvrt 115
. I will post the documentation about the drive and code soon. thanks again