pic: FRC488's Octocanum Ver 2.0

[RyanCahoon]

Originally Posted by pfreivald

I'd be worried about wonky drive control on mecanums that weren't hard-mounted to the frame. Our steel pods show absolutely no sign of damage after two regionals of really abusive driving on both mecanum and traction wheels.

Patrick,
Are you referring to potential for the force vector of a wheel to change if the pods deflect under load, leading to the forces from the wheels not summing correctly? I hadn't though of this before. Do you think this could be solved with feedback from the follower wheels/gyro?

Or did you have something else in mind?

[pfreivald]

Originally Posted by RyanCahoon

Patrick,
Are you referring to potential for the force vector of a wheel to change if the pods deflect under load, leading to the forces from the wheels not summing correctly?

That, and our machine tolerance aren't precise enough for me to be able to guarantee that the weight distribution is exactly right. As long as your frame is square and the mecanum wheels are mounted to it, this isn't a problem.

Originally Posted by RyanCahoon

Do you think this could be solved with feedback from the follower wheels/gyro?

In theory, every mechanical issue can be fixed by adding sensor feedback and offloading the issue to the programmers, right?

[kmcclary]

Originally, RyanCahoon wrote:
> Are you referring to potential for the force vector of a wheel to change if the pods deflect under load, leading to the forces from the wheels not summing correctly?

Originally Posted by pfreivald

That, and our machine tolerance aren't precise enough for me to be able to guarantee that the weight distribution is exactly right. As long as your frame is square and the mecanum wheels are mounted to it, this isn't a problem.

At first I was a fan of using "articulated sub-frames", for one of the pair of wheels, to rock them from side to side at their mid-line midpoint. Some of my early teams used this approach when attempting mecanum drives. It creates a "virtual tripod", which as you know from a three legged stool will ALWAYS sit flat on the floor. That evenly distributes the weight amongst the four wheels, and totally eliminates any "vector sum" problems.

However, from experience I've found that as long as you are working on a flat, carpeted surface (no ramps, et al) and avoid focused weight points on your robot, then the normal "twist give" of the basic C-Frame kit more than accounts for sufficient flex to keep all four of the wheels flat to the floor, and under proper load.

So (to keep this On Topic), as long as mounting the payload doesn't stiffen up this chassis too much, IMO 488's design should have more than sufficient flex to keep all four mec wheels on the ground on flat-surfaced games.

BUT... If you have to deal with RAMPS, I'd definitely consider going with the rocker sub-frame trick. Just place it on the FAR end from where your main gripper action occurs, to keep the gripper's orientation stable WRT the main frame.

BTW... As the arms are long between the two ends of the cylinders (and their pull motion is at 90 degrees to a rocker) should you DO decide to add a rocker sub-frame, then as long as the arm ends don't bind I'm not sure if you'd even have to go to independent cylinders for wheel switching!

NOTE: With rocker sub-frames, just be sure to LIMIT their motion to only a FEW degrees of rock, JUST enough to deal with keeping all four wheels on the ground!! Otherwise, you can risk flipping the bot if a wheel slips off the edge of a ramp, or encounters any other major field discontinuity!

This happened to us a few years ago, when we had to start the bot on a ramp. In one match one of our rocker sub-frame's wheels slipped off of the ramp edge during Autonomous. The rocker frame promptly spun over 45 degrees trying to keep all feet on the "ground". That let the robot tilt WAY over. The CG quickly went wonky, and the entire bot fall off of the ramp and onto its side...
We have since have added "motion limiter brackets" whenever we have a rocker sub-frame design, to limit it to JUST a few degrees of motion.

Originally Posted by pfreivald

In theory, every mechanical issue can be fixed by adding sensor feedback and offloading the issue to the programmers, right?

... Actually, I agree that having an independent measurement of performance is always USEFUL (for precision guidance during Autonomous, Field-Centered Navigation [FCN], etc).

But... As long as you have enough chassis twist flex to keep all four mecanum wheels firmly on the ground, IMO that becomes a bonus, not an absolute requirement.

IMO, just having a gyro in the sensor mix to account for orientation is often sufficient, even when implementing FCN. Since Auto is only 15 seconds long (and these days most game designs have been drifting toward having little or NO interaction with opposing robots during that time... <yawn>), I'm guessing that as long as you do not expect traction loss during Autonomous, then simple wheel encoders on the mecanum gearboxes may still be more than sufficient for implementing a decent Auto mode navigation routine.

YMMV though. If you are intending a really complex, far ranging Autonomous Mode (or we DO ever get back to being allowed to mess with opposing alliances during Auto Mode... Ah, the "Good Old Days"... ), then by all means add in the external sensors (follower wheels, gyros, etc) to support an independent "opinion" of where you are.

- Keith
--- Also the List Dad of "OmniMec" - An omnidirectional and mecanum wheel specialty e-list ---

[pfreivald]

Our octocanum drive this year did absolutely everything we wanted it to do, including take heaps of abuse with no signs of wear. We used one cylinder on each side of the robot, controlled with a single valve. Our mecanum wheels were hard-mounted to the chassis, and the traction wheels were on the ends of pivots just barely long enough to accommodate the wheel geometry.

We absolutely love everything about it except the weight, which we're going to play around with in the off-season.