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.
1 Like
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.
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.
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?
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.
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…
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.
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.
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?
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.
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?
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
http://forums.usfirst.org/showthread.php?14331-2009-reused-code-1717
http://forums.usfirst.org/showthread.php?15972-Team-1717-2011-pre-season-code
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.
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.
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.
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.