pic: FRC488's Octocanum Ver 2.0

[JohnGilb]

Originally Posted by Ether

Mecanum is not hard to program. It is very straightforward. The same is true of field-oriented drive.

If your robot had superior control, I suspect the reasons are probably:

1) superior craftsmanship and attention to detail of the mechanical design (wheel and frame alignment, leveling, weight distribution, minimal and consistent drivetrain friction, carefully assembled and adjusted mecanum wheels)

2) attention to detail of the electrical design (proper wiring to motors and gyro, selection of gyro with minimal drift, etc)

3) well-designed driver interface (match the driver interface to the driver)

4) skilled drivers with lots of practice

Granted, the 488's 2011 machine was built quite well, but there were still all sorts of mechanical inconsistencies. The center of gravity moved around significantly as the arm moved, generally there was more weight in the back (and slightly more on the left side, I believe), not to mention occasionally getting rammed around or crashing into objects.

The base aspect of converting a desired vector/rotation into wheel speeds is pretty easy (it's even included in the WPI libraries), but we did a lot of additional work so the robot would _actually_ move the way you intended. There were many PID operations that more or less worked in concert to allow smooth robot control. It was essentially a solved problem from a theory perspective, but still required a lot of code in order to operate well.

[Ether]

Originally Posted by JohnGilb

There were many PID operations that more or less worked in concert to allow smooth robot control.

Other than closed-loop speed control of the 4 wheels (did you do that?), what other closed loop controllers did you use for controlling the drivetrain?

[JohnGilb]

Initially, we had 3 closed-loop systems:

Rotational - used a gyro to keep the robot on target heading
Translational - used encoders on "follow wheels" (unpowered wheels) to gauge ground speed and keep the robot translating on a target vector
Wheel Speed - used encoders on the drive wheels themselves to achieve precise wheel speed control

After a while, we actually disabled the wheel speed, as we didn't appear to get much performance improvement from it and we were looking to save on some CPU cycles.

[Ether]

Originally Posted by JohnGilb

Rotational - used a gyro to keep the robot on target heading
Translational - used encoders on "follow wheels" (unpowered wheels) to gauge ground speed and keep the robot translating on a target vector

Were these controls presented to the driver as the interface? i.e., did the driver interface allow the driver to command for example "Translate in direction A with the vehicle pointing in Direction B" ?

[JohnGilb]

The driver had two joysticks:

1st: X/Y joystick movement controlled X/Y direction & magnitude of the robot relative to the field
2nd: X joystick movement controlled rotational rate relative to the robot

So, not exactly what you described, but fairly close.

[Ether]

Originally Posted by JohnGilb

The driver had two joysticks:
1st: X/Y joystick movement controlled X/Y direction & magnitude of the robot relative to the field
2nd: X joystick movement controlled rotational rate relative to the robot

OK, so let me read back to you what I hear you saying:

- You do closed-loop control of the vehicle speed as commanded by the radius¹ of joystick #1

- You do closed-loop control of vehicle heading as commanded by the angle² of joystick #1

- You do open-loop command of rotation rate as commanded by joystick #2 (X, Y, or Z axis?)

Am I understanding you correctly?

How many follower wheels did you use, and how are they mounted?


¹ Do you use sqrt(X^2+Y^2) or max(abs(X),abs(Y))?

² Do you use atan2(X,-Y) to calculate angle, or something else?

[JohnGilb]

Sorry, I think something got lost in my description.

-We perform closed loop control of X translation as commanded by the X axis of Joystick1

-We perform closed loop control of Y translation as commanded by the Y axis of Joystick1

-We perform open loop control of Robot rotation rate as commanded by the X axis of Joystick2 (however, when desired rotation rate is 0, we perform closed-loop control of robot angle as commanded by the heading we were at when we stopped rotating)

This was accomplished with 3 follow wheels and a gyro. Two of the follow wheels were used to track the robot moving forward/backward, and one was placed directly under the center of rotation and used to track the robot strafing.

[pfreivald]

An interesting design! We've used mecanum for the past two years and were very satisfied with it in many respects, but know that it needs some push to really up our competition level. Thus, we've been working on our own drive (though I didn't know it had a cool name like 'octocanum') which is similar in idea to this.

Thanks for sharing! (And great questions everyone. This is a good thread to follow for anyone considering such shenanigans like we are!)

[Ether]

Originally Posted by JohnGilb

Sorry, I think something got lost in my description.

-We perform closed loop control of X translation as commanded by the X axis of Joystick1

-We perform closed loop control of Y translation as commanded by the Y axis of Joystick1

-We perform open loop control of Robot rotation rate as commanded by the X axis of Joystick2 (however, when desired rotation rate is 0, we perform closed-loop control of robot angle as commanded by the heading we were at when we stopped rotating)

This was accomplished with 3 follow wheels and a gyro. Two of the follow wheels were used to track the robot moving forward/backward, and one was placed directly under the center of rotation and used to track the robot strafing.

OK that's pretty clear, thanks.

Were the forward/backward follower wheels mounted like this? And, I assume they were omni, correct?

Did you ever consider, or try, using the data from the follower wheels to compute rotation rate?

[JohnGilb]

Ether, your follow wheel mounting assumption is correct. They were positioned as in your diagram, and they were omniwheels.

We did use them to calculate a rotation rate, let's call that Rotation_Follow. We also had rotation from the gyro, let's call that Rotation_Gyro.

We found that Rotation_Follow wasn't as good as the Rotation_Gyro, we suspect due to minute wheel scrub and small errors accumulating, but it did not suffer from drift. Consequently, we used Rotation_Gyro exclusively, but ignored any change in rotation while Rotation_Follow was 0 (typically at the start of the match before the robot was moving anywhere, or during testing when the robot spent a lot of time on a bench or disabled). This eliminated a large part of our gyro drift.

[Ether]

Originally Posted by JohnGilb

we used Rotation_Gyro exclusively, but ignored any change in rotation while Rotation_Follow was 0 (typically at the start of the match before the robot was moving anywhere, or during testing when the robot spent a lot of time on a bench or disabled). This eliminated a large part of our gyro drift.

I like it. Nicely done.

[Jared Russell]

Originally Posted by JohnGilb

Ether, your follow wheel mounting assumption is correct. They were positioned as in your diagram, and they were omniwheels.

We did use them to calculate a rotation rate, let's call that Rotation_Follow. We also had rotation from the gyro, let's call that Rotation_Gyro.

We found that Rotation_Follow wasn't as good as the Rotation_Gyro, we suspect due to minute wheel scrub and small errors accumulating, but it did not suffer from drift. Consequently, we used Rotation_Gyro exclusively, but ignored any change in rotation while Rotation_Follow was 0 (typically at the start of the match before the robot was moving anywhere, or during testing when the robot spent a lot of time on a bench or disabled). This eliminated a large part of our gyro drift.

This is a clever solution. A Kalman Filter would be another good way to combine accurate (but drift-prone) gyro measurements with less precise (but stable) odometry measurements.

[JohnGilb]

We tried a number of filters (Kalman was unfortunately beyond my reach, never had a strong grasp on linear algebra), but they turned out to be unnecessary - the gyro we used (don't have the model # on me) was incredibly accurate - it usually only drifted ~3 degrees over the course of each match, even through collisions.

The "stationary detection" we did was only necessary when the robot was put on the field but the start of the match was delayed several minutes (yeah, we've all been there).

[AdamHeard]

Originally Posted by JohnGilb

We tried a number of filters (Kalman was unfortunately beyond my reach, never had a strong grasp on linear algebra), but they turned out to be unnecessary - the gyro we used (don't have the model # on me) was incredibly accurate - it usually only drifted ~3 degrees over the course of each match, even through collisions.

The "stationary detection" we did was only necessary when the robot was put on the field but the start of the match was delayed several minutes (yeah, we've all been there).

Mind sharing the model number of that gyro?

Also, you didn't use the pair of follower wheels to try to determine rotation rate while translating, you just used it to detect the complete absence of velocity, correct?

[AdamHeard]

Originally Posted by Ether

Other than closed-loop speed control of the 4 wheels (did you do that?), what other closed loop controllers did you use for controlling the drivetrain?

Wouldn't measuring the vehicle's actual velocity be more useful? After all, the drive has no care as to what wheel speed is (especially if that wheel is slipping).