pic: FRC488's Octocanum Ver 2.0
 

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

2. What are the final gear ratios to each set of wheels?

3. Why did you choose to build under the kit frame instead of on top of it?What's the sub-frame made out of?

Re: pic: FRC488's Octocanum Ver 2.0
 

What mecanum wheels are you using, why did you select them, and what (if any) issues have you had with them?

What makes your mecanum implementation better?

Re: pic: FRC488's Octocanum Ver 2.0
 

We pivot the traction wheels down for a few reasons. First, by putting them nearer to the center of the machine, it makes turning with four high-traction wheels a bit easier to accomplish. We also gear down further to that wheel set, so it makes sense for it to be at the end of the gear train.

The gear ratios are 8.45:1 at the mecanum wheels -- that's one of the options for the Toughbox Nano -- and about 25:1 at the traction wheels. The traction wheel ratio makes things pretty slow, but it's easy to swap in sprockets to speed things up as required.

The kit frame is 1.25" thick and the output of Toughbox is 1.5" from its edge, so when using a 6" mecanum wheel, we'd end up with just .25" of ground clearance if we built things the other way around.

The subframe, right now, is 1x1x.125" angle bolted to the perimeter of a .125" perforated PVC sheet and hung from the Toughbox Nano housings. It is intended to hold electronics and would need to be enhanced if it were going to see more substantial loading.

This is based on AndyMark 6" mecanum wheels -- http://www.andymark.com/product-p/am-0136.htm

We used this last season and I'm happy with the build quality and performance. They're heavy, but they're not as heavy as the 8" set we originally played with years ago and we're willing to deal with the weight and cost in place of building our own.

Our mecanum implementation worked. I didn't program it, so I can't speak too much to what made it work, but our programming team did a fantastic job there. We had accurate, fast, field-oriented drive that allowed us to fully use the movement capabilities of the mecanum wheel set. In my experience, most teams fail to achieve the level of control we managed.

Re: pic: FRC488's Octocanum Ver 2.0
 

Thanks that cleared some things up.

Are the wheel assemblies and bearing blocks the only machined parts?

How do you avoid compressing the C-channel when you bolt the tough-boxes through it?

Re: pic: FRC488's Octocanum Ver 2.0
 

The wheel assemblies are 1/4" ABS with .5x.5x.125" angle added for rigidity. We can laser cut the ABS parts in a few minutes; then it's simply a matter of cutting the angle to length and match drilling it to the ABS.

The bearing blocks are of similar construction, but are really ugly right now. I'm still working on those.

If possible, we'll bolt the transmissions through just one wall of the C-channel. Otherwise, we'll laser cut 1/2" ABS inserts to stick inside the C-channel to prevent it from buckling where it's bolted through.

Re: pic: FRC488's Octocanum Ver 2.0
 

Woah.....

I have seen many amazing drive trains in my time (and I mean MANY), but this is just AMAZING! I love the idea! Are you going to implement it next year?

Just some questions:

1. How many KoP parts does it use?
2. How many other parts?
2.5 Where can these parts be obtained?
3. How easy is this to make (during build season, with a team of builders)
4. Is it open source? ;)

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

^ Those help too. :)

Re: pic: FRC488's Octocanum Ver 2.0
 

Comments/ questions are bolded

Overall, very cool. I'm a fan of the ability to quickly strafe in any direction, to hold your ground when pushing, and with proper programming basically what amounts to a shifting drivetrain. Looks like you have a good thing going here. :)

Re: pic: FRC488's Octocanum Ver 2.0
 

Any thought into making the Mecanum wheels the pivoting ones?? Our team last year developed some CAD prototypes for this combination, and eventually didn't implement it due to the added complexity. However, we did use mecanum last year, and didn't have a great experience with it. I think one of the biggest problems we saw (other then malfunctioning Jaguars...), was that when all four wheels were not on the ground (due to an un-even playing field, and seams in the carpet) the controllability of the system declined, and even worse the power of the drive system declined. Some of this we could correct with programing, but loss in power and acceleration was really noticeable. The loss in acceleration is I believe the biggest downside of using mecanum, the reality I saw was that our robot was just far slower in accelerating, changing direction, and stopping (decelleration) then high traction based drive systems.

I was wondering if you pivoted around the traction wheels instead of the Mecanum wheels in the octocanum, if you would see any advantages because the pistons could act as a suspension system. I've been told that mecanum drive systems perform better with a suspension system, I would be interested in hearing from teams that have used suspension in their mecanum drives. But for me I would need to see a big improvement in acceleration/deceleration to advocate for using mecanum again.

Re: pic: FRC488's Octocanum Ver 2.0
 

What do you think would cause a mecanum to stop unacceptably slowly?

Are you saying it slides across the carpet when you try to stop quickly?

Do you have any video showing this?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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" ?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

I like it. Nicely done.

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

The point midway between the translation follower wheels was said to be the center of rotation of the vehicle. To the extent that is true^*, you could extract vehicle rotation while translating.


^*The center of rotation likely shifts around especially if weight distribution changes as manipulators move.

Re: pic: FRC488's Octocanum Ver 2.0
 

Wouldn't that only be true while not translating? Translating would shift the center of rotation, would it not?

Re: pic: FRC488's Octocanum Ver 2.0
 

What's the maximum speed at which you can switch between Mecanums and high-traction wheels? Plus, about many switches can be performed before there becomes a serious air deficiency such that it is unreasonable to switch at all, assuming you have about 3-4 tanks at 120 PSI at the start.

Re: pic: FRC488's Octocanum Ver 2.0
 

Imagine a robot going around a circular track at constant speed such that it completes one lap every minute. The robot has a gyro mounted on it. The gyro rate will be 1 rpm, the same as if the robot were spinning in-place at 1 rpm.

I'll have to check the math, but I believe that with 3 followers mounted as shown, you can extract the vehicle's rotation rate (the same rate measure by a gyro) for any vehicle motion.

Re: pic: FRC488's Octocanum Ver 2.0
 

Yes, but that's with 3 follower wheels. 488 only has two follower wheels measuring the floor, so I was clarifying as our swerve has two and there is no way we could infer rate from that (in fact we have to factor in the gyro rotation rate to even to get an accurate linear velocity).

EDIT: 488 actually has three follower wheels in that diagram, I was mistaken. Trivial calculation in that case.

Re: pic: FRC488's Octocanum Ver 2.0
 

Ether,

We tried Mecanum wheels and tried field oriented drive. It was a good exercise for our programmer who did it all on his own. It would work for 10 to 15 seconds and then the headings will be off. I think it is because of gyro drift. We use the gyro that comes in the KOP. Is there a better one that we should use? We tried a compass sensor but there is too much electro magnetic interference from the motors. Any help would be appreciated.

Re: pic: FRC488's Octocanum Ver 2.0
 

We're still waiting for JohnGilb to tell us what sensor his team used.

How about it, John? :-)

Re: pic: FRC488's Octocanum Ver 2.0
 

The Discobots used the kit gyro last year to do field oriented drive on our omni-drive. We didn't have to much issues with drift over the duration of the match. We did have it setup so that the driver could zero the gyro him self at any of the cardinal directions but he only needed to use it in a few matches.

Our biggest problem with the kit gyro was the initial calibration routine we were dead in the water during a few elimination matches at Lone Star because we didn't let the robot sit still when we turned it on.

Re: pic: FRC488's Octocanum Ver 2.0
 

I've sent an email to the electrical lead on our team, I'll let you know once he digs up the model number of our gyro. =]

Re: pic: FRC488's Octocanum Ver 2.0
 

YMMV, but we used 1 tank, (2) 1.5" bore, 2" stroke cylinders to switch between traction & mecanums, (2) .75" (6 or 8" stroke) to lift claw, and 2 small cylinders to deploy the minibot, and never had a want for more air.

Re: pic: FRC488's Octocanum Ver 2.0
 

That is what we did. Not necessarily for the suspension, but we wanted the traction wheels to be the most outward wheels for stability, and on the the fixed axles for strength. Also, if there was an pneumatic failure, we wanted the default wheels to be the traction wheels.

Not shown in the sketch below, the pistons were vertical, one on each side, and they pushed down where the front and rear pivot arms met in the center of the robot. We used the 8" Andymark wheels, not by preference, but budget. We had a new, unused set on the shelf as spares from the prior year. Also not shown below, the transmissions and outer axle bearing were rigidly mounted to chassis.

Yes, 8 motors on drivetrain, 1 CIM and 1 CIM-U-LATOR/775 per wheel.



While I personally preferred the field-orientated driving, unfortunately (for me) mentors don't drive. Our driver preferred traditional controls, so that his orientation didn't change when swapping between traction and mecanums.

Re: pic: FRC488's Octocanum Ver 2.0
 

You could do something like 451's SOAD - Semi Omni Arcade Drive.

Re: pic: FRC488's Octocanum Ver 2.0
 

So, our electrical mentor says we used http://www.sparkfun.com/products/9410, and it looks pretty familiar.

Re: 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)?

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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)

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

2.

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

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

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

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!

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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

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

Re: pic: FRC488's Octocanum Ver 2.0
 

Madison
THANK YOU SO MUCH! allways you have nice things

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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?

Re: pic: FRC488's Octocanum Ver 2.0
 

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? ;)

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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.

Re: pic: FRC488's Octocanum Ver 2.0
 

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

Re: pic: FRC488's Octocanum Ver 2.0
 

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.