pic: FRC488's Octocanum Ver 2.0

Did you take advantage of both output rates? As in, only referencing the faster output when the slower output was saturated (or some more intelligent way of mixing them)?

We did that for a time, but it turned out the finer resolution was overkill and a bit noisy. The lower resolution (500 deg/sec max output) was accurate enough.

Actually, I thought the gyro was broken, because sometimes it wouldn’t drift at all for long periods of time. Then I’d kick the robot and see it respond. The gyro combined with the default gyro libraries from WPI worked pretty well.

This is probably due to two features of your gyro:

  1. The bandwidth of the gyro as implemented on that evaluation board.
  2. The “auto zero” function, which apparently uses Vref to provide a dynamic estimate of what the true bias is (if you used this feature)

Sorry for taking so long to reply – I’ve been pretending to be very busy. Let me try to address some of the non-programming-related questions.

We’ll implement it if it’s right for the game. A design like this obviously favors a flat, open field; though it can navigate ramps pretty safely. Platforms, stairs and varying surfaces may make things more challenging.

  1. It uses a KoP frame as its main frame, but nothing else is really from the KoP.

  • The gearboxes are AndyMark ToughBox Nanos with the long hex output shaft option and gearing of 8.46:1.
  • The wheels are AndyMark 6" mecanum wheels and 4" Plaction wheels. Sprockets are AM 16 tooth hex broached sprockets on the gearbox output and 36 tooth hubless sprockets on the traction wheels.
  • The subframe is 1x1x.125" aluminum angle surrounding McMaster-Carr #92985T25.
  • The mecanum wheels are driven by an AM hex broached hub. The plaction wheels ride on AM hex bearings. The wheel modules pivot on hex bearings.
  • The plaction wheel axle is a 1/2" hex standoff – McMaster-Carr #92230A335
  • The wheel module sides are laser cut 1/4" ABS with .5x.5.x.125" aluminum angle for rigidity
  • 1.5" bore pneumatic actuators with a 3" stroke to actuate the drive. I want to use spring-return actuators here but don’t know if they’ll be legal.
  1. This should be very easy to assemble, generally speaking. The most difficult parts to deal with are the wheel module sides. Last season, we used 2x1x.125" channel there, but because the gearbox was driving the mecanum wheels via chain, everything was a dead axle. Here, the mecanum is driven via live axle and thus requires bearings in the wheel module sides so that the plaction wheels can be rotated down efficiently. The manufacture it the way I’ve shown, you’d need some ability to CNC plastic/aluminum or otherwise to mill accurate bearing pockets.

  2. Maybe. There are still details absent from the model. If I ever get those in place, I’ll share the CAD models.

I aimed for simplicity in the design, so because we want the mecanum wheels to be the fast travel wheels, they end up higher in the gearing. They’re geared at 8.46:1 and the plaction wheels are geared at 19:1 (in addition to being smaller). There aren’t any reasonable, commercially available gearboxes that have a final ratio of 19:1, so to get we want out of the traction wheels, we’d run into a bunch of complications in our gearbox selection and then we’d have to gear up again to get the mecanum wheels going at the desired speed.

It’s possible to drive the pivoting wheels first, I’m sure, either by allowing the entire gearbox to move when the wheelsets actuate or by devising a system that allows the chain length to vary as the distance from gearbox output to wheel changes. I’ve done the latter (about ten years ago) and would rather avoid doing it again. The former is probably achievable, but I feel that it’ll complicate the frame design more than I’d like and we didn’t have discernable trouble last season with rigidly mounted mecanum wheels, so I’m happy to do it again.

The switch can happen at full speed and takes a fraction of a second. We had a small compressor on-board last season and a single Parker accumulator, both feeding the actuation cylinders – two 1.5" bore, 3" stroke – and a single gripped actuator (about 1.5" bore, 9" stroke). We never had problems having enough air in reserve.

First off–very nice design, and very accessible. We’re not very capable in terms of build complexity, but might prototype something like this next season.

One of our main concerns is the side loading.

Is this also intended to handle some of the sideways forces that the wheel assemblies would encounter if a robot hit from the side while in traction mode? It appears that the subframe and wheel assembly are flush, so I assumed that was an additional purpose?

If I recall, from octocanum v1.0 I saw video of you testing side loading by deploying traction while strafing. Did you run into any problems with this during last year’s competition?

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


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!)

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

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). :slight_smile:

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! :D)

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 —

THANK YOU SO MUCH! allways you have nice things

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.

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.

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?

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.

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

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.

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… :D)

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 —

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.

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?

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… :eek:
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.

:)… 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”… :D), 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 —

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.