Limit speed of 4 chassis CIM motors

[Mr V]

Originally Posted by jblay

Also, what might help is limiting deceleration. I would make sure my motor controllers are set to coast and not brake, this way you don't decelerate as rapidly so that you have less tipping issues when stopping.

Yes tipping when abruptly getting off the throttle will also likely cause tipping. With 4 motors you can set one on each side to coast and one on each side to brake for a lower braking force. We did that on the rookie team I am working with this year and it has worked good in practice.

Personally I would remove a motor per side if it can be done w/o major disassembly.

[GeeTwo]

Originally Posted by jblay

Also, what might help is limiting deceleration. I would make sure my motor controllers are set to coast and not brake, this way you don't decelerate as rapidly so that you have less tipping issues when stopping.

Absolutely. Deceleration is a form of acceleration, and I included it implicitly. The following line was intended to reduce deceleration, and putting the motor controllers in coast would prevent a sudden unintentional change.

Originally Posted by GeeTwo

if (newSpeed < curSpeed - maxSpeedDelta)
     newspeed = curSpeed - maxSpeedDelta;

[Ether]

Originally Posted by Ether

You may want to limit acceleration.

The suggestions previously given in the post quoted above can be used to limit acceleration/deceleration without using sensors (no wheel encoders required).

If you have wheel encoders and you want to create smooth accel/decel-controlled pre-planned motion in auto, you might try something like this:

http://www.chiefdelphi.com/media/papers/download/4312

[s_forbes]

Originally Posted by Ether

http://www.chiefdelphi.com/forums/sh...69&postcount=8

http://www.chiefdelphi.com/forums/sh...22&postcount=2

We did a quick implementation of this approach a couple of weeks back. Limiting the rate that the joystick input can increase is an easy fix in code and does the job well. You can set different rate limits for each joystick axis (we have forward/back, strafing, and turning) to match the tipping geometry of the robot too.

[IronicDeadBird]

You using Joysticks or gamepads for control?

[s_forbes]

Originally Posted by IronicDeadBird

You using Joysticks or gamepads for control?

The interface hardware doesn't get rid of the tall-tippy-robot issue; you can still inadvertently send the robot a command of "full speed ahead" whether you use a joystick, a gamepad, or a DDR dance mat.

[IronicDeadBird]

Originally Posted by s_forbes

The interface hardware doesn't get rid of the tall-tippy-robot issue; you can still inadvertently send the robot a command of "full speed ahead" whether you use a joystick, a gamepad, or a DDR dance mat.

Going to have to disagree in regards to gamepads or typical console controllers you can gain more control over movement (provided they are bound to the thumb sticks) by increasing the height of the thumbstick you need to accidentally make much larger movements. If you are using a joystick your out of luck though.

[microman1934]

Thank you so much for the help guys, I just ended up doing this:

double rot = -stick.getX();
double speed = -stick.getY();
myRobot.arcadeDrive(rot*0.5, speed*0.5);

[nighterfighter]

Originally Posted by microman1934

Thank you so much for the help guys, I just ended up doing this:

double rot = -stick.getX();
double speed = -stick.getY();
myRobot.arcadeDrive(rot*0.5, speed*0.5);

Glad you found a solution.

I would suggest you throw that in a if-else statement though, making the half-speed your default speed:

if(stick.getRawButton(1))
{
myRobot.arcadeDrive(-stick.getX(),-stick.getY());
}
else
{
double rot = -stick.getX();
double speed = -stick.getY();
myRobot.arcadeDrive(rot*0.5, speed*0.5);
}

This way, if in the middle of a match, your driver decides that he or she needs full speed, they have the ability to do so.

Just a suggestion. Of course, you may already have it that way in the rest of your code!

[microman1934]

Thanks for the idea, would the throttle work for that as well?

[nighterfighter]

Originally Posted by microman1934

Thanks for the idea, would the throttle work for that as well?

Yes. You could set the throttle to act as a toggle switch...

I'm on my phone so I can't format this correctly and can only give some pseudo code.

If(stick.getThrottle () > 0)
myRobot.Drive (halfSpeedValues);

else if(stick.getThrottle <= 0)
myRobot.Drive (fullSpeedValues);

Remember the throttle on the joystick ranges from -1 to 1, so 0 will be in the middle.

[Knufire]

Just remember, by implementing that throttle (we refer to it as a software shift), you lose both speed and torque. This shouldn't be an issue driving around on an open field, but things like noodles or carrying large stacks while driving with the throtte enabled could cause very poor drive performance.

[JesseK]

Originally Posted by microman1934

Thank you so much for the help guys, I just ended up doing this:

double rot = -stick.getX();
double speed = -stick.getY();
myRobot.arcadeDrive(rot*0.5, speed*0.5);

Depending on your drive train characteristics, you may have trouble turning. This will be especially prevalent in tight spaces or next to a bump. It is just as bad (or worse, perception-wise) as flopping over on your face every match. Could you describe your drive train from a mechanical perspective?

[Ozuru]

Originally Posted by microman1934

Thank you so much for the help guys, I just ended up doing this:

double rot = -stick.getX();
double speed = -stick.getY();
myRobot.arcadeDrive(rot*0.5, speed*0.5);

Why not just square the magnitude? Pseudo code for example.

double rot = -stick.getX();
double speed = -stick.getRawAxis(drive axis);
myRobot.arcadeDrive(rot, speed * Math.abs(speed));

This allows finer control at lower speeds (when joystick is reading 0.5 you will send 0.25 to the motors) but still allows full speed when the joysticks are at full throttle.