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?