Coaxial Swerve Derivation with Paired Modules
 

Our team is looking at different swerve variations and considering trying one in the off season.

Ether was nice enough to do the derivations for equations and wheel speeds and post them in an excel format for unicorn drives, and straight up "crab" where all the modules are linked is simple to program.

Has anyone performed a similar variation for a paired-module swerve where 2 have 2 sets of modules, when each set has linked steering and drive?

To more explicit, picture 4 modules where the left side modules are turned and driven together, and the right side modules are turned and driven together.

Re: Coaxial Swerve Derivation with Paired Modules
 

190 did this in 2009. It's basically tank that can strafe and gave us pretty good mobility for the motor choices we had that year.

Nowadays, with the amount of motors you can pick from, the benefits of full swerve outweigh the drawbacks.

Re: Coaxial Swerve Derivation with Paired Modules
 

1983 also did this in 2009. Ty is right, with the amount of similar motors a full swerve would be the way to go if you are confident you can build it and control it.

Re: Coaxial Swerve Derivation with Paired Modules
 

I'm going to respectfully disagree. I've seen veteran teams sit idle for matches because of their swerve drives, for trivial reasons (e.g. the wheels weren't properly aligned at the start of the match).

At any rate, every game deserves thorough evaluation on the pros and cons of each drive train, because ultimately propellers will rule when it's a water game.
:p

Re: Coaxial Swerve Derivation with Paired Modules
 

I think his point was that if you have the capability to build a functional swerve drive, would there be an advantage do pairing modules together in pairs, rather than all together, or all independent, and how to implement this. In the high majority of cases I doubt running modules in pairs instead of independently would cause a team's robot to sit idle in a match. That would be more due to the overall fact that the team wasn't able to get swerve running properly in general.

I cannot speak to what the pros and cons of running them in pairs would be. We ran all 4 of our modules independently this year. Off the top of my head the only advantage I can see to pairing instead of all independent is using two less motors, but at this point with the number of motors available and the weight that teams have been able to get their swerve drives down to, that doesn't seem like a huge plus.

-Nick

Re: Coaxial Swerve Derivation with Paired Modules
 

I agree with others.

Full independant is mechanically easier and it lets your 4 corners exist in isolation from each other.

Also, it's trivially heavier as you're not linking power transmission over long distance, so you eliminate all that weight (but do add two motors at .5 lbs each + gearing).

Re: Coaxial Swerve Derivation with Paired Modules
 

Some benefits of pairing swerve modules would be:
* Ability to drive (2) swerves with (3) CIMS
* Easier to add gear shift

But, what kind of drive action/control are you seeking: Crab or Snake? Either could be accomplished through pairing, but not both together.

For example of crab & snake, see:
http://www.chiefdelphi.com/media/papers/2400
http://www.chiefdelphi.com/media/papers/2401

Re: Coaxial Swerve Derivation with Paired Modules
 

This is one of the reasons we were considering looking at two pairs...we wanted to see about getting 6 CIMS to power the 4 wheels.

Re: Coaxial Swerve Derivation with Paired Modules
 

Yep, read that in a different context. Thanks for shining a different light on it.

Re: Coaxial Swerve Derivation with Paired Modules
 

Why do you want 6 cims for a swerve drive? It seems a bit over kill when a swerve is best at out maneuvering not out pushing/running.
You could try a 3 wheel 6 cim having the best out of both worlds.

Re: Coaxial Swerve Derivation with Paired Modules
 

6 CIM drives really aren't about pushing harder; they don't, at least not with shifters. They're about accelerating better when geared for a high speed at full weight. A swerve that accelerates more slowly than the standard tank drive would be less agile - this would be bad for outmanuvering.

Re: Coaxial Swerve Derivation with Paired Modules
 

6 cims is not for pushing, because the 120a breaker basically limits your torque, even if it delays a few seconds. Your wheels will lift before that happens at lower speeds (~7fps IIRC). It does, however, give you much better acceleration.
The main problem with a 6 cim swerve is that you lose all your cims that could go to a manipulator. Plus, you either have to do a central gearbox or go with a 6-module swerve.
Using centralized gearboxes saves weight (chain weighs very little as a matter of fact) but at the cost of not being able to do complex maneuvers. For programming purposes, a simple crab would work better in my opinion, but mechanically it will be hell to line them up due to chain spacing.

The chain for crabs also has to be designed around for anything that goes above the chassis. The high number of chains also can lead to faster breaks, so using #35 chain could be an advantage maintanence wise.
Chain weight is 0.087lbs for #25, 1.8lbs for #35 per foot.

One way to line up swerve modules is to stretch a piece of surgical tubing between the end of one wheel's axle to the end of another and tie it off there. That keeps both wheel facing forwards. Then you calibrate at 0, and remove the tubing.

Re: Coaxial Swerve Derivation with Paired Modules
 

How do you get "much better acceleration" if you don't have more torque?

Re: Coaxial Swerve Derivation with Paired Modules
 

This. Without more torque, then there is no reason why your wheel spin-up would be decreased, thus helping your acceleration. What's your reasoning behnd saying you do not get more torque?

I think some teams on Einstein this season would have disagreed with you.

-Nick

Re: Coaxial Swerve Derivation with Paired Modules
 

I think the reason a 6 cim drive gives you more acceleration is because it spikes the current initially. I'm not 100% sure why it is faster at accelerating (it definitely is though, one of parents did some calculations) but that would be my guess.
It won't help in a pushing match because the current spike will just kill you, because the current will not decrease over time like when you start driving. Insert blown breaker here.
The reason I say torque is limited is because torque is directly related to current on a motor. Because we have (usually) a maximum 120a-180a going to all cims, and the stall current on each cim is 133a, you are not getting more torque. The delayed blow on the breaker will allow the current to spike for all the cims, giving you a torque boost with more cims, but it can't hold those current levels for long. So the max torque cap is pretty much the same if you don't want to blow breakers.

Torque is also inversely proportional to speed in electric motors, so having 6 cims divvy up a given amount of current (torque) will increase their speed as well compared to 4 cims.

Let me rephrase what I said about manipulators:
6-cim drivetrains are fine. You are still left with many motors for doing all kinds of stuff on the robot. However, when you have a bunch of turning motors too (which you will want, crab or swerve) then you end up being left with some wimpier motors. On a single centralized turning gearbox, it might not be a problem, but if you want to turn the modules quickly then you would want more than 1 turning motor there.

Just my opinion of course. 6 cim swerves have been done in the past, and have done beautifully. However, in my opinion, it doesn't matter what you pick as long as it's excecuted well and you get driver practice. Focus more on the little picture.

Re: Coaxial Swerve Derivation with Paired Modules
 

Using the above logic, a 6 CIM drive should have a 50% faster top speed compared to a 4 CIM drive, all else being equal.

Re: Coaxial Swerve Derivation with Paired Modules
 

It's been a while since I've done the math, perhaps those with more recent, published models can confirm. This is all based off my intuition.

Since you have a 4 wheel drive, put 2 CIMs on modules in opposite corners, with 1 CIM in each of the other corners. The power you're supplying to your wheels should still be balanced on either side, regardless of the direction of movement which is defining said "sides" at any given time.

Adding in arbitrary rotation on top of translation complicates things a bit, since now the power available to pull off the rotation will depend on how far each "unit" of power is from the center of rotation. In particular, if you're spinning about one of your modules, if it's a 1 CIM module, you have 5 CIMs available to do the maneuver, while if it's a 2 CIM module, you only have 4 across the other 3 modules. If you spin about a point away from all the modules, you have all 6 CIMs available. A 4 CIM, 4 wheel swerve also fails to have this type of symmetry, but to a lesser extent.

In any case, a good speed control loop will ensure you still get the desired motion, but the max acceleration and force with which you can perform a maneuver may vary because of the loss of symmetry. Since a good swerve will require extensive off season testing anyway, I'd recommend trying this out so you don't have to try transferring power between modules, and seeing if the performance is acceptable.

Or go 3 wheel :)

Re: Coaxial Swerve Derivation with Paired Modules
 

For the kinematics: first take the equations for 4 wheels. A wheel's velocity is given by:



where i is the index of the wheel, r is its position vector relative to robot center, v is the velocity of the robot, omega is the rotation of the robot (counterclockwise around robot center). However, by pairing up modules, you introduce further constraints on magnitudes and directions of wheel velocities. In your case, you are requiring for some pair i,j:



or very close to zero (the wheels are allowed to scrub a little). But this means either you aren't turning very much at all, or your paired wheels are nearly on top of each other.

For other pairings you can follow a similar process to figure out what motions are still allowed. Calculate wheel speeds and directions as you would normally, then average them for each pair output, so that the pair outputs are the same, and it should work, though some motions may not be possible.

I believe it was 2451 who had a nice table of all the different ways to pair up modules for both power and steering, and the motions it allowed. I've been unable to find this anywhere online however, so I must have seen it in their pit. The paper by Nate Laverdure posted below is what I was thinking of.

Re: Coaxial Swerve Derivation with Paired Modules
 

http://www.chiefdelphi.com/media/papers/2785 is a tremendously useful paper that outlines pretty much every possible combination of steering and powering modules, including a list of possible maneuvers by combination and notable examples.

The configuration that you're describing is the one labeled {5}. As mentioned earlier in this thread, it is basically a 4 wheeled tank that can translate, meaning that to spin in place you'll have a bit of scrub. One way to avoid this is configuration {13} which powers each side together but links steering modules on the diagonal. This retains the ability to strafe in an arbitrary direction but does a much better job at spinning in place. Check out team 1717 in 2011 for an example of this.

I would tend to agree with other posters in this thread and say that if you're planning on going through with a swerve, assuming the motor rules stay as lax as they are, it wouldn't be a huge step up to just go for 4 independently powered and steered modules.

I would also recommend, if you have the resources to do so (which is a decent amount of money), buying a set of revolution modules from 221 robotic systems and throwing together a chassis to give to your programmers as soon as possible. The biggest hurdle with swerve tends to be software and implementation of controls, as there are tons of resources available mechanically (221 posts cad on their website, team 1640's wiki is incredible, 973 has swerve cad on their website, etc.).

Re: Coaxial Swerve Derivation with Paired Modules
 

Hm, that's correct. How would you explain it then? 6 cims definitely increase acceleration.
However, I stand by by statement that torque is limited by the breaker.

Re: Coaxial Swerve Derivation with Paired Modules
 

You can pull huge amounts of current for a short amount of time without tripping the breaker.

Source: http://www.cooperindustries.com/cont...UITBREAKER.pdf

Re: Coaxial Swerve Derivation with Paired Modules
 

At a given voltage and speed, 6 CIMs draw more current than 4. More current means more torque. More torque means more acceleration.

As the speed approaches motor free speed (for the given voltage), current draw approaches zero no matter how many motors you have (due to back emf).


With 6 CIMs you also have 6 40-amp breakers, so the associated total current limit increases. And the main breaker is slow acting - it can sustain high overcurents for a significant duration.

Re: Coaxial Swerve Derivation with Paired Modules
 

I still don't buy it. Even if you somehow manage to allocate 6 cims and 4 turning motors (say Banebots), you still have 4 Minicims/Bags, and 4 AM 9015's, in addition to many other motors of decreasing value.

Get back to me when you find a need for 18 motors.

Re: Coaxial Swerve Derivation with Paired Modules
 

Further detail for those interested:

Drivetrain Full-Throttle Acceleration Simulation Model with traction limiting and voltage drops:

http://www.chiefdelphi.com/media/papers/2868

see these attachments:

PDF Drivetrain Acceleration 2013-09-25 RevC

Derivation of Voltage Drop Model rev E

C source Drivetrain Acceleration 2013-09-24_2231

See attached chart of accel vs speed for one set of model parameters, using data generated with attachment ready-to-run model 2013-12-18

You can change the parameters to whatever you think is appropriate for your drivetrain and run the model to see how they affect the performance.

Re: Coaxial Swerve Derivation with Paired Modules
 

The potentially big issue with a 10 motor drive on the new control system is only having 16 slots on the odb. 6 motors might not be enough for the rest of the bot.

Re: Coaxial Swerve Derivation with Paired Modules
 

Still leaves enough for 2 motors to each of 3 additional degrees of freedom. We usually only have 2 additional motor powered degrees of freedom. And you can always go 1 motor on a degree of freedom. Besides the fact that pneumatics are most of the time a better option. So I'm not super worried.

Also, 3 wheel swerve only has 3 turning motors ;)

Re: Coaxial Swerve Derivation with Paired Modules
 

The new PDB is loosing 4 20/30A slots, but none are required for the control system.

Currently you need to power at least the sidecar and analog breakout, and sometimes a solenoid breakout and a compressor, so you're effecivly loosing 2 ports without pneumatics, no ports with pneumatics.

See attached image.

Re: Coaxial Swerve Derivation with Paired Modules
 

In 2011 we did a 2 speed coaxial crab ( fronts paired, backs paired ), I'll try to find some pics/CAD.

Re: Coaxial Swerve Derivation with Paired Modules
 

Hmm. I thought I'd get some comments or questions about the shape of the 6CIM accel curve.

Re: Coaxial Swerve Derivation with Paired Modules
 

If I'm guessing correctly, the cusp is due to the transition between traction-limited and motor-limited. The 4CIM at that gearing is never traction-limited so there is no cusp. For a different gearing you might see an identical plateau at the beginning for the 4CIM, but it would drop off sooner.

I wonder why there is a slight decrease in acceleration while traction-limited as the speed increases, though?

Re: Coaxial Swerve Derivation with Paired Modules
 

Correct.

Yes, that's the one I was expecting to get questioned about.

See if you can figure it out with the following hint: Notice that Krv is set to a non-zero value.

Re: Coaxial Swerve Derivation with Paired Modules
 

Ah. The rolling friction losses are being applied (incorrectly, I'd think) even when the wheels are slipping.

Re: Coaxial Swerve Derivation with Paired Modules
 

It's not incorrect if you look closely at what Krv is supposed to be. It's supposed to be rolling resistance force proportional to vehicle speed (not wheel speed).

Re: Coaxial Swerve Derivation with Paired Modules
 

Yes; I meant incorrect compared to what is actually physically happening.

I imagine even if you corrected it to be wheel speed it would not be quite right, since it's supposed to be accounting for rolling friction losses, and clearly the physics are pretty different when you're slipping the wheels from when you're rolling.

Re: Coaxial Swerve Derivation with Paired Modules
 

What is actually physically happening is quite complex, and the model provides 3 parameters to attempt to model it: Kf, Kro, and Krv.

You can set the values of these parameters to whatever you believe best reflects the physics.

Wind resistance depends on vehicle speed, not wheel speed. The force required to plow through the carpet arguably depends more on vehicle speed than wheel speed. You can use Krv to attempt to account for those effects.

That is true, and the friction model used attempts to account for these differences. Friction models are notoriously tricky. In this model, I used a "standard" static/kinetic friction model... so when the wheels are slipping, the torque on the wheels is constant at uk*normal_force*radius, and the wheels will be spinning at whatever speed that corresponds to on their torque vs speed curve, at the voltage derated for resistance losses in the circuit. When the vehicle speed finally catches up to wheel speed, the friction model transitions to static friction.

Re: Coaxial Swerve Derivation with Paired Modules
 

I'd naively think that when you're slipping the wheels you wouldn't have much of an effect from vehicle speed at all; in the reference frame of the wheel, the only thing vehicle speed does is decrease the effective rotational speed of the wheel (almost negligibly at those speeds, at that). It's not clear what effect that would actually have on the force generated by the wheel.

Re: Coaxial Swerve Derivation with Paired Modules
 

As I stated in the previous post, the force exerted on the wheel by kinetic friction with the carpet is modeled to be constant (independent of relative slip speed) when the wheel is slipping.

But the acceleration of the vehicle depends on the net external force on the vehicle, not just the kinetic friction force of the carpet acting on the wheel.

Krv allows you to account for that. A robot with a large "shot-blocking shield" for example could generate windage force. The carpet could generate speed-dependent force to plow through it.

I'm not claiming that 0.5 is a "typical" value for Krv. AFAIK, nobody yet has empirical data to establish a typical value. But if there is a vehicle-speed-dependent force resisting the robot motion, Krv is there in an attempt to model it. The model is a teaching tool - it allows you to see what effect a vehicle-speed-dependent resisting force has on robot acceleration.

I'd be willing to bet that if someone ever runs some precision tests of robot acceleration with wheels slipping over a sufficient speed range, it will show a decrease in acceleration with speed as shown in the plot (i.e., Krv>0).

I've attached a plot showing the effect of changing Krv to 0 (notice the flat line when the wheels are slipping), and of changing μ_s to 2 (not realistic I know, but it shows what the 6CIM would do if not traction limited).

Re: Coaxial Swerve Derivation with Paired Modules
 

This is where I'm not following. If the wheels are slipping, then the wheels are never "plowing through carpet" in that direction; they're plowing in the opposite direction, but plowing less as speed increases. I do not think it is obvious that this will necessarily decrease the acceleration of the robot, or that the robot-speed model that you use to calculate the drag of moving through carpet when rolling is at all valid in that situation.

I need to go to bed, but I'll draw some pictures tomorrow to explain my confusion.