Need help programming our swerve with feedback?

[activemx]

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.

[Cyris12]

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):
1) Find the difference between your current pot position and your target position. This is your error value.
2) 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.
3) 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.
4) 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).

[10intheCrunch]

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.

[FotoPlasma]

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>

[Astronouth7303]

Why not just make a look-up table custom made for your bot?

[Alex1072]

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).

[TomJoseph]

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)

[KenWittlief]

why not simply use a potentiometer on the operator interface?

then all your control loop has to do is get the feedback pot to match the OI pot

and your wheels will turn in the direction the pot is pointing on the OI - like a steering wheel?

[Mike Soukup]

Originally Posted by KenWittlief

why not simply use a potentiometer on the operator interface?

then all your control loop has to do is get the feedback pot to match the OI pot

and your wheels will turn in the direction the pot is pointing on the OI - like a steering wheel?

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.

[KenWittlief]

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?

[Mike Soukup]

Originally Posted by KenWittlief

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.

[Grommit]

Originally Posted by Astronouth7303

Why not just make a look-up table custom made for your bot?

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.

Thanks for all the help everyone.

[eugenebrooks]

Originally Posted by Cyris12

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.

In physics terms, you are creating a harmonic oscillator
about the set point. The oscillation is a natural consequence of the linear force, much in the same manner that a mass bounces back and forth when suspended by a spring. You can reduce the finickyness by adding a damping term that operates much as a shock does on a car. This is done by adding a force that is proportional to, in this case the rotational, velocity and in opposition to the travel. This is easily done in he code by remembering the arm position from the prior poll with the computer, or interrupt as the case may be, and subtracting the current value. If you do this, you will find that you can increase the constant of proportionality for power to the drive motor, tightening up control, while preventing oscillation. There is a value for the damping, referred to as critically damped in physics terms if I remember correctly, that is somewhat magic in behavior.

We used this form of damping on 1280s arm at the
SanJose regional, and it was quite effective...

[Jay Lundy]

Originally Posted by eugenebrooks

In physics terms, you are creating a harmonic oscillator
about the set point. The oscillation is a natural consequence of the linear force, much in the same manner that a mass bounces back and forth when suspended by a spring. You can reduce the finickyness by adding a damping term that operates much as a shock does on a car. This is done by adding a force that is proportional to, in this case the rotational, velocity and in opposition to the travel. This is easily done in he code by remembering the arm position from the prior poll with the computer, or interrupt as the case may be, and subtracting the current value. If you do this, you will find that you can increase the constant of proportionality for power to the drive motor, tightening up control, while preventing oscillation. There is a value for the damping, referred to as critically damped in physics terms if I remember correctly, that is somewhat magic in behavior.

We used this form of damping on 1280s arm at the
SanJose regional, and it was quite effective...

Well by oscillate a little, he meant it overshot a few inches then returned to it's target spot. In theory it would have a damped oscillation that continued infinitely, but since this is all digital the oscillation dampened quickly and disappeared.

If you were at SVR you probably saw our arm. A lot of programming went into keeping that monster controllable.

[eugenebrooks]

Originally Posted by Jay Lundy

Well by oscillate a little, he meant it overshot a few inches then returned to it's target spot. In theory it would have a damped oscillation that continued infinitely, but since this is all digital the oscillation dampened quickly and disappeared.

If you were at SVR you probably saw our arm. A lot of programming went into keeping that monster controllable.

A description of the physics of what I am referring to can be found at:
http://hyperphysics.phy-astr.gsu.edu/hbase/oscda.html
by using an electrical damping term, not depending on mechanical
damping, you can get improved speed and control, subject to any slop
in the mechanism, of course.