As an off-season project, I am tackling a swerve drive. It is a modification on the GBX-136 design on grab-CAD. I have changed it to accommodate a 4" AM wheel in hopes that it may be able to handle some basic obstacles, because it isn’t a custom wheel (though it is modified), and because our team has a bunch lying around. However, with the current reduction on the CIM motor (designed for a 2.5" wheel), it would go 28.3 ft./sec with the 4" wheel. If I change the bevel gear set up to 3:1 rather than 2:1, it would go 18.8 ft/sec. Is this okay, or should I shoot for slower? The original set up with a smaller wheel would have gone 17.7 ft./sec. What maybe be some problems with having too fast of a drive train?
Here is an image of the modified design.
Sent from my iPhone using Tapatalk
Neat that somebody is using my base for a swerve drive! I like what you’ve done with it, although the smaller bevel gear could use a support bearing inside the fork. You also should mess with the tiny upper bearings somewhat; under heavy side loads those will pop right off (something I didn’t not consider when designing it). I recommend putting the large turning gear on top of the bearing
I like to run fairly fast, especially if we’re talking about this year. 18fps is about good, although 19 is definitely doable. Keep in mind that those are free speed numbers, and works out to ~15fps adjusted.
Thanks for the input! I will probably keep the large turning gear on the bottom to take some of the thrust from the weight of the robot, though a different solution to hold it on would have to be devised. In terms of the cantilevered bevel gear needing support, I will probably have to thicken the fork to embed a bronze bushing into it to support the end of the shaft. Next on my agenda though is to off-set the wheel slightly. Right now, when you are steering, the wheel will rotate. This causes the robot to move and squirm when steering, a problem I have noticed with other swerve drives. The wheel off-set would allow it to roll around a path with an equivalent circumference to the amount the wheel would rotate with one revolution of the motor. I hope that makes sense, thanks!
Sent from my iPhone using Tapatalk
Other things equal, the faster you’re geared, the poorer your acceleration will be for a given current draw, or equivalently, the greater current draw will be for a given acceleration. That extra current is turned quite efficiently into heat in the motors, breakers, speed controllers, battery, and wiring. That heat leads progressively to reduced performance (due to higher resistance), tripped breakers, and smoking components. These issues can be mitigated by reducing your weight-to-motor ratio, whether through more modules, more motors per module, or a lighter robot.
Actual drive speed, I’ll put in my two-cents.
It depends on your robot and on the game. If you have a lightweight 70-pound + bumpers robot, and the game is wide-open where scoring is benefitted by high speeds to cross the length of the field like Steamworks did, you should gear for a top speed of about 15 ft/sec or more. I don’t see that your 18 right now is reasonable.
But if the game involves slowing down and accelerating again in multiple places, if it involves obstacles to actually climb, pushing and if your robot is near the weight limit, you should gear to 8-10 ft/sec.
Most swerve, including yours, are single speed. Single speed is fine for most robots and games but you need to use the “low” gear that you’d use in a two-speed. For most games, the acceleration you’ll get back will almost benefit you more than a higher top speed.
Also, when figuring the top speed just using algebra, I recommend you don’t actually use the published ‘free speed’ of the motor, since it will have load from your gearing system. For a CIM, free speed is listed at 5330 rpm. I would figure top speed using about 4800 rpm or even 4500. You could test this.
Running a gear train and especially using a bevel gear, you’ll be losing some free-speed power to inefficiency. A bevel gear is only 93 to 97 percent efficient, so you’ll use up about five percent of your power on that.
There are many swerves that don’t use bevel gears and If I was planning one, I’d consider these. Who wants to give up five percent?
My team has built a couple of over-geared robots and it’s painful. Motor controllers amp-out in tight turns. Motors are too hot all of the time. Looking slow because of bad acceleration makes people not pick you, even if you are fast in a stretch.
For reference, the AM14U3 this year is geared 10.71, for a 5300rpm free speed of 13.02 ft/sec but a more realistic free speed (4800rpm) of 11.7 ft/sec. This is with no bevel gears to waste your energy.
When you start, you say “we’ll only be 70-80 pounds, so we can go for 15 ft/sec”, but then you add this and strengthen that and end up at 119.
With two cims per side on a custom single reduction (12:72) gearbox 1058 was able to achieve 14ft/s measured speed (geared for 15) and we were roughly 115 pounds (add on bumpers and battery to that as well). In addition we could play defense if needed, but the drivetrain was mostly suited for offense. In our second round robin match on Einstein we were running gears for most of the match and at the end played defense in an attempt to slow down the blue alliance’s gear running. It’s a good example of versatility on a single speed drivetrain. While 18fps might be a bit high for a 4 cim swerve drive, 15 is probably the sweet spot and 10 is most definitely too slow in a game like Steamworks where you are cycling long distances multiple times. An efficient and simple drivetrain geared higher with a slightly longer acceleration time looks better in most teams’ eyes than one that is capped at a slow speed like 8 or 10 fps - just from what we look for, anyway.
1072 geared for 16.5fps (the highest we could achieve with our gearbox design) and in hindsight we were annoyed that we couldn’t gear any faster. 299 used a KOP chassis and only geared for around 13fps, and we suffered immensely for it. Had we geared for 18+fps we would have been far more successful due to the long driving runs in this years’ game.
For 2016 16fps or 13fps would have been fine.
You do have some good points that your speed can create a cap especially in cycling years and with how many matches teams play nowadays you can start hitting that sooner compared to earlier games.
I would however argue the opposite. To clarify some numbers from Emile, he is extremely close but our actual speeds are slightly slower. Our free speed is 15.5 fps and actual more in the 12-13fps range.
Something I learned from 2013 while on 3467 as we geared too high and became a large problem in later parts of the season specifically Battlecry. Going into IRI we added slightly more reduction to our drivebase by swapping from 15t sprockets coming off our our ballshifters to 12t. What we noticed at IRI and later events was our extra fifth cycle before a 30 point climb was more frequent since our driver was spending less time adjusting from high speed turns and misalignment and was more focusing on precise moves on the field that increased our cycling efficiency.
This carried into our design this year on 1058 where we geared high enough that we weren’t the slowest on the field yet slow enough that we had the control we needed.
Additionally, your mechanism design is an important factor in increasing cycling efficiency. We opted for a floor intake paired with a fish eye camera (thanks 319) so we could avoid the finesse of lining up downfield to the human player working around other machines and fuel. Other teams like 5687 used large funnels to reduce the requirements on lining up. They also added wedges in the front of their gear mechanism that help guide a spring into a gear in their robot giving them a larger sweet spot when scoring on a peg.
Little things like that can go a long way towards your match efficiency when coupled with trained drivers. My advice is never gear your robot faster than your driver can handle. You hit a point where increasing your top speed is only shaving 1-2 seconds off of a 25-30 ft sprint before its time to line up to game elements and exercise precise movements. There were machines with speeds faster than ours that we played against and could cycle faster than them head to head or maintain a similar pace.
For comparison we were geared at 18.8 fps free speed this year in high and 7.1 fps in low. We achieved around 14 fps in reality. We had 2 CIMs + a mini per side and weighed ~115 lbs + battery and bumpers. It should be easy to find some video of us playing with 1058 in Archimedes elims and Einstein so you can see how different free speed gearing impacts cycling. Our driver this year was one of the best we’ve had so maneuvering was not a big issue, but wouldn’t recommend going single speed tank drive at 18.8 fps - I agree with Brendan there. You might be able to get away with it from a maneuverability stand point if you have swerve though. I wouldn’t know - no experience with it. Either way I wouldn’t run anything at 18.8 fps off 4 miniCIMs.
I shared this info on another thread I thought I’d put it out here too.
Some performance trivia on our swerve if you want to compare notes:
15 fps at 85% motor max RPM.
0 to max speed in 10 ft.
50 amp current limit using the Talon’s current limit.
Against the current limit for the first 3 ft.
Robot weighed 119.6 lbs. + battery + bumpers
We found 50 amps was about right to keep the 775s from being destroyed AND to stop from tripping the main breaker AND keep our driver from complaining. Even at 50 amps we could still trip the main breaker if not careful.
Our driver’s priority was purely offensive; swerve and evade. If you watch the video’s from worlds, it will give you an idea of what 15 fps can do on an open field with a well driven swerve.
As others have indicated, your top speed goal is dependent on the game and the driver skill. It’s easy to see that you don’t want a 20+ fps robot in Stronghold unless you can drop it down with a 2 speed. In contrast, a 20+ fps could work with a totally open field like Ariel Assist.
QFT, and emphasis.
Drive trains must enable the robot to do that which is needed to score, as often as possible. The driver is the most critical component of a drive train.
Training is the most important factor in building a great driver. We geared our drive train faster this year, but only after the driver and coach had trained enough to know they could handle it.
Drive train + driver training => effective mobility.
Feel free to take this as it is, our bot for this summer is currently geared for about 23fps in high and 10.5 in low but getting around 18.5fps in high and 8.5 in low. Once we replaced our front aluminum with a steel plate and brand new tensioners we could hit pretty hard without falling apart. However our electronics set up is a little sketchy and our bot isn’t afraid to throw a main breaker. My take on it is if you have good connections and a driver that can handle the speed your good. Did I mention we’re running custom tracks and 6 cims 
We geared rather aggressively as a new team, I was one of the people arguing against such a speed but what can I say. If you observe some of our matches, you can see that the driver definitely had significant difficulty using the robot effectively. For example, turning in high gear is basically impossible. I also had to build some code to limit acceleration because we would “jump” onto balls (case in point: semifinals @ seven rivers), though I think that is more due to our huge wheels (another choice I personally argued against). By the time worlds came around, he had it down, but our first regional was pretty bad.
Based on the speeds given by the EVO-Shifter product page, we were running 13.18 ft/s in low, 23.85 ft/s in high (CIM speed estimated at 4100 RPM). This was a 2 CIM, 2 Stage gearbox with 8" wheels. In reality, I believe we were a bit slower because the 8" pneumatic wheels are not truly 8".
We really motor when we want to though. Imagine trying to defend against a max-weight robot (we weighed in at about 115 lb) hitting you at 20 ft/s.
However, we were limited to about 3-4 cycles per match. Why? Because our gear manipulator required the robot to line up, wait for a gear, jerk backwards, jerk forwards, wait for the gear to fall, then race back across the field. Probably spent half our cycle time on that.
Speed definitely can result in higher scores. However after a certain point you must be using multiple speeds. And acceleration is definitely something to keep in mind.
Could you provide more details about your system? I know 115 geared for at least 22fps in high gear with 4 CIMs and had no issues turning. If you were using pneumatic wheels then not having enough center drop can be a very real problem.
Turning in high gear at high speeds was the issue. If we did the robot tended to end up going much too far in the direction we had intended it to go. The robot would also stall if we tried to go from a dead-stop to turning in high gear, which I attribute to a lack of weight balancing*. We did wrap the wheels in duck tape as an experiment, it handled the same except it was able to turn in high gear in the dead-stop condition. We later removed the tape to increase our traction. The other, potentially related issue we had was frequently breaking wheel hubs.
*I wasn’t very involved in building/designing the robot (at least as far as mechanical problems go), being the entire programming team and half of electrical. Which is understandable, since I was the only team member with previous experience (FTC).
Over-turning while driving in high gear was likely due to high-sensitivity of tank drives to turning at high speeds. Unlike Ackerman drives (cars) where you can make small, precise orientation adjustments at high speeds, tank drive turning will usually be much jumpier. There are a number of things you can do to correct this, including better driver UIs and closed-loop driving.
Not being able to turn in high gear from standstill is almost definitely related to a too high gear ratio. It could also be not enough drop center, but that would make more sense if the robot couldn’t turn at speed also. Especially if the robot was stalling and then stopped stalling when you lowered the CoF of the wheels. This shouldn’t be a problem though, because you can just downshift if you need to turn at standstill. In fact, your driver should almost always downshift when the robot is going slowly or you need to make small adjustments or you stop and go again because that will give you more precision and lower the current the motors draw when you start sprinting again.
115 ran a medium-fast gear ratio (17fps free) in 2016 with 4 CIMs on a 6WD with 8" AM pneumatic wheels. We suffered from problems turning from a standstill, but not while moving (because the radius is larger and we had momentum), until we added a 1/4" drop center. The gearboxes also had lots of friction from an unknown source. Once we added the drop center we didn’t have any more issues.
A common fix that year was to put duct tape on the wheels either to reduce turning scrub or to add extra drop center, or both. Even gearing as high as 24fps will still let you turn from a standstill as long as your center drop is ok. Using a slower gear ratio can alleviate the problem, but dropping the center more on pneumatic wheels is a way to do it without sacrificing power.
We built a swerve this year, geared for 21fps free speed. It was way too fast.
The high speed was useful for dodging defenders, but our acceleration was pretty terrible. A good hit could rob us of a few valuable seconds due to the current needs of getting up to speed.
A more useful speed for a swerve would be closer to 18fps free.
A more important consideration than the gearing is the driver skill. A less skilled driver would NOT have been able to handle our system this year. Whatever system you construct MUST be compatible with your driver’s skill and practice level.
Depends on the game- where are you trying to get to?
In other words, what’s your sprint distance?