2015: Year of the Mecanum

[Ether]

Originally Posted by Tom Line

After all your meCHanum motor set speeds are calculated, mix in a component from the gyro useing a PID.

My interpretation of the above is:

1) calculate the 4 motor speeds using the X and Y translation commands

2) calculate the motor speeds for rotation using the output from a PID

3) add the the corresponding speeds from (1) and (2).

Wouldn't it be more straightforward to compute the 4 motors speeds just once directly from the X, Y, and rotation commands?


BTW, what's the significance of the CH in caps?

[alopex_rex]

What I was thinking was a way of dealing with imperfect results from mecanum, i.e., if simply using WPILib's mecanum drive function results in the robot turning when it's supposed to be straight strafing. When the driver is trying not to rotate (the "rotate" value would be zero), store the current gyro heading. Then have a PID controller that tries to maintain that gyro heading, by setting the "rotate" argument for the function. So the PID would find the value that counteracts any undesired rotation caused by mechanical issues.

[Ben Wolsieffer]

Originally Posted by alopex_rex

What I was thinking was a way of dealing with imperfect results from mecanum, i.e., if simply using WPILib's mecanum drive function results in the robot turning when it's supposed to be straight strafing. When the driver is trying not to rotate (the "rotate" value would be zero), store the current gyro heading. Then have a PID controller that tries to maintain that gyro heading, by setting the "rotate" argument for the function. So the PID would find the value that counteracts any undesired rotation caused by mechanical issues.

This is exactly what we did in the past for our mecanum drive, and it worked wonderfully. We didn't have to obsess nearly as much about perfect weight distribution.

[Ether]

Originally Posted by alopex_rex

What I was thinking was a way of dealing with imperfect results from mecanum, i.e., if simply using WPILib's mecanum drive function results in the robot turning when it's supposed to be straight strafing. When the driver is trying not to rotate (the "rotate" value would be zero), store the current gyro heading. Then have a PID controller that tries to maintain that gyro heading, by setting the "rotate" argument for the function. So the PID would find the value that counteracts any undesired rotation caused by mechanical issues.

See attachment

[alopex_rex]

Nice chart--That's exactly what I was trying to describe!

[forbes]

Originally Posted by Ether

See attachment

Thanks, that diagram is helpful.

[Saberbot]

Originally Posted by Ether

See attachment

Wouldn't another option be to treat the feedback loop as the "rate controller" for the yaw axis? The rotation command from the joystick would be sent to the yaw controller. If it the command is zero then it will work as described in the attachment. If the command is greater than zero, then the controller will allow for more predictable rates of rotation based on the joystick command.

I believe this is how yaw control is managed on most RC Multicopters.

[Ether]

Originally Posted by Saberbot

Wouldn't another option be to treat the feedback loop as the "rate controller" for the yaw axis? The rotation command from the joystick would be sent to the yaw controller. If it the command is zero then it will work as described in the attachment.

What you've described¹ would work; but if you're trying to hold position, it's best to close the loop on position, not velocity.


¹ ... http://www.chiefdelphi.com/media/papers/download/2796 ...... http://www.chiefdelphi.com/media/papers/2390

[Saberbot]

Originally Posted by Ether

What you've described¹ would work; but if you're trying to hold position, it's best to close the loop on position, not velocity.


¹ ... http://www.chiefdelphi.com/media/papers/download/2796 ...... http://www.chiefdelphi.com/media/papers/2390

That makes sense. Thank you for creating these great resources.