Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Extra Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=68)
-   -   pic: Small CIM in wheel swerve (http://www.chiefdelphi.com/forums/showthread.php?t=137177)

Bryce2471 07-05-2015 23:43
pic: Small CIM in wheel swerve
 

asid61 07-05-2015 23:45
Re: pic: Small CIM in wheel swerve
 
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.

cad321 08-05-2015 00:13
Re: pic: Small CIM in wheel swerve
 
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.

Bryce2471 08-05-2015 01:26
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by asid61 (Post 1480955)
4.6lbs per module? I think you've finally made a swerve that can be lighter than a WCD.
Much applause.
Thank you. This was mostly a design experiment for me, but I suppose it could be useful in a game like this year where a lot of weight is needed for the manipulators, and maneuverability is important, but pushing power is not.
Quote:
Is the two-plate design lighter than just flipping the motor over and using a planetary gearbox?
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.
Quote:
EDIT: Is that a custom gear on the bottom?
Yes. Several of the gears are custom so it would require access to a good laser, water jet, or wire EDM.
Quote:
DOUBLEEDIT: Oh wait, MiniCIM. Dang, that was almost the dream.
Yep...
Maybe one day.
Quote:
Originally Posted by cad321 (Post 1480958)
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.
Thank you, the mini CIM is accounted for, at 2.16 lbs. I'm pretty sure that the materials are correct, but like I said, there are some details that aren't in the CAD.

Clayton Summerall 08-05-2015 05:30
Re: pic: Small CIM in wheel swerve
 
What motors turning the left right motion? Pg or 750 maybe?

Bryce2471 08-05-2015 11:25
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by mcnabb2936 (Post 1480974)
What motors turning the left right motion? Pg or 750 maybe?
In the CAD, it is an AM-912, but in reality, I would probably use a banebots RS 550.

GeeTwo 08-05-2015 13:42
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Bryce2471 (Post 1480970)
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.
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. You'd need slip rings for the drive motor since you couldn't run the wire out through the rotation hub, which might eat up the weight savings.

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.

aphelps231 08-05-2015 13:46
Re: pic: Small CIM in wheel swerve
 
Great work, would you be willing to share STEP files so we could take a look?

Ryan_Todd 08-05-2015 14:59
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by GeeTwo (Post 1481039)
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.
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.

GeeTwo 08-05-2015 15:33
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Skywalkar (Post 1481049)
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.
Thanks, Skywalkar - I see it now. The reflection plane must be tilted down as it approaches the viewpoint (or the vertical on the module is tilted away at the top). I thought it strange that the dark gray gear did not engage with anything except to pass through to the yellow gear below the lower plate.

InFlight 08-05-2015 20:11
Re: pic: Small CIM in wheel swerve
 
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?

evanperryg 09-05-2015 09:54
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by InFlight (Post 1481114)
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?
This is what I'm most curious about, what kind of speeds are to going to get out of these? I'm sure there's an encoder mount somewhere, but where is it? Very, very impressive design.

InFlight 09-05-2015 12:02
Re: pic: Small CIM in wheel swerve
 
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. 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.

Scott Kozutsky 09-05-2015 12:52
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by InFlight (Post 1481193)
With a large steering gear like that you can't use an absoule encoder.
It appears there's an absolute encoder on the top of the entire module, likely connected by bent polycarb like 2451 and 3928 before them.

sanddrag 09-05-2015 13:12
Re: pic: Small CIM in wheel swerve
 
On 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.

Ether 09-05-2015 13:33
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by sanddrag (Post 1481198)
... there was a good bit of math and code involved...
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.

AlexanderTheOK 09-05-2015 13:53
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481203)
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.
Funny you say that. That was the original plan, but Java's timer tasks (as mentioned by 254) are slightly broken on the roborio. We had latencies in code of up to 200ms. We ended up using the FPGA's analogTriggers to keep track.

Since there's really never a need for analogTriggers save for this one strange case, that was broken too. Thank god for the fantastic people at WPI that got it fixed so quickly.

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.

AdamHeard 09-05-2015 13:57
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by AlexanderTheOK (Post 1481206)
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.
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.

Ether 09-05-2015 14:01
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481203)
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.
Here's the code (I think). Haven't tested it:

Let A be the encoder angle reading in degrees (0 to 360 clockwise) at the previous sample, and B be the encoder angle reading in degrees at the current sample. Then:
D = B-A;
D -= 360*floor(0.5+D/360);
if((D>0)&&(A>B)) turns++;
else if((D<0)&&(A<B)) turns--;

Bryce2471 09-05-2015 14:17
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by GeeTwo (Post 1481039)
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.
I would like to use a worm gear, but I have no idea how to make a large custom worm gear, and I assume that a COTS gear that large would be incredibly expensive. Perhaps worth looking into though, since this was just a CAD experiment anyway
Quote:
Originally Posted by InFlight (Post 1481114)
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?
Thanks, right now it uses a bomb squad style slew bearing.

I kept it to one stage in this design, but it's likely geared too tall for most situations. It's a 5.33 to one reduction on a 3.5'' wheel.
Quote:
Originally Posted by InFlight (Post 1481193)
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.
We have run an incremental encoder with a homing index in the past, and would probably never go back... It's a real pain, and the drift robs a lot of a swerve's efficiency.
Quote:
Originally Posted by Scott Kozutsky (Post 1481196)
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.
Correct, although I'm still debating how the wire routing will work...
Quote:
Originally Posted by Ether (Post 1481203)
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.
You also need to have a good home position. 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.

Ether 09-05-2015 14:28
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Bryce2471 (Post 1481209)
You also need to have a good home position.
That is a given.

Quote:
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.
Would you please elaborate on this? It's not clear what problem you are trying to solve.

Bryce2471 09-05-2015 15:05
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481210)
Would you please elaborate on this? It's not clear what problem you are trying to solve.
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.

Bryce2471 09-05-2015 15:10
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by AdamHeard (Post 1481207)
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.
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?

sanddrag 09-05-2015 15:25
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481203)
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.
I think that's essentially what our programmer did, although the libraries involved had some glitches that presented many headaches.

For those of you discussing "drift" with incremental encoders, are you referring to an accumulation of lost counts? Does this happen when the direction of steering reverses, and is this accumulation of lost counts biased toward one direction? Would the solution to have something like a hall effect sensor for zeroing, and reset the count every time you cross it?

Ether 09-05-2015 15:46
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Bryce2471 (Post 1481214)
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.
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.

AdamHeard 09-05-2015 15:49
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Bryce2471 (Post 1481216)
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?
You shouldn't be losing counts (which is why we love using them).

However, if you are there are two likely causes.

1) Mechanical slip. Somehow the encoder is slipping, easy to fix w/ better design.

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.

Ether 09-05-2015 15:57
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Bryce2471 (Post 1481216)
I have found that with swerves, the small amount of accumulated drift from an incremental encoder is unexceptable.
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).

Bryce2471 09-05-2015 16:31
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by AdamHeard (Post 1481223)
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.
I'm going to guess that #2 was our problem. I am surprised I've never heard of this issue before.

InFlight 10-05-2015 08:16
Re: pic: Small CIM in wheel swerve
 
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.

Bryce2471 10-05-2015 13:59
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481222)
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.
Sorry my post didn't do it for you; I haven't had a lot of time this weekend to think out my explanation, but I'll give it another shot. I don't like the idea of using a startup zero offset for several reasons. I don't like the weight or complexity of adding a homing switch/sensor. When using an absolute encoder I like to use hardware mounting calibration. So I was trying to explain a way to use hardware mounting calibration with an absolute encoder when the gear ratio between the swerve and the encoder is not 1:1.

You begin by choosing an integer gear ratio for the encoder, because that will make things much easier. Then you mount the encoder or slip the gears so that when the full circle of the swerve is cut into slices of pie, one of the edges of a pie slice ends up facing true zero. Then you write software that takes that edge to be the zero for the match. So now, before each match you don't have to get the wheels perfectly aligned, you just have to aim it in the sector that is to one side of the zero position.
It's just an idea, and maybe that was already blatantly obvious, or maybe its not useful, but I figured I would try to explain my idea so that I could at least find out if people though it was useful or not. Let me know If I need to try to explain it one more time.
Quote:
Originally Posted by Ether (Post 1481224)
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).
Because we had the problem on all four wheels, and we never disassembled the encoders, I'll rule out #4 and #5. We used the WPI lib encoder software, so I'll hope it wasn't #6. We originally thought that it was #3 because we could theoretically exceed the max angular velocity of the encoder, but we later decided it wasn't likely, because we would have to run the motor at very near free speed to do that.

(P.S. Thanks. Your post is much more constructive and helpful with the edit.)

Ether 10-05-2015 14:49
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481224)
6) incorrect programming (resetting the counts rather than letting the FPGA accumulator run freely).
Quote:
Originally Posted by Bryce2471 (Post 1481321)
We used the WPI lib encoder software, so I'll hope it wasn't #6.
Using the WPILib doesn't rule out #6. #6 refers to using the reset() function repeatedly in your software in the roboRIO.

Code:
/**
 * 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());
        }
}
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".

bobcroucher 10-05-2015 15:28
Re: pic: Small CIM in wheel swerve
 
Deleted

Bryce2471 10-05-2015 15:35
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Ether (Post 1481338)
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".
Oh, I see what you mean now. Although I have never heard of that issue before, we were not reseting the counts each cycle. We only reset them when necessary.

Chinske4296 10-05-2015 22:19
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs

Navid Shafa 11-05-2015 00:00
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Chinske4296 (Post 1481393)
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
Look for individual parts or sub-assemblies that you may have missed. Make sure Electronics, KOP-items, COTS and downloaded models are all correct. I've never had any problems, but it is pain-staking work to get all the details right.

asid61 11-05-2015 00:08
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Chinske4296 (Post 1481393)
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
Off above or off below?
We were about 10 lbs under the real weight in the CAD. Next year I'm planning for 100lb bot, to leave a wide margin.

Dunngeon 11-05-2015 00:11
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by InFlight (Post 1481291)
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.
Which slip ring would you use? Mercotac's are banned.

GeeTwo 11-05-2015 00:30
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481417)
Which slip ring would you use? Mercotac's are banned.
I was thinking of a custom solution when I suggested a module no taller than the wheel diameter. A quadrature encoder or a CAN controller wired in the traditional method would require 6 wires. Is it possible to make a CAN talon work with only two control wires that branch a bit away from the talon? If so, you could reduce the connection to four wires, if you could figure out a place to park the talon on the far side of the sliprings with the motor, gearbox, encoder, and wheel.

InFlight 11-05-2015 01:24
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481417)
Which slip ring would you use? Mercotac's are banned.
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.

Rachel Lim 11-05-2015 01:26
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Chinske4296 (Post 1481393)
Never trust inventors weight simulation. We tried it for our robot with correct materials and it was off by about 20 lbs
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.

My preferred method (if we're cutting it close), since I think we're unlikely to get complete enough assemblies to just use the CAD model, is to create a spreadsheet and list out every part and its weight. For custom parts I get the weights off the CAD parts, and for COTs ones I just look at the supplier's website. This way I can ensure I'm not missing a part that ends up to weigh a ton.

In all, even if we have the proper weights for all COTs parts that we add into CAD, and the correct materials for all custom parts, I wouldn't be surprised if the CAD was several pounds under because of the bolts / nuts / wires / pneumatic tubing / chain / belts / all other parts we don't add in.

Dunngeon 11-05-2015 11:37
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by InFlight (Post 1481426)
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.
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.

Andrew Schreiber 11-05-2015 11:53
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481478)
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.
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?

Bryce2471 11-05-2015 15:14
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Rachel Lim (Post 1481427)
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.
I think that Inventor gets pretty good estimates too. Many of the designs I posted on Delphi have never been built, but my team did use the manually machinable swerve that I posted here before the season. The CAD for that said that It would weigh 6.85 lbs, and the real thing weighed in at 7 lbs even (and the real module had long motor wires on it when we weighed it). So I wouldn't say it's perfect, but it can be pretty close.

InFlight 11-05-2015 15:40
Re: pic: Small CIM in wheel swerve
 
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.

Andrew Schreiber 11-05-2015 18:25
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by InFlight (Post 1481523)
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.
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.

AdamHeard 11-05-2015 18:31
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481552)
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.
Anyone know the weight on these?

Andrew Schreiber 11-05-2015 18:32
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by AdamHeard (Post 1481556)
Anyone know the weight on these?
Heavy. Compared to the 30A ones or the Mercotacs... It's been a while since I last held one, but I'd guess almost a pound.

Dunngeon 11-05-2015 22:49
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481487)
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?
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.

bkahl 11-05-2015 22:51
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481588)
With a swerve you're already limiting yourself on drive power compared to other drivetypes.
Please elaborate.

VioletElizabeth 11-05-2015 23:05
Re: pic: Small CIM in wheel swerve
 
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 :p ) 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.

InFlight 11-05-2015 23:17
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481552)
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.
The detailed specs (link below) has these rated at 35 Amps and 50 Amps Maximum. It also has graphite contacts, so the voltage drop @ 12V would be ugly.

http://vi.raptor.ebaydesc.com/ws/eBayISAPI.dll?ViewItemDescV4&item=200661012580&cat egory=121837&pm=1&ds=0&t=1431397986744

Moog has high current contacts, but the price of four of those would be in the four figures. Not much out there that meets all the FRC needs in a small inexpensive package.

asid61 11-05-2015 23:50
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by VioletElizabeth (Post 1481593)
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 :p ) 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.
Generally I find that on a 5lb swerve module, which is relatively screw-dense, adding screws and nutsonly adds between 0.25-0.4lbs.

Dunngeon 12-05-2015 00:55
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by bkahl (Post 1481589)
Please elaborate.
Alright, so first let me lay down some qualifiers.

I'm going to assume that the amperage never exceeds either 40A or 30A on the snap breakers, and that power scales linearly to acceleration. Further, there's no mechanical loss of power due to friction ect.

In it's simplest form, a DC motor is really just a square loop of current (multiple loops) inside of a Magnetic Field (referred to as B-field from this point on). Now the equation for Force when there is a line of current and a magnetic field is
(Equation 1)

What's important is that the Force is proportional to current flowing through the wire, assuming that the length of the loop and B field stay the same. Since the current flows in opposite directions on each side of the loop, the force produced by each side sums.


Torque is equal to r x F (radius cross force) (I'm skipping directions for the vectors because I don't have the time to draw everything out) or r*F.

Now, Power in rotational motion is Prot = T*omega (Torque*Rotational Velocity)

I'm going to pull from this webpage. You can go there to see how this next equations/graph were derived.

Power for a DC motor with respect to speed and torque end up being quadratics.



and they produce this graph



This curve is for a Green Maxon Motor, but the CIM shares a very similar power curve (as do many DC motors).

We know that Power is dependent upon both Torque and Omega. We also know that Torque is equal to rI*integral dlxB.

So, assuming that B, dl (or essentially L), r, and omega remain the same, power is affected by changes in the magnitude of current.

If we limit the CIM to 40Amps, it will produce a peak power. However, if the CIM is limited to 30Amps, it will produce a lower peak power because it has less current flowing through the loop that creates the torque.

However, our power systems aren't limited to only 40 amps, you can exceed the amperage on our breakers by quite a bit. I have no idea exactly how much a 30A vs 40A breaker will affect overall power output, but it's enough that we have noticed acceleration differences.


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)

asid61 12-05-2015 02:11
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481619)
*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 current limitations are still the same as those on the 40a breakers on the PDB, because it's not like the slip rings are about to explode the moment you exceed 40a (probably :P). The spec sheet probably has the exact curves.

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.

InFlight 12-05-2015 07:34
Re: pic: Small CIM in wheel swerve
 
You 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.

Gdeaver 12-05-2015 08:13
Re: pic: Small CIM in wheel swerve
 
If 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.

Andrew Schreiber 12-05-2015 08:56
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481588)
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.
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.

Dunngeon 12-05-2015 10:14
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481648)
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.
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"?

Quote:
Originally Posted by asid61 (Post 1481624)

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.
I used an extreme case to make the point about the power loss, it rarely occurs to that extent. Generally it's just a loss of a few pounds of normal force on a few wheels.

Andrew Schreiber 12-05-2015 10:44
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Dunngeon (Post 1481662)
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"?
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.

GeeTwo 12-05-2015 19:37
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481670)
All too often I see swerves driven like tanks. Go to point, pivot wheels, go sideways, pivot wheels again, go back to going forward.
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?

Spoam 12-05-2015 19:52
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by GeeTwo (Post 1481740)
Does anyone have any insight on what 254 (or any other more "fluidly" driving team) uses to control their swerves or holonomic drives?
254 does not use holonomic drives. They do, however, scale inputs and use motion profiles to control their skid-steers.

Richard Wallace 12-05-2015 20:03
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Spoam (Post 1481742)
254 does not use holonomic drives.
I think that is because they don't need to.

Andrew Schreiber 12-05-2015 20:13
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by GeeTwo (Post 1481740)
Does anyone have any insight on what 254 (or any other more "fluidly" driving team) uses to control their swerves or holonomic drives?
254 doesn't swerve. But they DO use Cheezy Drive. It's designed to make driving in long sweeping arcs easier.

I know 16's controls encourage their drivers to drive in the long arcs you often see them do. I don't have nearly enough stick time with a bomb squad robot to explain it, hopefully I can get Jefferson to explain it a bit.

AdamHeard 12-05-2015 20:34
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by GeeTwo (Post 1481740)
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?
Their swerve code is in the block below.

Code:

sanddrag 12-05-2015 22:47
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by AdamHeard (Post 1481754)
Their swerve code is in the block below.

Code:
Gosh, that's the lightest-weight code I've ever seen. :D

Dunngeon 13-05-2015 00:52
Re: pic: Small CIM in wheel swerve
 
Quote:
Originally Posted by Andrew Schreiber (Post 1481670)
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.
Yeah, I was looking at the breaker specs today and realized that for most scenarios the 30A will have nearly the same functionality as the 40A (as you said). That was the part of our power system that I wasn't sure about and I mentioned in my post. I definitely agree with you on the control code, that is incredibly important to any drivebase.


All times are GMT -5. The time now is 07:46.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi