2 drive motors, because I’m using this to cad a triangle minibot and wanted to go zoooom.
I’m a bit worried about the very small amount of wrap on the driving pulley - does anyone have anecdotal evidence to back up something similar?
Drive gearing is very aggressive - 3.27:1, for a free speed of 22.7 ft/s. Again, this is for a minibot, so this is intentional. Without too much editing this could definitely be turned down, if anyone wanted to use this on an actual bot for some reason.
Steering gearing is a 1 stage UP followed by 10:52 belt, for a ratio from 15.03:1 to 27.2:1. Assuming a 5:1 UP stage is used, this is a bit on the aggressive side but reasonable, according to the 30:1 that tends to be recommended.
Weight according to Inventor is around 5.25 pounds, with weight of 3dp parts from Eiger.
Total print time (with everything Markforged) is 39 hours and cost is $38.86.
(actual print time may vary - for this estimate I used default settings on every part except the magnet holder, which had minimum infill set)
The UP output is once again replaced with a 3dp part to reduce part count and mount the pulley closer to the face of the UP. Still working on getting actual data on maximum load for that, but according to @Ryan_Dognaux if the spline is printed with a 0.003 offset from the REV cad, “it doesn’t easily push on but light arbor press seems to work.”
Inspiration mainly taken from here (if it wasn’t obvious)
This is really awesome looking! I especially love the 3D printed motor pulleys-over-gears trick. But I think you might be solving a problem that doesn’t exist? If you are indeed making a lightweight demo bot (< 100 lb?), you are going to be traction and/or current limited whether you use 3, 4 or 6 motors. Punching some numbers into the ILITE drivetrain simulator, with 6 motors (assuming 3 modules) geared 3.3:1, and a current limit of 40A per motor (240A total to avoid brownout) I get 2.7s for a 40ft sprint (which is as long a sprint as you’d ever need in FRC):
Unless you plan to use this bot for longer sprints outside an FRC field, the extra 2 or 3 motors may not be worth the cost. OTOH, continuous peaks of 80A may be enough to overheat the NEOs, so check that before you take my advice
I was curious, so I checked to see what the “perfect” amount of power would be to accelerate 100lbm at the traction limit (~1g) for ~40 ft (~1.6 s). The answer is 3.4kW, or about 10 Neos / Falcons / CIMS running flat out:
This is a good illustration of the difference between an “ideal” calculation, and a more complicated simulation like ILITE, which shows how the system losses due to motor efficiency, electrical resistance, and gearing friction prevent you from ever putting those extra motors to much use.
I personally think your belt set up will work, but what is stopping you from just running 2 9mm belts rather than 1 long 15mm belt? I think a 9mm belt is appropriate for a neo output, but I could be wrong.
Also, if you want to lower the ratio a bit, we have used WCP 8mm bore pulleys with pretty good success: WCP - HTD Timing Pulleys. This would let you get away with a smaller input pulley.
Just two random suggestions. Looks like a really cool concept overall.
What is interesting about swerve is that the maximum distance of a ‘sprint’ for a single wheel pod can be much longer than for a skid steer. In theory, a swerve drive doing an oval around an FRC could have at least 1 swerve pod always at its maximum speed for the entirety of the oval. A skid steer would likely need to slow down both sides of the drive train just to make the proper turn in the same oval - the friction of skid steer differential just isn’t enough for agile max-speed turns.
The swerve distances are something I hope to investigate myself in the coming months.
I definitely agree that the currents are a bit high for a 3.27:1 drive reduction though.
There is some good zebra dart data out there from the end of 2019 (IRI and a few other events that did some Beta testing) as well as the shortened 2020 season.
That data is a bit noisy, but with some smoothing, you can probably investigate what kinds of acceleration distances, maximum speeds and total “sprint” distances teams were actually seeing in the 2019 and 2020 games.
We spent some time looking at the zebra dart data off of our robot from our 2020 event and concluded that we were hitting and sustaining the maximum drivetrain speed over relatively long distances. We concluded that we wanted to gear for a higher speed as long as our drivers could control/steer the robot at those higher speeds. We did some limited testing over the summer with the lower gear ratio and concluded that a) it was controllable and b) it reduced our cycle time (albeit on a practice field without defenders, or other robots to swerve around).
The ILITE simulator was very helpful in comparing the effect of gear ratios. Our max sustained speeds and acceleration distances matched up fairly well with the data (once we smoothed it out a bit). So, that was encouraging. Our lower top speed, higher acceleration gear ratio was theoretically friction limited. We could not see that in the data, but our drivers did report that they could feel the wheels slipping on the carpet. With the higher speed, lower acceleration ratio, they did not report as much wheel slip. I hope we get some zebra dart data for this lower gear ratio at some point so that we can see the differences in top speed and acceleration in the data.
At the end of the day, the ILITE sim assumes that wheel speed = robot lateral speed, and iirc lateral speed is what Zebra DART measured. But in the case of a swerve moving around on the field and rotating its swerve pods, an individual wheel’s speed may be much greater or much lower than the robot’s lateral speed depending on the rotation of the pods.
Zebra dart uses 2 tags on the robot, typically placed on the left and right side of the robot near the center of the wheelbase length. I believe that they were only used to try to establish the direction that the robot was facing at any given time and honestly, we did not use that data in our analysis of our robot performance. The main output of the zebra dart data is position (x, y) on the field at any given time. You have to differentiate the data to get speed and acceleration. This contributes to some of the noise. But after some smoothing, you can see pretty cleanly the basic performance of the robot (for example, did it ever reach a top speed that was sustained for long periods or was it always accelerating or braking, what was the top speed, what was the typical acceleration profile).
If you are able to get what direction the robot is facing (from the 2 tags) and also see what direction it is actually moving (from the x, y data), you can probably work out what the modules were doing. For example, if the robot is translating along a straight line, but rotating, then you should be able to calculate both the rotation angular speed and the translation speed. Getting to actual module wheel speeds from there would require you to know the wheelbase length and width (as well as probably knowing where on the robot the tags were placed), so it does get a bit messy.
But in a fairly general sense, if you are watching the video of the match at the same time that you are looking at the Zebra Dart data, you can fill in a lot of the blanks yourself and get a pretty close approximation of what the modules were doing.
