If you’re going to make your robot a “low rider”, the suspension needs to be pneumatic. Also you are required to style your bot as a '66 Impala.
Which way is a caster drive traditionally driven? This could have an impact on the handling- as would the gear reduction in the pod vs. outside of the pod (see: https://www.cycleworld.com/sport-rider/how-motorcycle-swingarm-adjustments-impact-traction/)
What’s the stroke of the suspension (full rebound to full compression) and the approximate/predicted spring rate?
Why stop there? Go full-on inverted pendulum! iBot swerve drive!
I think we’re going to need a cost cap. I just don’t know how we’ll be able to keep up with innovation like this.
It can dive in any direction relative to the wheel orientation. However, when traveling any significant distance, the wheel will be pushed to trailing position.
Here the bumper I’m using: https://www.mcmaster.com/93115K111/
It’s rated for 210 lbs. and the travel is 0.375, so the spring rate is probably a little less than 560 lb/in. At full compression, the bumper is compressed by 0.2 in, so that probably won’t reach its max load rating, but it might be close.
You have 2 choices of which way to drive the wheel. The wheel can push toward the axis of rotation or it can pull away from the axis of rotation. If the wheel is pulling from a leading position, the steering system is going to be inherently stable and require very little torque to maintain the correct direction when driving straight or change direction slightly to the left or right. Pushing from a trailing arm position is inherently unstable and the arm is going to try to spin around. You can control this with the steering motor, but it will not naturally want to stay in that position - you need to hold it there. I am not sure how large the loads are to hold it, but they are probably higher than centered swerve drive loads. Probably your largest loads come into play when going around corners where you would need to resist lateral loads. These lateral loads multiplied by the length of the arm become the torque that you need to resist with the steering motor (added to the toque from the drive motor).
The opposite stability comes into play when braking. i.e. a pulling position is stable when driving but unstable when braking and a trailing position is unstable when driving and stable when braking.
So, I don’t think it matters whether you drive from a leading arm position or a trailing arm position. I think you will end up dealing with the same turning loads and stability issues either way.
This is awesome! Keep it up.
Thanks for the post. This is an interesting take, but I don’t think it’s true. I think you are falling victim to the pendulum fallacy. If two forces have the same magnitude and the same line of action, they should have the same effect when applied anywhere along that line of action.
As far as the steering torque caused by the drive motor, by my calculations 75% of it should be counteracted by offset of the dive wheel.
I agree that when the line of action is aligned with the axis of rotation, that the system will be stable. And since the line of action of the wheel in any single module always goes through the axis of rotation of that module, it will not produce any lateral forces to upset that equilibrium.
As you stated in your post, when travelling any significant distance, the wheel will align into a trailing position. In order to do this, the axis of rotation needs to move along the line of action as the line of action becomes aligned with the desired direction of travel. So the actual path of the robot would do a small hook to one side as the modules align themselves to the direction of rotation.
But, now picture the situation where you have two modules on the two front corners of the robot and each one is pointed out to the side by say 45 degrees (the module on the left side is pointed out to the left and the module on the right side is pointed out to the right). As you start to drive forward and those two modules try to align themselves with that direction of travel, you now have forces that appear at the wheels that are no longer aligned with the line of action. The wheels end up needing to skid sideways a bit as the two wheels oppose each other. I believe that in this situation, ‘pushing’ from a trailing arm position would result in the two arms turning outward more rather than aligning with the robot direction of travel.
I’m pretty sure you will easily be able to counteract this torque on the module with the steering motor. But if you freely castered the modules and applied no steering input, I think the system response would not be to just fall in line into a trailing position.
I really like this! The placement of the bevel gear is a bit retro, but it involves fewer custom parts. and still packs nice and small. My only critique would be that I think you need a 4" wheel for most FRC games.
great idea! I came to this topic expecting a weird spring design but got something awesome! great work!
I particularly like how the bumper is a Mcmaster part that can be easily replaced, simple and ergonomic!
How/why did you choose the spring force to be 560 lbs./in ?
This is one point where I disagree. I think with ideal software, the pivot would trace a straight line, when requested to move in a straight line regardless of the wheel orientation. Meanwhile the wheel would ideally trace a pursuit trajectory like this:
This is a very interesting hypothetical, not one I had considered before. Thankfully, our team has a functional caster drive robot. (Here’s some videos of it) So we can test it in practice.
If you arranged the three wheels of the robot so the rear one was facing back (trailing) the front left one was 45 degrees left and the front right was mirrored, then powered only the front drive motors, I would wagor the robot would move forward before the wheels would slip, and in that motion I think the front wheels would straighten out.
Maybe next time I see that robot I’ll run the experiment and take a video!
That’s sick! Are there any noticeable improvements in driveability or responsiveness over regular swerve?
So a robot with 4 of these would essentially be an IKEA shopping cart propelled by a hyperactive toddler — “IKEA DRIVE” if you will.
Would this still be true for a drive train with suspension? While designing this, I started to think that it might actually handle the 1" bumps this year pretty well.
Thanks! Yeah I wasn’t finding a simple way to contain a spring. I really started this design expecting it to be totally impractical, but I was surprised that it increasingly didn’t seem that bad. Still wouldn’t beat a swerve in any reasonable weighted decision matrix, but it would make for a fun offseason experiment.
I didn’t. This is further evidenced by the fact that I actually miscalculated that figure. I forgot to divide the max force by the lever ratio. The correct(ish) number is about 275 lbs/in.
What I did was choose a bumper and lever ratio that would cause the max load rating of the bumper to create over double the nominal weight taken by one module (~25% of robot weight or ~40 lbs). I did this because I wanted the wheel to be somewhere in the middle of travel while sitting on flat floor.
Not really haha! I will say that it is very fun to drive. There is definitely no delay to your inputs, and it feels like they are more closely connected to the forces on the robot.
However, the fact that its wheel modules are big and heavy combined with non equivalent gearboxes on the drive and steering caused wheel direction flips to not be super smooth. Besides that, the robot is very heavy (id guess almost 300 lbs) and is somewhat under powered. That is compounded by the fact that its motors must produce all driving forces including cornering forces (Where a swerve does not use motor power to produce cornering forces). So it feels a little like driving a air hockey puck by pushing it with a leaf blower. It also suffers from instability because of its relatively high center of gravity and 3 wheel configuration.
All in all though, I would say it was a big success for its application. It’s a blast to drive, easy to pick up, looks very flashy as a demo bot, and was a cool experience to get going
Suspensions (at least ones like this… shrimp rovers are a different story) don’t lessen the horizontal force required to get over a bump, they only deaden the vertical impact from landing (but not the horizontal impact from hitting the bump to begin with). So you’ve solved certain aspects of the problem.
I don’t mean overall ratio. I mean that reducing the final belt reduction (while adjusting the pre-belt reduction to maintain the same overall gear ratio) will cause the pod to oscillate up/down as a consequence of the belt tension pulling the wheel up (or down) (depending on which way the pod is driven). It’s kinda a wacky phenomenon… the same one that makes rocker slide drives work. I have no idea what the rammifications (positive or negative) of that would be. Obviously motorbikes are able to make it work but the real tuners are conscious of the effect.
Probably more like reduced one aspect of the problem. I think the other aspect in this case would be aided by the leading edge of the module being a low incline ramp. Here’s what it might look like hitting a 1 in barrier:
I see what you mean now. Sorry for misunderstanding your initial post.
Because of the steep angle of the suspension arm. I think this module will have quite a bit of what that article calls anti-squat. In this case I don’t think it’s ideal, as long as the robot has a fairly low COG though, I don’t think the 3/8" of travel will cause any stability issues. The weight distribution should be improved during acceleration by the wheels being offset to the back of the robot. However, the wheel offset will have a detrimental effect when coming to a stop.
I think you are right when you bring in the software side. I can see how the steering control can easily pull the modules into line to keep the robot moving along the desired path if the arms are in a trailing position. I don’t think there would be a solution if the arms were in a leading position.