Team 2471 swerve drives

[Bryce2471]

https://lh3.googleusercontent.com/-uVQTwXiHQu4/UkyoCc1LV7I/AAAAAAAB4os/876ArTAT3_g/w769-h577-no/13+-+1

https://lh3.googleusercontent.com/-MW9oDC94a74/UkyoL3sNxYI/AAAAAAAB4o4/_OhST0iRc68/w769-h577-no/13+-+1

https://lh5.googleusercontent.com/-m0v7UUf-Kxg/UkyoQJI-oWI/AAAAAAAB4pE/ciPBYExR97o/w769-h577-no/13+-+1

http://youtu.be/dKpz8bJqr58

This off-season I have been investing quite a bit of my time into this project, along with several of my team mates, its finally begun to pay off. The link is to a video of the test bot on Monday, which was the first day we got to drive it for more than about 5 minutes. Keep in mind, this is not our hallway to bash, so we are driving a bit cautiously. This robot will compete in the Bunny Bot off-season event on 12/21/13 hosted by team 1540.
Most of the team that worked on the swerve project would agree that the initial programming was much easier than expected. we began integrating the code on Monday of last week, we had a vexing initial zeroing problem that took us until the end of Wednesday shop to solve. Then I went in on Saturday for a few hours and got the robot strafing. The next day I was in for literally less than 90 min and the first version of the code was done and working. The current code is a simple robot based drive that works well but would take a lot of driver practice to achieve what we want, so we will continue to add complexity from here.
I have posted about the mechanical design previously on CD but I assume that many people have not seen it. The upper gear box is constructed with a one piece frame because it has high strength, low weight, and provides a compact design. The CIM drive has a one to one belt ratio on top right now to save space, and in the castor it has a 3.5 to 1 chain ratio, geared for 17 ft/sec. In the future, we may use a 12 to 15 belt ratio on top for more torque. The steering is done by a 550 series motor through a 27 to 1 planetary gearbox out of a Black and Decker drill, and then a 15 to 48 belt drive. The BND gearbox was chosen because it is light weight, some-what compact, and cost $17. Each swerve ends up weighing ~7.5 lb, the hole frame (as shown in the picture, not in the video) weighs ~37 lb. The foot print of each swerve is 6" by 6", but at ground level, the castors are only 4" wide.
I also have a version designed for next year that would have a foot print of 3" by 9.375". I might post the designs here later if I get enough requests. I will also do my best to post another video of it driving once we get more intuitive code.
If you have any further questions or comments i'd be happy to here them. Also, I'm still undecided on the gearing change, so if you have an opinion, please post.

[TheMadCADer]

Looking good, I'd like to see the more compact design as well.

As far as the gearing change, that depends entirely on the game the robot's playing, and what role it's playing in that game.

Looking at a game like 2010, an offensive robot didn't need a high top speed, since there wasn't a huge amount of room to drive around because of the bumps. However, a defensive robot was best if it could quickly drive between the two goals to block.

The next year in 2011, many offensive robots had a high top speed, designed to quickly traverse a mostly open field. The same thing was seen this year as long as you had a short robot (since the field was hardly open at all for tall robots).

Then there are games like 2012, where it's a balance of the two previous examples. There was a good amount of open space, but it was somewhat limited because of the barrier, which also caused you to have to stop and start if you needed to cross the field. A lot of teams opted for faster acceleration and a lower top speed, but were still faster moving than in 2010.

Basically, there's no benefit to having a higher top speed if you never reach it, and there's no benefit to having faster acceleration if you are driving long distances with few stops and starts.

I also would advise against taking any "pushing power" arguments into account. If you want to play defense, friction with the floor is a better force to rely on than your motors (see team 71 in 2002). If you play offense, trying to push a defender is exactly what they want you to do, because it's wasting your time. Instead, simply avoid and evade defenders (see 610 this year for a great example, especially the way that their driver would "box out" defenders causing them to run into the pyramid and get stuck long enough for 610 to get free). FRC is all about doing the same thing as everybody else, only faster.

[Gdeaver]

Welcome to the wild world of swerve. On the wheel part I wold be concerned with racking. You might want to consider adding a triangle cross brace to help with this. What wheel position sensor are you using? In my opinion 17 fps is too high. This sacrifices acceleration and precise movement for high end. Put a lower top end on and see what the drivers think. Track your current draw and voltage drop with a comp weight on the bot. Swerve is only as good as your drivers ability to use it. Time to set up the the obstacle course. The AndyMark wheels have good COF when new but wear fast.

[Bryce2471]

Basically, there's no benefit to having a higher top speed if you never reach it, and there's no benefit to having faster acceleration if you are driving long distances with few stops and starts.

I agree, this robot is going to play on a field that is almost entirely open, and will probably be moving almost continuously with a robot that will probably be under weight.
That being said, I'm curious to see if people think it is too tall for any situation. 3.5 to one is not a lot of gearing.

I also would advise against taking any "pushing power" arguments into account.

I agree again, because we are not planning on getting in pushing matches, and a swerve robot will be hard to push no mater what the gearing.

Put a lower top end on and see what the drivers think.

Do you mean electronically or by changing the gear ratio?

[Bryce2471]

Welcome to the wild world of swerve. On the wheel part I wold be concerned with racking. You might want to consider adding a triangle cross brace to help with this.

This may be a problem in the near future but we will have to conduct more testing to see. If it does become a problem, I think I will replace the .25" side plates and replace them with sections of a 3" by 1" by 0.125" U channel. This would rap around the front and back of the swerve giving it more rigidity.

[ratdude747]

Looks good... but I'm concerned with the rigidity of the frame. Is there going to be a belly pan or the like for the electronics? If not, I'd look at some diagonal bracing...

[jsasaki]

looks cool. Is that swerve frame a single piece of aluminum???

[Bryce2471]

looks cool. Is that swerve frame a single piece of aluminum???

No it is four pieces of 3" by 1" by .125" U channel, with two CNC'd cross braces, made from 3" by 1" tube. The outside U channels were TIG welded together a couple of weeks ago. Learning to TIG weld was another one of my off-season projects.

[Bryce2471]

Looks good... but I'm concerned with the rigidity of the frame. Is there going to be a belly pan or the like for the electronics? If not, I'd look at some diagonal bracing...

The frame shown in the picture, and the robot shown in the video are one and the same, but the video was taken later on in the project. In the video, the robot has a belly pan and electronics.

[Ether]

Most of the team that worked on the swerve project would agree that the initial programming was much easier than expected. Then I went in on Saturday for a few hours and got the robot strafing. The next day I was in for literally less than 90 min and the first version of the code was done and working.

Could you provide more detail about your software? e.g. Does it have 3 independent degrees of freedom (X, Y, and rotate) or just X and Y? What does the Driver Interface look like? Is it field-centric or robot-centric? etc.

we began integrating the code on Monday of last week, we had a vexing initial zeroing problem that took us until the end of Wednesday shop to solve.

Was the problem related to the gyro?

[Bryce2471]

Could you provide more detail about your software? e.g. Does it have 3 independent degrees of freedom (X, Y, and rotate) or just X and Y?


Yes. It has full 2D motion capabilities. All of these should be visible in the posted video.

What does the Driver Interface look like? Is it field-centric or robot-centric? etc.

The software is new. We have never programmed a swerve robot before so we kept it simple with a robot-centric driving system.
The code is made up of two, somewhat simple parts right now. First, the left analog stick input gives an X-Y heading. That vector is directly applied to each wheel. This gives us our translation or strafing ability. Next, the X component of the right analog input gives a turning value. This value is set as the length of a vector on each wheel for orienting the robot. The angle of this vector is defined as being perpendicular to a line between the wheel and the the center of robot rotation.
Then, one problem is that each wheel has two vectors that it is supposed to accomplish. The solution is simple: you just add the two vectors together. This presents a second problem. If you try to turn at full power and drive at full power at the same time, each wheel will try to drive at >100% power. This is solved by dividing each wheel's power by the power of the highest power wheel if that is greater than 100%.

Was the problem related to the gyro?

No,
This code, as I mentioned earlier works quite well, but it is somewhat difficult to drive. So before the off-season ends, we will be implementing a field-centric drive code. To get our sense of bearing, we will be using both gyro and compass sensors. To filter these inputs together we considered using a Kalman filter, but we decided it was not a good solution because it has a lot of tuning involved as well as not having a lot of information available on the details of how to tune them. We have decided to implement our own filter that is much more simple and gets directly to the solution. It essentially works by taking the height of the compass sensor on a graph and applying the curve of the gyro input to that.
We had a problem in the beginning: a small syntax error that caused a lot of very odd outputs and symptoms.

[Ether]

First, the left analog stick input gives an X-Y heading. That vector is directly applied to each wheel. This gives us our translation or strafing ability.

Next, the X component of the right analog input gives a turning value. This value is set as the length of a vector on each wheel for orienting the robot. The angle of this vector is defined as being perpendicular to a line between the wheel and the the center of robot rotation.

Then, one problem is that each wheel has two vectors that it is supposed to accomplish. The solution is simple: you just add the two vectors together. This presents a second problem. If you try to turn at full power and drive at full power at the same time, each wheel will try to drive at >100% power. This is solved by dividing each wheel's power by the power of the highest power wheel if that is greater than 100%.

Very clear explanation. Did you guys use resources on CD (papers, posts, etc) as a starting point, or did you work from first principles to figure out the physics and math?

[Bryce2471]

Did you guys use resources on CD (papers, posts, etc) as a starting point, or did you work from first principles to figure out the physics and math?

Originally, in 2012 at the championships on Newton field, I was inspired by the maneuverability of 1717. We were on an alliance with them in the elimination rounds. Unfortunately, they weren't functional for most of the quarter and semi final rounds, but I still wanted to make a drive train like theirs.
Partly because 1717 doesn't publish their designs or code, we took into consideration the resources that are available from team 1640. They are very generous to offer years worth of experience. While their detailed cad designs helped me get off the ground, their software papers were more complicated than I was hoping. So, essentially all of the ideas that went into this version of software came from the minds of the people involved in the project. We already have most of the ideas compiled for the field-centric version as well, but I'm sure we will run into some challenges that we have not yet foreseen.
After the field-centric version is complete, we will try out a new concept that is specific in solving the challenges involved in this years bunny-bot off-season event. the main challenge to the game is collecting and herding 6" foam dodge balls, while only using a three sided corral.
After bunny-bots, we will do our best to publish a white paper about several aspects of the project as well as post the designs so that others can use them.

Edit: Here's a link to us playing with 1717
http://youtu.be/X-Jm1vQ_bSk?t=24m26s

[Joe Ross]

Partly because 1717 doesn't publish their designs or code,

http://forums.usfirst.org/showthread.php?14331-2009-reused-code-1717
http://forums.usfirst.org/showthread.php?15972-Team-1717-2011-pre-season-code

[Clem1640]

They look great. Very nicely done! Great job managing the mass.

I'm glad our designs were helpful.

[Bryce2471]

They look great. Very nicely done! Great job managing the mass.

I'm glad our designs were helpful.

Thanks, as I said earlier, I wasn't able to fully understand your programming papers. So I was hoping you could tell me if our current programming is similar to what you guys call ocelot drive.

[That1MuzzaFuzza]

How much pushing power does this have? I have always liked this idea but it never seems practical if you are going up against any mildly strong defensive team. I feel like you could be smelling those motors after a small pushing battle.

[MichaelBick]

How much pushing power does this have? I have always liked this idea but it never seems practical if you are going up against any mildly strong defensive team. I feel like you could be smelling those motors after a small pushing battle.

Theoretically, swerve is just as strong as a matching tank drivetrain with the same wheels and gearbox ratios. However, from what I have heard the big problem with independent swerves is that when you get into a pushing match two wheels tend to come slightly off the ground, causing you to lose 50% of your power.

[Chris is me]

How much pushing power does this have? I have always liked this idea but it never seems practical if you are going up against any mildly strong defensive team. I feel like you could be smelling those motors after a small pushing battle.

The small motors are just used for rotation, so there's not a ton of risk of burning them out in a pushing match.

Pushing performance is tied to how the CIMs are geared. At 17 FPS like these modules, probably not as pushy as a shifting drive or at a lower speed. CG is also a factor as ideally it should be low enough that tipping off of a wheel or two isn't as easy in a pushing match.

Best of luck on getting the code on this up to 1717's standards. The vast majority of swerves never get there, but with time in the off season to prepare it's totally possible. I love the mechanical design, especially the gearbox made from a single piece of extrusion.

[Bryce2471]

How much pushing power does this have? I have always liked this idea but it never seems practical if you are going up against any mildly strong defensive team. I feel like you could be smelling those motors after a small pushing battle.

This robot's "pushing power" will be minimal,(although I estimate it is about 100 lbs) but what I don't think many people understand about swerves is that it is the best drive train for getting around defense.

When many tall geared offensive robots try to get around a defensive one, they dodge left or right early. To do this they must slow down a little. Then the slower D-bot (defensive robot) begins to move in that direction. The D-bot is not fast enough to get directly in the way of the O-bot, (offensive robot) but it can run into the side of the O-bot. In most situations this costs the O-bot a few seconds because the friction between their bumpers is high enough that it is difficult to get unstuck.

Now if an S-bot (swerve bot) has an defender in the way, it can head full speed directly at the D-bot without giving away which direction it is planning to go. Then, with just a few feet left between, the S-bot can dodge on way or the other without slowing down, their is no D-bot that I know of that would be able to accelerate fast enough to get in the S-bot's way.

Now, lets say that S-bot wants to play defense. They still will never have to get in a pushing match. Because S-bot is most likely as fast as any robot it will face, S-bot just predicts where O-bot wants to go then just sits in the way. In our programming, every time you let up off the joy sticks, the wheels make an X formation. So to push S-bot when it is not moving would require that O-bot have more traction than S-bot and Have so much torque that It can Break loose S-bots wheels.

So in conclusion, we will not be able to push other robots but they won't be able to push us either, and we will be able to change direction almost instantly while moving at high speed.

PS. sorry for the long post, but I just find it strange that many people think a swerve robot would be easy to push.

[Bryce2471]

Best of luck on getting the code on this up to 1717's standards. The vast majority of swerves never get there, but with time in the off season to prepare it's totally possible. I love the mechanical design, especially the gearbox made from a single piece of extrusion.

Thanks, I did almost all of the mechanical design summer after 2012, so it's nice to finally see it in person.
On a side note, as light as the gearbox is right now, another change I am considering for the season is the wall thickness. As it stands, it has .25" wall, and I think the welded frame of the robot would fall apart before the box would see a dent. I'm thinking of .1875" or .125". I know that that .1875" would be strong enough, (I've personally jumped up and down on a piece) but the rest of the robot frame is always made from CNC'd .125".

CG is also a factor as ideally it should be low enough that tipping off of a wheel or two isn't as easy in a pushing match.

This is a factor that I had considered but I frequently forget about. Thankfully the CoG of this robot is approximately 5" off the ground. It's one if the lowest robots my team has built. I also think a low CoG improves the driving performance, much like a car's handling is affected by its CoG.

[magnets]

These swerve modules are really neat. I like how you have pocketed out plate on the wheel holder.

I'd keep the bottom plate at 0.25". The top plate could probably be 0.1875", or maybe eve 0.125", but the bottom plate has to handle the load from your thrust bearing. To save weight you could cut away some of the bottom plate that goes around the CIM motor. In the first picture you could probably remove quite a bit of material from the side. You could get creative with the shape of the plates. The only sides that need to be flat are the ones that you are welding to, so you could do something that isn't a square. Also, it's probably worth making the swerve modules stronger than they need to be. We also make our robot's frame out of 0.125" thick aluminum, but we've dented it before. If the swerve modules get dented, it's not good.

[Bryce2471]

These swerve modules are really neat. I like how you have pocketed out plate on the wheel holder.

Thanks, Those pocketed side plates are personally my favorite part. That is part of why I am reluctant to change them to add more strength to side load.

I'd keep the bottom plate at 0.25". The top plate could probably be 0.1875", or maybe eve 0.125", but the bottom plate has to handle the load from your thrust bearing. To save weight you could cut away some of the bottom plate that goes around the CIM motor. In the first picture you could probably remove quite a bit of material from the side. You could get creative with the shape of the plates.

Good suggestions. Although, I think your concern about the bottom plate may be unwarranted. Our first test box had .1875" wall, and to prove a point I set the box on the ground. Then I put one foot on the plastic collar that ends up supporting the robot (we aren't using a thrust bearing). I proceeded to jump up and down on that foot. There was no visible deflection in the box. I wouldn't describe myself as a big guy, but I weigh about 145 lbs. So I'm pretty confident that the bottom plate could handle being .1875" thick. I like your idea of making some parts thinner than others though.

[MichaelBick]

The D-bot is not fast enough to get directly in the way of the O-bot, (offensive robot) but it can run into the side of the O-bot. In most situations this costs the O-bot a few seconds because the friction between their bumpers is high enough that it is difficult to get unstuck.


There are easy ways to get around this. Putting drop down casters on one side of the 6wd causes the defensive bot to spin the offender instead of t-boning it.

Then, with just a few feet left between, the S-bot can dodge on way or the other without slowing down, their is no D-bot that I know of that would be able to accelerate fast enough to get in the S-bot's way.


The second you telegraph your moves the defensive robot can react. I doubt this delay is long enough where the defensive robot will actually have a hard time blocking you. Furthermore, good defensive robots are going to predict and trap, effectively neutralizing this advantage. Furthermore...

Because S-bot is most likely as fast as any robot it will face, S-bot just predicts where O-bot wants to go then just sits in the way.


what makes you think if that you can predict your opponents moves they cannot do the same on you.

In conclusion, I'm not saying that swerve is a bad drivetrain. There are clear advantages like precise movement and not telegraphing moves. However, I personally find that a 6wd can accomplish your same goals with good drivers, lots of practice, and a few small additions.

[Bryce2471]

There are easy ways to get around this. Putting drop down casters on one side of the 6wd causes the defensive bot to spin the offender instead of t-boning it.

Interesting idea, I've never seen it before in competition, but it sound cool none the less.

The second you telegraph your moves the defensive robot can react. I doubt this delay is long enough where the defensive robot will actually have a hard time blocking you. Furthermore, good defensive robots are going to predict and trap, effectively neutralizing this advantage.

Your right, as soon as S-bot begins moving in one way or the other, D-bot can begin reacting to that. My point was that S-bot is already going 14-17 fps and S-bot is going zero. A six wheel drive O-bot could also be going that fast but they slow down when they turn.

what makes you think if that you can predict your opponents moves they cannot do the same on you.

My other point was that S-bot does not give away which direction in intends to head based on the robot orientation. Where as O-bot must turn before it can start to head in one direction or the other this.

Originally, I was just trying to make the point that in general, it is harder for any given D-bot to form a pushing match against a swerve robot than a 6wd bot.

[Navid Shafa]

what makes you think if that you can predict your opponents moves they cannot do the same on you.

Most FRC Drivers, especially at the regional/district level seem woefully unprepared. 2471 is not one of those teams. Sure, they are likely to see a little harder defense in elims and at champs, but so will any drive base/drive team...

[MichaelBick]

Most FRC Drivers, especially at the regional/district level seem woefully unprepared. 2471 is not one of those teams. Sure, they are likely to see a little harder defense in elims and at champs, but so will any drive base/drive team...

If the drive teams you see are unprepared then a 6wd should be able to get by them just as easily as a swerve.

[Navid Shafa]

If the drive teams you see are unprepared then a 6wd should be able to get by them just as easily as a swerve.

The point I was making, is that you can do this with any drive style, it really comes down to skill and experience.

[MichaelBick]

The point I was making, is that you can do this with any drive style, it really comes down to skill and experience.

Sorry, I misunderstood. I thought you were rebuking rather than agreeing with me.

[Gdeaver]

4 wheel independently steered swerve allows several moves that are not possible with a non omni-directional drive. First a simple side slip. When approaching a defender just as they are about to hit side slip and go on your way. A improved version is the role out maneuver. Same as a slip except as the side slip begins add a chassis roll to it. Its all most impossible to get into a "well driven swerve". Our 2013 driver was very good at this. Look how far he took us. The defender does have more of a chance in a tight restricted area. Walls can be death and field structures. This year the pyramid sides formed a restricted zone. We could go under the pyramid and many times performed the roll out in this zone or went under the pyramid and on our way. Swerve only provides a competitive advantage if the driver is well trained and skilled enough to use the additional degrees of freedom provided by swerve. Alignment in the game is a big advantage to swerve. This year alignment to the feeder station and alignment for shooting were greatly simplified by swerve. So even if you manage to build a swerve system and mechanically get it right your only about half way there. The driver interface and driver training are just as hard. We recognized this and have been working very hard training our rookie drivers for 2014.

[Ether]

Gdeaver alluded to the importance of swerve/omni Driver Interface (DI), and that segues into a question I've been wondering about lately.

Does anyone know of a team who has implemented a DI mode I will call1 a HaloAR (AR=Auto Rotate), as described in this thread (http://www.chiefdelphi.com/forums/showthread.php?p=1279133#post1279133) posts 5, 6, and 9?


1until someone informs me that such DI has already been named

[Bryce2471]

Does anyone know of a team who has implemented a DI mode I will call1 a HaloAR (AR=Auto Rotate), as described in this thread posts 5, 6, and 9?

Interesting question, although I can't give you a definitive answer because I haven't seen every omni-directional drive. I can say, that I have never seen one that was programmed like this.

The proposed DI is somewhat similar to the system we will try to implement after we get a regular field-centric drive working. It is also quite similar to a DI that we have planed, and may end up using in future seasons.

I will just explain the one that we are implementing this off season right now. As I mentioned earlier, the primary challenge this off-season competition, is herding multiple 6" foam dodge balls with a three sided corral. The fact that you can only use a three sided corral means that if the robot were to drive straight forward at speed and the stop, the balls that are inside would roll out.

The solution to this problem was difficult to determine, but it is relatively simple to explain. There will be standard field-centric dive code running (one joystick gives field heading, the other gives rotation), but there will be another piece of code that will be added to the rotational part. The code will use an accelerometer to tell which direction we are accelerating, then is will run a control loop to make the front of the robot face in the direction of acceleration to automatically for any motion that the drive makes in field space. Probably, there will be a button that must be held down to enable this driving code, because for some operations in this game, the driver will want to control orientation.
Feedback on if you think it will work or not, and why would be appreciated.

[Ether]

The solution to this problem was difficult to determine, but it is relatively simple to explain. There will be standard field-centric dive code running (one joystick gives field heading, the other gives rotation), but there will be another piece of code that will be added to the rotational part. The code will use an accelerometer to tell which direction we are accelerating, then is will run a control loop to make the front of the robot face in the direction of acceleration to automatically for any motion that the drive makes in field space. Probably, there will be a button that must be held down to enable this driving code, because for some operations in this game, the driver will want to control orientation.
Feedback on if you think it will work or not, and why would be appreciated.

What is the benefit of rotating based on acceleration, instead of joystick angle?

[Bryce2471]

What is the benefit of rotating based on acceleration, instead of joystick angle?

Good question, essentially because the balls always want to roll in the direction they were previously heading, and so we want to adjust that heading with the back of the robot. Also, many times, the robot's acceleration is not in the direction of joystick position.

Here's an example. Driver presses left on the joystick causing the the robot to accelerate left in field space. The robot automatically rotates to be facing left, just as it would if the code followed joystick position. Then, as the driver approaches where he wants to be, he slowly lets up on the joystick. with code that is tied to the joystick, the robot would continue to be facing left until it came to a stop. this would allow any balls that are being corralled to escape. If the code is tied to acceleration, then as the driver lets up on the joystick, the robot will be accelerating to the right and so the robot will turn around to and catch the balls.

As far as I can tell, this sort of thing applies to all situations, so the driver ideally won't have to worry about orienting the robot to move the balls around.

[yash101]

I'm not trying to grief here, but 28 pounds for the drivetrain sounds horrendous! I do not know how much our mecanum drivetrain weighed, but I know that it is well under 28 pounds!

[Bryce2471]

I'm not trying to grief here, but 28 pounds for the drivetrain sounds horrendous! I do not know how much our mecanum drivetrain weighed, but I know that it is well under 28 pounds!

I'm not sure where you got the 28 lb figure, but that is irrelevant. This is one of the lightest swerve drive train that i know of. The point is not to be lighter than a mecanum drive. The point it to out preform a mecanum and try to stay as close as posible on weight. But, in some ways you are right, one of the disadvantages of swerve drive is the weight.

Look at it this way, there's over 15 lbs of motors. Maby someone will point out that there is a swerve that weighs much less, and prove me wrong.

[yash101]

The first post shows it on the weighing scale.
Also, mecanum gave all the performance we needed. Your robot gets as good as your drivers get. Crappy drivers and a million dollar robot would be worth pennies. Great driver and ten dollar robot would make the robot worth millions, (if you think of it in money). In this case, the money is the points!

Also, doesn't swerve have a high latency? As of what I know, holonomic drive can have very little latency

[MichaelBick]

Also, doesn't swerve have a high latency? As of what I know, holonomic drive can have very little latency

A good swerve doesn't have high latency, though it will have a bit.

[Gdeaver]

No, it's even more. Add the motor controllers and wire to that weight. Yes, there is a big buy in for swerve. For this reason I would tell the largest majority of First teams to look at the cad models and learn but, do not do swerve. It is not for you. Perfect a 6 wheel drive and devote the rest of the teams resources to scoring mechanisms. There are a few teams that have the resources and ability to pursue swerve or other complex drives. The poster appears to have the capability and commitment to do swerve. The rewards can be big. Putting aside the competition aspect of swerve and think how much knowledge and skill a swerve project can give students.
Yes, swerve does affect the weight budget of the robot. That leads to another favorite subject of mine. How do you build light weight strong structures to make up for the weight that was put into the swerve? Composites. I try my best to get as many students as possible to assist in at least 1 composite project.

[DampRobot]

I'm not sure where you got the 28 lb figure, but that is irrelevant. This is one of the lightest swerve drive train that i know of. The point is not to be lighter than a mecanum drive. The point it to out preform a mecanum and try to stay as close as posible on weight. But, in some ways you are right, one of the disadvantages of swerve drive is the weight.

Look at it this way, there's over 15 lbs of motors. Maby someone will point out that there is a swerve that weighs much less, and prove me wrong.

If your swerve really weighs 28lbs (which I doubt includes everything, but nonetheless), then it's extremely light. 28lbs is a pretty decent weight for a WCD, at least in my book. If your drivetrain's over 40lbs (not including electronics), only then might weight be a potential issue.

Oh, yeah, one more thing to add. It's been said many times before, but not in this thread (at least as far as I can see). You've probably already figured this out, but swerve is a ton of work, not just in terms of design or programming, but also in terms of raw manufacturing time and effort. Be careful before you decide (especially before the season) that because swerve is so awesome and you've done it in the offseason that you should do it in-season. Just in terms of manufacturing and assembly time, you could essentially free up enough time to do a full manipulator iteration in season by choosing a WCD or an off the shelf drivetrain over swerve.

All in all, cool swerve, and it looks like you've had fun building it! Congratulations, you've succeeded where many have failed.

[yash101]

If done correctly, mecanum will also get the same things done. Our robot was able to push the other robots around at competition. With locking mecanum, we will be able to stun the other teams when we enable it and sideload ourselves, making it impossible for us to be moved! I will inquire about how much our drivetrain weighs tomorrow, when we have robotics.

[MichaelBick]

If done correctly, mecanum will also get the same things done. Our robot was able to push the other robots around at competition. With locking mecanum, we will be able to stun the other teams when we enable it and sideload ourselves, making it impossible for us to be moved! I will inquire about how much our drivetrain weighs tomorrow, when we have robotics.

Not quite. There is no real replacement for traction and a second speed.

[yash101]

Locking mecanum makes your mecanums into regular solid wheels, giving you a greater traction.

If you want traction, here's what to do next:
A claw drive system that uses claws to pull the robot along. Things can easily get impractical :(
:deadhorse: :deadhorse: :deadhorse: :deadhorse:

[MichaelBick]

Locking mecanums doesn't change the interaction between your wheels and the ground(traction). Swerve can run much higher traction wheels. Furthermore, it still doesn't change the fact that a swerve can run two speeds.

[Ether]

Locking mecanums doesn't change the interaction between your wheels and the ground(traction).

Yes it does. He's talking about locking the rollers. See posts 5 & 50 of this thread (http://www.chiefdelphi.com/forums/showpost.php?p=1300510&postcount=5).


Swerve can run much higher traction wheels.

You can make mec wheels out of high-traction material if you've got the budget to do it.

[s_forbes]

Very impressive drive system. Now that you have one iteration done and currently testing, you can continue to develop and make improvements to put yourselves further ahead than a large majority of teams for the 2014 season (assuming that a swerve drivetrain is beneficial next year...) Abuse it until you find what breaks!

I am curious about the Black and Decker gearboxes you used. Do you have more details on what model you purchased and what modifications you needed to make? I'm a fan of cheap off the shelf components like this.

I'm not trying to grief here, but 28 pounds for the drivetrain sounds horrendous! I do not know how much our mecanum drivetrain weighed, but I know that it is well under 28 pounds!

I don't believe that I've ever helped construct a FIRST robot with a drivetrain that weighed less than 35 pounds. I would argue that reducing the weight of the upper structure of the robot is much more important. If you have a 28 pound drivetrain and 92 pounds worth of other mechanisms/components, then the drivetrain is not the part that needs to be redesigned.

[Bryce2471]

Also, doesn't swerve have a high latency? As of what I know, holonomic drive can have very little latency

I'm confident that this swerve will not have latency problems. The modules can turn at around 120 rpm and still have enough torque to spin the wheel under load. the wheels will never have to turn more than a quarter turn, so the most you could wait to drive is .5 seconds. In practice it turns out to be much less than that. When driving it, the latency is not even noticeable.

There are a few teams that have the resources and ability to pursue swerve or other complex drives. The poster appears to have the capability and commitment to do swerve. The rewards can be big. Putting aside the competition aspect of swerve and think how much knowledge and skill a swerve project can give students.

Thank you, It's cool to here someone that has done this several times has confidence in us. I agree, even if this project never gets used on a final FRC season robot, there will have been a lot of benefit to the team from what we have already done.

[MichaelBick]

While being pushed from the side it does increase traction, however from what I understand it does not increase traction while pushing head on. Regardless, swerve can run super grippy wheels that mecanum cannot(2" wide rough top).

[tickspe15]

Where is the 28 pound number coming from. OP says it weighs 37 pounds in his first post.

[Bryce2471]

Where is the 28 pound number coming from. OP says it weighs 37 pounds in his first post.

thank you, I don't understand where that came from either.

I'm not trying to grief here, but 28 pounds for the drivetrain sounds horrendous! I do not know how much our mecanum drivetrain weighed, but I know that it is well under 28 pounds!

Although this is the first time it's brought up. I guess some people didn't read my first post.

[bobcroucher]

I'm confident that this swerve will not have latency problems. The modules can turn at around 120 rpm and still have enough torque to spin the wheel under load. the wheels will never have to turn more than a quarter turn, so the most you could wait to drive is .5 seconds. In practice it turns out to be much less than that. When driving it, the latency is not even noticeable.

At 120 rpm, a 90 degree rotation only takes 1/8 second. That's probably why it feels like less than 1/2 second.

[Andrew Schreiber]

If done correctly, mecanum will also get the same things done. Our robot was able to push the other robots around at competition. With locking mecanum, we will be able to stun the other teams when we enable it and sideload ourselves, making it impossible for us to be moved! I will inquire about how much our drivetrain weighs tomorrow, when we have robotics.

Congrats, go start a thread on it so I can go grief about how my 8wd will weigh less than it… Seriously, are you contributing anything to this thread other than your infatuation with your drivetrain? There's a million threads about people talking swerve vs mecanum, go necro one of those.

[AdamHeard]

At 120 rpm, a 90 degree rotation only takes 1/8 second. That's probably why it feels like less than 1/2 second.

Based on our swerve and 1717's, I'd say you can gear your turning faster. Easily in the 180-200 rpm range and get a responsiveness gain.

[Bryce2471]

Based on our swerve and 1717's, I'd say you can gear your turning faster. Easily in the 180-200 rpm range and get a responsiveness gain.

I believe the current gear ratio is faster than 1717's. Our current ratio is about 87:1. The number 120 was just a number I chose because it's in the middle of the motor's range. Thanks for the suggestion though.


On a side note, here is a render of a future frame I CAD'd. It is built with a 110" perimeter. The swerves are 3" wide and 9.375" long. Sorry for the low quality render, but it was my first time trying to making a render.

https://scontent-b-sea.xx.fbcdn.net/hphotos-prn2/q71/s720x720/1451543_634867079898229_782556496_n.jpg

[AdamHeard]

I believe the current gear ratio is faster than 1717's. Our current ratio is about 87:1. The number 120 was just a number I chose because it's in the middle of the motor's range. Thanks for the suggestion though.


On a side note, here is a render of a future frame I CAD'd. It is built with a 110" perimeter. The swerves are 3" wide and 9.375" long. Sorry for the low quality render, but it was my first time trying to making a render.

https://scontent-b-sea.xx.fbcdn.net/hphotos-prn2/q71/s720x720/1451543_634867079898229_782556496_n.jpg

Ah, I assumed you were quoting free speed. Yes, you are geared faster then.

[yash101]

thank you, I don't understand where that came from either.



Although this is the first time it's brought up. I guess some people didn't read my first post.

Sorry, I was talking about the 7 pounds per transmission


That's pretty cool. It seems much easier to build because the parts are more spread apart!

[gpetilli]

Gdeaver alluded to the importance of swerve/omni Driver Interface (DI), and that segues into a question I've been wondering about lately.

Does anyone know of a team who has implemented a DI mode I will call1 a HaloAR (AR=Auto Rotate), as described in this thread (http://www.chiefdelphi.com/forums/showthread.php?p=1279133#post1279133) posts 5, 6, and 9?


1until someone informs me that such DI has already been named

Yes, FRC1559 is planning this for 2014. We are implementing a fusion sensor of a compass and gyro in a velocity PI loop. The gyro is the P velocity feedback and the compass is the I feedback (conceptually it directly reads the integrated error).

When turning, the current heading is updated to the current compass. When not turning, the PI loop is closed loop to hold the heading (which helps reduce affect of gyro drift).

At initialization, the robot snaps a zero heading. At any time the driver can press a "hat" button to command the heading to be one of the primary orientation (plus maybe feed station). The PI loop will drive the orientation while the driver continues to command XY translations.

We have this working with our asymmetric Killough drive, but only have about 30min of testing under our belt. Focus has moved to a similar fusion PD loop for X and Y with a follower wheel for velocity error P and an accelerometer for the differential error D.

[yash101]

This is partially off topic, but if you were trying to lock direction/orientation using a gyro or accelerometer, would you use a coprocessor or would you use the cRIO? Don't you need to continuously monitor it to make sure that the results are accurate? Also, what about some mechanism that works like an array of optical mice? I guess that the FPS would be a tad high for the mice sensors, but it should be able to gather movement!

[magnets]

Yes, FRC1559 is planning this for 2014. We are implementing a fusion sensor of a compass and gyro in a velocity PI loop. The gyro is the P velocity feedback and the compass is the I feedback (conceptually it directly reads the integrated error).

When turning, the current heading is updated to the current compass. When not turning, the PI loop is closed loop to hold the heading (which helps reduce affect of gyro drift).

At initialization, the robot snaps a zero heading. At any time the driver can press a "hat" button to command the heading to be one of the primary orientation (plus maybe feed station). The PI loop will drive the orientation while the driver continues to command XY translations.

We have this working with our asymmetric Killough drive, but only have about 30min of testing under our belt. Focus has moved to a similar fusion PD loop for X and Y with a follower wheel for velocity error P and an accelerometer for the differential error D.

That's really neat. I've ever thought of using two different sensors, an angular rate and an absolute rate sensor as two different sources of feedback for a PID loop. Out of curiosity, which compass sensor are you using and have you had interference issues in the past?

[magnets]

This is partially off topic, but if you were trying to lock direction/orientation using a gyro or accelerometer, would you use a coprocessor or would you use the cRIO? Don't you need to continuously monitor it to make sure that the results are accurate? Also, what about some mechanism that works like an array of optical mice? I guess that the FPS would be a tad high for the mice sensors, but it should be able to gather movement!

You would use the cRIO. The cRIO is perfectly capable of doing all the math fast enough for any FRC task excluding vision. We've played with the loop time to see how the responsiveness changes, and you can't tell the difference between 20 Hz (50 ms loop time) and 100 Hz (10 ms loop time), both of which the cRIO can do easily. Once you start going faster, you don't gain anything. The mechanisms themselves don't respond fast enough, the motor doesn't have enough torque to make a noticeable change in 1/100th of a second.

[gpetilli]

This is partially off topic, but if you were trying to lock direction/orientation using a gyro or accelerometer, would you use a coprocessor or would you use the cRIO? Don't you need to continuously monitor it to make sure that the results are accurate? Also, what about some mechanism that works like an array of optical mice? I guess that the FPS would be a tad high for the mice sensors, but it should be able to gather movement!

Multiple threads have tested the cRIO and claim it has more than enough compute power. The standard driver station "periodic" rate is 20ms, which is what we are currently using.
The X,Y movement will use something similar to a mouse. We are using a 3D printed fork assembly to mount two orthogonal un-driven VEX 2.75 omni-wheels with VEX encoders tied to the cRIO FPGA to measure in/s. We are not using encoders on the driven wheels given the amount of slip we expect from a Killough drive.

[gpetilli]

That's really neat. I've ever thought of using two different sensors, an angular rate and an absolute rate sensor as two different sources of feedback for a PID loop. Out of curiosity, which compass sensor are you using and have you had interference issues in the past?

We are using a 9DOF IMU called a GY-85 which we got on ebay for $16 including expedited shipping (from Hong Kong so still took a week). It has a 3axis compass, 3axis gyro and 3axis accelerometer all on a single I2C bus which we tied to the DSC. The board is tiny (< 1 sq. inch) but does not have a processor. We read the X,Y magnetometer values and compute atan2 on the cRIO.

We originally mounted it on the main electronics board - which worked fine for debugging I2C and gave accurate compass readings... until we drove the motors. We moved it to about 18" above the motors and that seems to be fine. We have not tested it with other robots on the field yet, but given 18" was enough we are hopeful it will not be an issue.

[brianbond]

Awesome design! Question for ya, have you had any problems with plastic gears?

[yash101]

After comparing the "~37lbs" to other drivetrains, THAT IS VERY LIGHT FOR A SWERVE DRIVETRAIN (I think I needed those caps :)). I think that that may be around how heavy the KOP chassey should be! Good work Bryce and Team 2471!

[Tyler2517]

Awesome design! Question for ya, have you had any problems with plastic gears?

If i remember correctly their plastic gears are for the encoders only, they have timing/gate belts for the drive loads.

On a side not the pocketing on then modules for the encoders was an amazing idea. The weight of the swerve is the lightest I have ever seen and will only be getting litter by the time of next season.

[M3rcuriel]

Yes, FRC1559 is planning this for 2014. We are implementing a fusion sensor of a compass and gyro in a velocity PI loop. The gyro is the P velocity feedback and the compass is the I feedback (conceptually it directly reads the integrated error).

When turning, the current heading is updated to the current compass. When not turning, the PI loop is closed loop to hold the heading (which helps reduce affect of gyro drift).

At initialization, the robot snaps a zero heading. At any time the driver can press a "hat" button to command the heading to be one of the primary orientation (plus maybe feed station). The PI loop will drive the orientation while the driver continues to command XY translations.

We have this working with our asymmetric Killough drive, but only have about 30min of testing under our belt. Focus has moved to a similar fusion PD loop for X and Y with a follower wheel for velocity error P and an accelerometer for the differential error D.

Have you guys found that using this sort of PID loop is more useful than using other sensor integration techniques such as a Kalman filter?