|
|
|
![]() |
|
|||||||
|
||||||||
I wanted to see how small a swerve could be if it was a CIM in wheel design, but using a mini CIM. Ill admit that this design didn't turn out as well as I was hoping, so I haven't filled in some of the details. Even still, I though it might be interesting enough to post. Let me know what you think about it, or if you have any questions.
It's about 4.5'' tall, and inventor says that it should weigh 4.6 lbs per module.
07-05-2015 23:45
asid614.6lbs per module? I think you've finally made a swerve that can be lighter than a WCD.
Much applause.
Is the two-plate design lighter than just flipping the motor over and using a planetary gearbox?
EDIT: Is that a custom gear on the bottom?
DOUBLEEDIT: Oh wait, MiniCIM. Dang, that was almost the dream.
08-05-2015 00:13
cad321Are you certain your materials are set correctly? A mini CIM weighs 2.16lbs according to VEX. If they are set correctly and that is in fact how light the module is, than I must say, very impressive.
08-05-2015 01:26
Bryce2471|
4.6lbs per module? I think you've finally made a swerve that can be lighter than a WCD.
Much applause. |
| Is the two-plate design lighter than just flipping the motor over and using a planetary gearbox? |
| EDIT: Is that a custom gear on the bottom? |
| DOUBLEEDIT: Oh wait, MiniCIM. Dang, that was almost the dream. |
|
Are you certain your materials are set correctly? A mini CIM weighs 2.16lbs according to VEX. If they are set correctly and that is in fact how light the module is, than I must say, very impressive.
|
08-05-2015 05:30
Clayton SummerallWhat motors turning the left right motion? Pg or 750 maybe?
08-05-2015 11:25
Bryce2471
08-05-2015 13:42
GeeTwo
|
i'm not sure about lighter, but I thought it would be a shame to put such a tall gearbox on such a short swerve module.
|
08-05-2015 13:46
aphelps231Great work, would you be willing to share STEP files so we could take a look?
08-05-2015 14:59
Ryan_Todd|
Also, what is the light colored gear to the lower right of the main rendering? I don't see what else it engages, and I also don't see it in the reflection.
|
08-05-2015 15:33
GeeTwo
|
From the looks of the reflection, I would say that it's paired with another pinion underneath the bottom support plate via a live axle, which in turn is what engages the great big ring gear that goes around the perimeter of the module.
That makes for a 3-stage reduction in total, so I am inclined to agree that a worm gear would be a viable option here. |
08-05-2015 20:11
InFlightBryce,
Really nice concept once again.
Are you using a Silver Thin Bearing to support the the pivot assembly?
The planetary drive inside the wheel is a great idea, are there two stages there for ~9x reduction?
09-05-2015 09:54
evanperryg|
Bryce,
Really nice concept once again. Are you using a Silver Thin Bearing to support the the pivot assembly? The planetary drive inside the wheel is a great idea, are there two stages there for ~9x reduction? |
09-05-2015 12:02
InFlightWith a large steering gear like that you can't use an absoule encoder.
Team 141 at championships had a similar large steering gear setup. They used an incremental encoder to count steering input revs, but also had a pivot extension that triggered a proximity switch to calibrate the nominal forward position. Really elegant and beautifully machined swerve drive. They used a Kaydon brand bearing, very similar to the Silverthin ones. I had the pleasure of talking with the 141 students and mentor for quite a while, really an exceptional team.
09-05-2015 12:52
Scott Kozutsky|
With a large steering gear like that you can't use an absoule encoder.
|
09-05-2015 13:12
sanddragOn 696, we had a large 84T 20DP steering gear, and a 1:3.5 ratio between that and our MA3 absolute encoder. That is, the steering encoder would pass through 3.5 rotations for every one rotation of the swerve module. We had to physically set the wheels pointing straight at the start of each match (which is probably good practice anyhow), and there was a good bit of math and code involved, but we were able to very reliably track the position of our wheels at all times, resulting in fine control and operation.
Was it easy or friendly to do it this way? No. Is it possible? Yes. Would we run anything other than a 1:1 ratio to an absolute encoder again? Maybe not. It's kind of a pain. We likely will look into using a zeroing sensor and incremental encoder next time if we cannot maintain a 1:1 ratio with an absolute encoder.
09-05-2015 13:33
Ether
09-05-2015 13:53
AlexanderTheOK|
If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then "all ya gotta do" at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.
|
09-05-2015 13:57
AdamHeard
|
I know sanddrag said that it worked well enough at competition, I have to say the headache caused by this is greater than he may have noted, and took a lot of time out of the season. It's generally just not a good idea to do incremental sensing of anything if it is at all possible to have absolute sensing. Zeroing sensors are a must.
|
09-05-2015 14:01
Ether|
If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then "all ya gotta do" at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.
|
D = B-A;
D -= 360*floor(0.5+D/360);
if((D>0)&&(A>B)) turns++;
else if((D<0)&&(A<B)) turns--;
09-05-2015 14:17
Bryce2471|
If you used a worm gear for steering, it seems to me that you could orient both motors horizontally and get the module height down to the wheel diameter. You'd also save some weight on a second gear stage at a bit of loss of steering efficiency.
|
|
Bryce,
Really nice concept once again. Are you using a Silver Thin Bearing to support the the pivot assembly? The planetary drive inside the wheel is a great idea, are there two stages there for ~9x reduction? |
|
With a large steering gear like that you can't use an absoule encoder.
Team 141 at championships had a similar large steering gear setup. They used an incremental encoder to count steering input revs, but also had a pivot extension that triggered a proximity switch to calibrate the nominal forward position. |
|
It appears there's an absolute encoder on the top of the entire module, likely connected by bent polycarb like 3928 and 2451 before them.
|
|
If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then "all ya gotta do" at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.
|
09-05-2015 14:28
Ether| Which would likely involve putting the swerve slightly to one side of "Straight" before every match, so that it's "zero" would be the real zero of the swerve, to begin with. |
09-05-2015 15:05
Bryce2471|
Would you please elaborate on this? It's not clear what problem you are trying to solve.
|
09-05-2015 15:10
Bryce2471|
If you embrace incremental, then it can be a huge time savings.
We never have to manually zero sensors, there are no magic numbers in code, and we know we can replace a sensor/system at any time with no new work required. Every position system 973 has ran all the way back to 2012 has been on an incremental sensor that assumes a zero at start (plus sometimes a manual or automated routine to hardstop zero). We always mean to add the zeroing sensors, but never do as the functionality isn't needed. |
09-05-2015 15:25
sanddrag|
If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then "all ya gotta do" at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.
|
09-05-2015 15:46
Ether|
I was trying to explain one way to make sure that the swerve zero is accurate before each match. If the software just takes the initial position as zero, then your wheels will have slightly different zeros each match because the wheels won't be perfictly lined up.
I was suggesting that you could have the software take the point where the encoder would read zero as the reference for the match. That way, you wouldn't have to worry about getting the swerves perfictly lined up before each match. I'm thinking that my explanation may still not be good enough, but let me know. |
09-05-2015 15:49
AdamHeard
|
I have found that with swerves, the small amount of accumulated drift from an incremental encoder is unexceptable. This is because it causes the wheels to fight each other, and makes the responce to driver input less predictable. I know you guys have run swerves in the past. Did you use incremental encoders? If so, how did you keep the drift down and zero them?
|
09-05-2015 15:57
Ether|
I have found that with swerves, the small amount of accumulated drift from an incremental encoder is unexceptable.
|
09-05-2015 16:31
Bryce2471|
You shouldn't be losing counts (which is why we love using them).
2) Voltage brownout causing the supply voltage to the encoders to drop out. We use a regulated supply for all of our encoders for this reason. |
10-05-2015 08:16
InFlightIf you could work out the incremental encoder setup, it would free you up to put a slip ring module at the top. That trade off would solve the motor wiring issue, and not restrict you to partial rotations.
10-05-2015 13:59
Bryce2471|
It's still unclear what problem you are trying to solve and what your suggested solution ("putting the swerve slightly to one side of "Straight" before every match, so that it's "zero" would be the real zero of the swerve, to begin with") is.
With absolute encoders for steering, there are at least two common ways to deal with steering alignment: hardware mounting calibration Mount, adjust, and lock down each steering encoder so that each encoder reads zero when its associated wheel is properly aligned. With this approach, there is no need to align the wheels perfectly at the start of a match. startup zero offset During setup for each match, carefully align the wheels to their zero steering position. At startup, read and store a zero offset reading for each steering encoder, and apply that offset to the encoder reading. |
|
If you are getting "drift" with an incremental encoder then you are probably doing something wrong.
Adam listed two likely causes. A third, fourth, fifth, and sixth might be 3) using an encoder outside its operating range (edges per second), 4) a damaged encoder (dirty / scratched optical disk), 5) improperly assembled / mounted (optical disk alignment / concentricity), and 6) incorrect programming (resetting the counts rather than letting the FPGA accumulator run freely). |
10-05-2015 14:49
Ether|
6) incorrect programming (resetting the counts rather than letting the FPGA accumulator run freely).
|
|
We used the WPI lib encoder software, so I'll hope it wasn't #6.
|
/**
* Reset the Encoder distance to zero. Resets the current count to zero on
* the encoder.
*/
public void reset() {
if (m_counter != null) {
m_counter.reset();
} else {
ByteBuffer status = ByteBuffer.allocateDirect(4);
// set the byte order
status.order(ByteOrder.LITTLE_ENDIAN);
EncoderJNI.resetEncoder(m_encoder, status.asIntBuffer());
HALUtil.checkStatus(status.asIntBuffer());
}
}
10-05-2015 15:35
Bryce2471|
I've seen code where the counts are read and then reset() every cycle. You can miss counts that way. I'm not saying that's what your code is doing... but if it is, that might explain your "drift".
|
10-05-2015 22:19
Chinske4296Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
11-05-2015 00:00
Navid Shafa|
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
|
11-05-2015 00:08
asid61|
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
|
11-05-2015 00:11
Dunngeon|
If you could work out the incremental encoder setup, it would free you up to put a slip ring module at the top. That trade off would solve the motor wiring issue, and not restrict you to partial rotations.
|
11-05-2015 00:30
GeeTwo
11-05-2015 01:24
InFlight
11-05-2015 01:26
Rachel Lim|
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
|
11-05-2015 11:37
Dunngeon|
There are quite a few Gold on Gold, or Silver on Silver contact designs that don't contain Mercury. The Wind turbine industry has lots of low cost high current options.
http://www.amazon.com/Sunwin-Wires-2...ords=Slip+ring Company Specs http://www.moflon.com/mw.php?a=1 Just one option, lots of other low cost (no-mercury) models. Moog would be nice, but really expensive. |
11-05-2015 11:53
Andrew Schreiber|
That slip ring you linked is only rated for 30A per the website, FRC rules require that it be rated for 40A if it's on the 40A breaker. I wouldn't want to put it on the 20A, for obvious power reasons. Which is why I've been looking for a low cost 40A Slip Ring. Unfortunately, I haven't been able to find any legal ones.
|
11-05-2015 15:14
Bryce2471|
I've found the weight estimates in SolidWorks to be pretty good (and I'd be surprised if Inventor is significantly worse). What I have realized is all the "small" parts we don't add in really add up. Doing a weight calculation for our intake arms this year, I realized that just the fact that we don't add bolts/nuts to assemblies made my estimate under by ~0.6-0.8lbs.
|
11-05-2015 15:40
InFlightYou may be able to find 40 amp slip rings, but all the ones I've seen are large and very expensive.
Both the M1330 and the MW1440 (4 wires, 30 amp per contact) both use 12 gage wire. Thus the wire size meets the R38 requirement for 40 amps.
R 37 states that you may use up to a 40 amp breaker for motor controllers, thus a 30 amp breaker to match the contacts is thus also permitted and fully compliant.
For a 40 amp rating; It seems like it could be permissible (R39) to splice two contacts in parallel (w/ MW1440) to achieve the 40+ amp load rating. Would be a good area for a rule interpretation, as it would make slip rings a more available and useable device.
[U]R39 Branch circuits may include intermediate elements such as COTS connectors, splices, COTS flexible/rolling/sliding contacts,
and COTS slip rings, as long as the entire electrical pathway is via appropriately gauged/rated elements.[/u]
Probably enough hijacking of this Swerve Drive thread on encoders and slip rings.
11-05-2015 18:25
Andrew Schreiber|
You may be able to find 40 amp slip rings, but all the ones I've seen are large and very expensive.
Both the M1330 and the MW1440 (4 wires, 30 amp per contact) both use 12 gage wire. Thus the wire size meets the R38 requirement for 40 amps. R 37 states that you may use up to a 40 amp breaker for motor controllers, thus a 30 amp breaker to match the contacts is thus also permitted and fully compliant. For a 40 amp rating; It seems like it could be permissible (R39) to splice two contacts in parallel (w/ MW1440) to achieve the 40+ amp load rating. Would be a good area for a rule interpretation, as it would make slip rings a more available and useable device. [U]R39 Branch circuits may include intermediate elements such as COTS connectors, splices, COTS flexible/rolling/sliding contacts, and COTS slip rings, as long as the entire electrical pathway is via appropriately gauged/rated elements.[/u] Probably enough hijacking of this Swerve Drive thread on encoders and slip rings. |
11-05-2015 18:31
AdamHeard
|
The last sentence in R39 is what makes these illegal despite being the appropriate size wire. They are not RATED for 40A. (I've been trying to find a way around this for a while). I'd be especially hesitant with the splicing.
As promised: http://www.ebay.com/itm/200661012580 As with most things: Light, Cheap, Legal. Pick 2. |
11-05-2015 18:32
Andrew Schreiber
11-05-2015 22:49
Dunngeon|
There's a few out there, I don't have any links handy right now though. I'll see if I can scrounge up a part number when I get home.
Out of curiosity, why would you ignore the fact that 30A breakers are totally a thing and also require your drive to be on a 40A breaker? |
11-05-2015 22:51
bkahl|
With a swerve you're already limiting yourself on drive power compared to other drivetypes.
|
11-05-2015 23:05
VioletElizabethOn the subject of weight being off--the other thing whole robot models ignore, besides nuts and bolts, is wiring, and sometimes pneumatics as well. (I have never been able to find a CAD model for a compressor.) 6 gauge wire is heavy, and smaller gauge adds up. Also, nuts and bolts are steel, which is more than 3x as dense as aluminum. (.30 lbs/in^3 vs. .098 lbs/in^3 Rachel knows these numbers by now
) We took off a handful (literally, I held them, maybe 10?) of bolts and t-nuts, that we had added as spares in our 80-20, and I would estimate it lost us a pound.
The most accurate way I found was to just weigh the base in real life, and assume that weight for that assembly. All other assemblies were a lot closer to reality.
11-05-2015 23:17
InFlight|
The last sentence in R39 is what makes these illegal despite being the appropriate size wire. They are not RATED for 40A. (I've been trying to find a way around this for a while). I'd be especially hesitant with the splicing.
As promised: http://www.ebay.com/itm/200661012580 As with most things: Light, Cheap, Legal. Pick 2. |
11-05-2015 23:50
asid61|
On the subject of weight being off--the other thing whole robot models ignore, besides nuts and bolts, is wiring, and sometimes pneumatics as well. (I have never been able to find a CAD model for a compressor.) 6 gauge wire is heavy, and smaller gauge adds up. Also, nuts and bolts are steel, which is more than 3x as dense as aluminum. (.30 lbs/in^3 vs. .098 lbs/in^3 Rachel knows these numbers by now
) We took off a handful (literally, I held them, maybe 10?) of bolts and t-nuts, that we had added as spares in our 80-20, and I would estimate it lost us a pound. The most accurate way I found was to just weigh the base in real life, and assume that weight for that assembly. All other assemblies were a lot closer to reality. |
12-05-2015 00:55
Dunngeon
(Equation 1)

12-05-2015 02:11
asid61|
*snip*
So barring any of the current limitations discussed above, what else puts a swerve down on power compared to other FRC drive-trains (primarily 4/6/8wd to keep it simple)? Here's the main one that comes to mind. In a 6wd all the wheels are chained together, and one gearbox of (usually) multiple motors powers all the wheels on that side. So that when your robot is being lifted/losing normal force (under defense ect.) you don't lose the power. Since (most) swerves now days have an individual module per wheel (and a single motor), this benefit is lost. When the front is off the ground, the power being produced by those wheels is simply lost. Whereas in a 6wd, that power is still being put to the ground by the rear 1-2 wheels on each side. Obviously, this ignores things like slippage of the wheels, drivetrain ineffiencies, and other trade-offs that make it a bit more complicated. Power also doesn't scale linearly to more acceleration iirc, so keep that in mind as well. Edit: Let's say each swerve module has 1 CIM, this cim produces a power P. When all 4 wheels are on the ground, the drivetrain is producing 4P. When 1-2 wheels are off the ground, the drivetrain is producing 2-3P. With a 6wd, assuming each side has 2 motors, the drivebase has a power of 4P. When 2 wheels are off the ground, the base is still producing power 4P because the wheels are connected and at least one is still touching the ground. (again, this is simplified a bit) |
). The spec sheet probably has the exact curves.
12-05-2015 07:34
InFlightYou can skip the whole lesson on Maxwells equations and simply use the quite linear DC motor equations:
Current = ((Stall Current – Free Current) / Stall Torque) x Torque Load + Free Current
Torque Load = (Current – Free Current) x Stall Torque / (Stall Current – Free Current)
Speed = - (Free Speed / Stall Torque ) x Torque Load + Free Speed
Power = 3.14 x Speed x Torque Load / 30
The efficiency is simply power out over power in,
Eff = Power / (Current x Voltage)
For a CIM motor:
Free Speed: 5,310 rpm (+/- 10%)
Free Current: 2.7A
Maximum Power: 337 W (at 2,655 rpm, 172 oz-in, and 68A)
Stall Torque: 2.42 N-m (343.4 oz-in)
Stall Current: 133A
You run peak current at the highest torque load.
As an aside, it's no mystery why six CIM drives pop their main breakers with regularity.
12-05-2015 08:13
GdeaverIf you are discussing power input and swerve don't forget the steering motors. In a pin and hard action, they will draw considerable current in addition to the drive motors. Do not worry about tripping breakers. The Roborio will invoke brown out protection long before a breaker trips. For this year no team should have had problems with brown out and drive. If we go back to a 2014 game teams better look at where on the power curve they design and look at total robot power budgeting. We developed a CVT swerve module last summer. There was no need for it this year. We will be revisiting it again this summer. With a CVT the total gearing reduction increases as the load increases keeping the drive power input in a safer zone. Read the Roborio brown out doc and enforce power management in future robot design process. Of course if we have a 2014 like game next year why would you use a minicim swerve.
12-05-2015 08:56
Andrew Schreiber|
With a swerve you're already limiting yourself on drive power compared to other drivetypes. Going from 40A to 30A is reducing that even further. It's not that I wouldn't use them, just that I'd prefer to have 40A slip rings in most cases.
|
12-05-2015 10:14
Dunngeon|
Ah so it is just the "moar powah" claim.
I thought there might be more to it. I'm ok trading some pushing power for simpler modules. (As a programmer I find designing with bevel gears to be far more difficult than slip rings) If you're pushing with a swerve you're probably doing something wrong. |
|
The thing about 4 wheels on the ground makes perfect sense, but unless you're planning on having a pushing match halfway on a table it's largely irrelevant. Just use sailcloth for bumber material and slide away perpendicular to the opponent's robot; presumably that doesn't take all 4 motors to do, and once you're on the ground you have plenty of power to flee. |
12-05-2015 10:44
Andrew Schreiber|
Yeah, at its core it's about the power, but not exclusively for pushing. With a swerve, I'd rather avoid contact as you said. That seems to require that a robot be nimble, of which quickness/low-end acceleration seems to play a large part (2014, 2013). Maybe I'm overestimating the importance because I've never fielded a swerve before. Also, my opnions are based upon swerve in games like 2013,2014, where there was a need for quick direction changes and occasional pushing to get to a ball/traverse the field. For games like 2012 and 2015, sacrificing 10A wouldn't matter.
Out of curiousity, what else are you thinking when you said there's "more to it"? |
12-05-2015 19:37
GeeTwo
|
All too often I see swerves driven like tanks. Go to point, pivot wheels, go sideways, pivot wheels again, go back to going forward.
|
12-05-2015 19:52
Spoam|
Does anyone have any insight on what 254 (or any other more "fluidly" driving team) uses to control their swerves or holonomic drives?
|
12-05-2015 20:03
Richard Wallace
12-05-2015 20:13
Andrew Schreiber|
Does anyone have any insight on what 254 (or any other more "fluidly" driving team) uses to control their swerves or holonomic drives?
|
12-05-2015 20:34
AdamHeard
|
I strongly suspect than many teams program both holonomic and redundant (e.g. swerve) drive controllers like tank, and if so, then of course they're driven that way. By "like tank", I mean that the primary drive is either two-tread style or arcade style, with options like strafing, translating in odd directions, translating odd directions while rotating, and rotating around a fixed point being either special cases or left for the driver to figure out.
When 3946 did mecanum (Aerial Assist, not our best tactical call), we had all of the translation in a single joystick, and rotation on the left and right "triggers" of the xBox controller. This did encourage a bit of combination maneuver - you could move towards the ball or goal while simultaneously rotating. Even I was able to do both at the same time within a couple of minutes when I did a demo at my office department's spring picnic. I'd personally like to have done a joystick with a long (+/- 60 to 90 degrees) proportional twist axis, but I wasn't mentoring programming that year, and I understand that we didn't have any joysticks up to the task, in any event. Does anyone have any insight on what 254 (or any other more "fluidly" driving team) uses to control their swerves or holonomic drives? |
12-05-2015 22:47
sanddrag
13-05-2015 00:52
Dunngeon|
30A breakers don't pop immediately. (http://www.snapaction.net/pdf/MX5%20Spec%20Sheet.pdf) So, a 30A breaker pulling 80A (which according to tests I've heard about is about the max you can get to a CIM given other loads on the system and the battery) will last 0.8 - 1.8 seconds. A 40A breaker will give you about twice that time. But that's assuming you're practically stalling the CIM. And it completely ignores the fact that, more than likely, the RoboRio will cut your motor power due to voltage drop.
Acceleration is also a function of code/driving/operator interface. All too often I see swerves driven like tanks. Go to point, pivot wheels, go sideways, pivot wheels again, go back to going forward. If you watch how teams who have mastered swerve (ok, I'm a 16 fan boy, I'll admit it) they tend to be much more fluid and rely less on raw power to accelerate from 0 in that direction. 254 does similar things when it comes to tank drives, it's why they seem to get away with gearing so much higher than other people. Basically, while being able to pour more power for longer may seem like a good solution to the acceleration problem there's a fair bit more to it and utilizing it will mean your motors run cooler, your batteries last longer, and you can STILL out swerve most people. That all being said, if I could easily find a 40A rated slip ring for comparable weight/cost of the 30A I'd choose it every time. But if I given the choice between a more complicated module (bevel), more complicated code (limit rotations), and limited continuous current (30A breaker) I'd choose limited current every time. But I'm a software engineer, I have a certain set of criteria I apply to decisions. Other folks with different backgrounds might make different decisions. |