pic: FRC488's Octocanum Ver 2.0

[pfreivald]

I wanted to resurrect this thread to say the following to Madison:

THANK YOU SO MUCH!

We based our octocanum on your design for this year, and it's the most successful, awesome drivetrain we've ever built. We absolutely, completely love it -- and based on the feedback from a lot of other teams, many other people do, too. It is, hands down, one of the reasons we were as successful as we were this year.

Thanks again!

[lcoreyl]

Originally Posted by pfreivald

I wanted to resurrect this thread to say the following to Madison:

THANK YOU SO MUCH!

We based our octocanum on your design for this year, and it's the most successful, awesome drivetrain we've ever built. We absolutely, completely love it -- and based on the feedback from a lot of other teams, many other people do, too. It is, hands down, one of the reasons we were as successful as we were this year.

Thanks again!

Wow, I guess this should push us over the edge and get to work on this. Man, I'm kicking myself for not prototyping so we could have used it this year.

I could probably guess due to your absolute love, but did you encounter any serious side loading during competition? (That will save Madison from needing to bother so she can go work on her next bit of magic!)

[pfreivald]

Originally Posted by lcoreyl

Wow, I guess this should push us over the edge and get to work on this. Man, I'm kicking myself for not prototyping so we could have used it this year.

I could probably guess due to your absolute love, but did you encounter any serious side loading during competition? (That will save Madison from needing to bother so she can go work on her next bit of magic!)

Nope. We made sure to use steel pods so that side load would be adequately dealt with -- and it was tremendously robust over two regionals where we played massive defense, crossed the barrier 1+ times a game, and did lots of bridge balancing. The only malfunction was losing tread on an AM performance wheel, and that hardly counts. (Even with only three treaded wheels, we humped across the barrier that last game.)

[kmcclary]

A good design, Madison. I've tried to convince several of my teams to try something similar for quite a few years now (and in fact I suggested this exact config THIS year, too!) But many of them are younger, smaller, still developing teams, and were a bit afraid of attempting a complex drive train in addition to focusing on designing complex payloads (like programmable shooters, rotating turrets, and non-jamming ball lifts).

Originally Posted by AllenGregoryIV

This looks really great I have a couple questions [...]
1. Why did you choose to pivot the traction wheels down instead of moving the mecanum wheels?

IMHO, you should always hard mount the mecanum wheels to the frame, and never have them dangling on the end of a pivot arm.

Remember... The forces generated by a single mechanum wheel are always at 45 degrees to its facing direction. (The thrust vector is always along the wheel's roller axle direction, as viewed touching the floor, not the top of the wheel.)

That means for every pound of thrust forward or backward, there is also a pound of thrust SIDEWAYS applied to the frame. Therefore, placing it on the end of a pivoting arm adds significant moment arm sideways forces to the pivot joint. IOW, under normal operation, a mecanum wheel at the end of an arm is always trying to BEND your drop arm SIDEWAYS... (Not a good idea...)

OTOH, when you place the mecanum wheel at the chassis and the BARREL on the end of the pivoting assembly, the barrel always applies its reaction thrust along the direction of motion, which is then transferred directly along the side plates of the assembly back to the axle, very near to where it connects to the base frame. NOW the only sideways torque is when someone crashes into you and pushes your bot from the side... (Oh yea... Be sure to remember to design to accept that! )

BTW... This also means you in addition to the normal roller bearings, all mecanum wheel stacks (whether pivoting or not) should also always include Thrust Bearings in its design. Simply place one on on each side of each mecanum wheel before adding your spacers. They are not that expensive. This keeps you from losing efficiency from side force friction of the mecanum wheel pressing against the frame, and therefore helps assist in transferring maximum vector thrust force to the frame with the least loss.

I hope this helps!

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

[yara92]

Madison
THANK YOU SO MUCH! allways you have nice things

[RyanCahoon]

Originally Posted by kmcclary

IMHO, you should always hard mount the mecanum wheels to the frame, and never have them dangling on the end of a pivot arm.

Definitely good points to raise, but I imagine you would see similar kinds of (and perhaps even greater in magnitude) stresses by putting the traction wheels on the end of the pivot arm and then being pushed sideways by a robot playing defense against you. Either way, you definitely want your frame to be pretty tough.

Empirically, 488 has experience making pivoting suspensions. Their mecanum prototype utilizing tennis balls is rather infamous among the Western WA teams.

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

[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 Posted by kmcclary
> IMHO, you should always hard mount the mecanum wheels to the frame, and never have them dangling on the end of a pivot arm.

Originally Posted by RyanCahoon

Definitely good points to raise, but I imagine you would see similar kinds of (and perhaps even greater in magnitude) stresses by putting the traction wheels on the end of the pivot arm and then being pushed sideways by a robot playing defense against you. Either way, you definitely want your frame to be pretty tough.

Ah, but I still stand by my original statement(s) (including the comment in my previous post saying that yea, your design also must consider being pushed sideways... )

Note that when mecanums run, they are ALWAYS pushing sideways on the frame, just as much as they push forwards and backwards. If they're on the end of the descending sub-frame, they will ALWAYS be pushing it from side to side, and trying to bend them. That's a LOT of stress, under just NORMAL operation.

Therefore, I still feel the the BEST choice is to always mount the mec's axles AT the chassis' main plane, and immediately couple this side-to-side force directly to the frame with thrust bearings. This greatly increases the mec's effectiveness, and totally unloads your motors from any mec wheel generated side friction, from its basic operation.

The thrust bearings also helps prevent the mec wheels from BINDING UP when being attacked sideways while using them.

Note also (assuming you are only using the barrels for F/B pushing, and are not trying to skid-turn the bot with them) that significant side forces on the descending barrels ONLY exist when you are being pushed sideways by another robot. In that case, you wish the sub-frame and main chassis to act as a single SOLID.

Therefore, the goal is to eliminate any GAP between the sub-frame and the main chassis, WITHOUT introducing friction while changing wheel types.

There is a simple solution for dealing with that (and side attacks)...
Attach a pair of Delrin (Acetal Resin) blocks to the main frame, one on either side of the descending sub-frame, to take up any gap between the main chassis and the descending sub-frame. (Put a little radius on the leading and trailing edges.)

Now, whenever you are pushed sideways, the descending sub-frame "leans against" the Delrin blocks, preventing deflection, bending, and/or damage, and immediately couples the barrel's tractive force, to resist the attack. (It also helps protect the sub-frames should you DO try to turn the bot on the 4 barrels. )

Using Delrin or HDPE for these Skid Blocks gives you the "slipperiness" necessary to allow you to easily "change wheels" while being attacked without binding, for escape, or other action. Just make sure there are no protruding screw heads on the sub-frame to catch the pads (or simply notch out the blocks to allow them to pass by...)

Given a smidgen of clearance between the sub-frame and the blocks, they only come into play when you're being pushed sideways, to add side support and provide a bearing surface to the sub-frame.

IOW, IMHO it's not worth the time, weight or complexity of messing with adding side "follower wheels" to the chassis (or sub-frame) just to support the far end of the descending sub-frame from side to side forces while changing wheel types. IMHO using Skid Pads that come into play whenever necessary is a much simpler, and lighter solution.

Does this make sense?

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

[Dad1279]

If you look at one of the modules we used last year, we mounted the transmissions directly driving the traction wheels to the chassis. The mecanum wheel modules pivoted on this axle, with acetal slides mounted alongside the wheel modules near the mecanum axle.

This worked fine for two regionals, through considerable robot-robot interaction, and a few off-seasons, demos, and testing this year.

With the higher COF, the traction wheels would put more sideways 'force' on the chassis, when being pushed sideways. I haven't measured it, but it takes considerable more force to push a roughtop traction wheel sideways than a robot on mecanums.

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