Wouldn’t this also delay your auto by a couple seconds? Surely you can’t run the motor at full speed to find the sensor for fear of skipping it.
For the steering motor, I see you added an encoder slice to the gearbox in place of the rev through bore encoder (from your earlier Update). As @dydx stated following that update, the gear ratio between your output gear from the steering gearbox and the module itself is not 1:1. Therefore, that encoder will not give you absolute position of the module.
There are effectively 4 ways to get absolute position of the module using an encoder:
- Have a 1:1 belt or gear drive from the module to a parallel shaft that the encoder is mounted to (this is by far the most common method uses by SDS and many other designs that have taken heavy influence from the 2910/SDS design).
- Mount the lamprey encoder magnet concentric to the axis of rotation of the module itself and mount the lamprey sensor to the top plate (with the motor shaft passing through the center of the ring magnet) as was done on 33’s summer? swerve design. This option really only emerged this year with the release of this new encoder so it is not overly common yet.
- Use the encoder in the steering motor to sense rotation at something other than a 1:1 ratio to the module and then either manually set the initial position of the module to 0, or sense the initial position by rotating until you trigger a sensor (like 3737 has done).
- Mount an additional gear set from the steering output shaft to an encoder shaft that has the same gear ratio as the ratio between the steering gear and the module. This is the solution we used in prior years on our module.
Options 1, 2 and 4 will get you an absolute position sense at the encoder that can be used directly in a control loop. Sensing the current orientation of the module using option 3 relies on knowing the initial orientation and then keeping track of rotations of either the motor or some other part of the steering gearbox system and dividing those rotations by the gear ratio from the sensed location to the module to get the module angle.
I hope this helps.
Normally it is faster than that. More like .25-.5 seconds.
Seems pretty fast!..but, not so fast. To Sam’s point:
Let’s say it’s .25 seconds. During this zeroing time a typical WCD robot has gotten a 3 foot jump on you. It is painful to watch your robot sit there for what seems to be an eternity while the other robots are already moving on the floor.
There is also an issue of the zero point moving. In the case of a hall sensor or mag switch, the magnet or sensor moves or in the case of a mechanical switch, well I think we get the idea.
There is ways to address this in software that make calibration of the switch go away but adds time to the zeroing routine.
The 0.25 - 0.5 sec time estimate is about right and perhaps mitigated by a more efficient trajectory over the 15 seconds compared with WCD. We were happy with it. Once zeroed, the NEO encoders were totally accurate to provide direction during autonomous. Our code just adds or subtracts pulses as necessary. We felt the simplicity, weight saving and lower cost outweighed the sub second zeroing.
I can confirm that the “delay” between when the other robots started moving in auto and when 3737 started moving was barely noticeable. In fact, I was not aware there was a delay until I read Derek’s post the other day and I had to go back and re-watch some match videos from the event. It was not until after watching 4 or 5 matches that I was convinced that there even was a delay.
Obviously, if you know which direction the modules are going to spin to try to find the zero point, you can set them up just a little bit to one side of that zero position such that the modules don’t have to spin that long before they find their zero. So, if your auto routine needs the full 15 seconds to complete all the tasks you have programmed, then you can shorten the zeroing time to almost 0 with clever setup on the field before the match.
Since the last time, the focus was on adding the Absolute encoder @Nick_Coussens and @dydx kept recommending (Please let me know if it is done correctly, or if I messed up.)
Remaking the top plate.
Adding some lightening patterns to the gear and top plate, and working on reducing the overall height.
So it’s been 5 months since I have last touched this swerve design. Since then there have been multiple reiterations, but I think it is finally at a point to be built and tested. (Thought the feedback may say otherwise.)
Link to the onshape which showcase the current model, the old interaction in their “glory” if you can call it that as well as many parts in between.
Some of the changes this time around include adding a second shaft with a gearing coming off the versa to get the absolute position of turning.
Changing the turning speed to roughly 275 rpm.
Making a completely new saddle for mounting the forks and recessing the wheel mounts so we can lower the ground clearance.
As well as changing around the packaging altogether.
Any tips, feedback, and opinions on what may have been screwed up are always welcomed. This is my first time ever working on designing or building swerve so I am unsure of anything I may be missing, not taking into consideration or common mistakes/failure points.
I know some people were having trouble when using lamprey encoders and NEO 550s so that may be why. Something about the way the lamprey encoder reads didn’t play nice with the spark max’s.
New rev looks good. Do you have a bearing on the opposite side of the small bevel to help support it? May not be needed, but for a first swerve it’s always good to play it safe where you can.
Good strategy with the encoder. How is the pink gear being made?
The pink gear is a standard 72 tooth gear, currently all the gears are cot vex gears, the saddle and plates will be .25 plates, and the wheel forks will be .5 aluminum.
The bevel gear has a spacer right behind it then the bearing for it on the axel, unless you mean the side by the fork, which it has a bearing right in the fork. Or are you saying right behind the bevel gear should be a gear into the saddle?
Bearing in the fork is what I mean, good job.
Here’s my quick thoughts:
- You may need more than four fasteners to hold the x-contact ring bearing. You have plenty of holes I see.
- I like the encoder setup too! There’s alittle more backlash this way, but that’s probably not an issue.
- You definitely want a second bearing on the vertical bevel gear shaft.
- Using the 60T SDS bevel gear and a small motor pinion might result in too slow a drive ratio?
- Consider making the bottom plate symmetrical (even if it’s wider) so you don’t have to build two versions for either side of the robot. That’s a matter of preference though.
Overall it’s a really great, simple module! If some of the components were available as cots parts (forks), it would be easy for any team to build. Take my suggestions with a grain of salt, as we’ve never actually built a module, just tinkered with designs so far. Good luck!
To answer your questions:
I didn’t notice there were only 4 on each side of the contact bearing, more can definitely be added.
I tried to reduce the backlash by putting a bit of tolerance into it, one of my mentors told me to always include 2 thousandths tolerance for gears. (this may also become printed for the encoder gears to lighten the overall weight.
The bevel gear has a bearing right inside the fork, and the other is in the 72 tooth gear. (photo below)
The pinion on the motor is a 14 tooth. currently, the setup is 14:24 then 15:60 giving a ratio of 6.86 and an estimated speed of 12.39 (free speed of 14.45) I know with the 14 tooth gear it makes it the top plate needs to be attached to the neo before adding the gear, but it was one of the only ways to get a speed that was desired. Wouldn’t be easy to do an Aren hole and using a smaller gear after the pinion would have moved the wheel more offset causing more issues with mounting holes.
The bottom and tops plates are designed that you just flip them both 180 then assemble them to get the other two corners made. so currently this image would be the front left and back right. If you flip both plates then assemble you have front right and back left. We used this same idea this year on 5030 with our drive gearboxes as we had 1 in each corner and it worked well. It is just a point of marking which side is which when you build it to avoid a problem.
For the forks, I am unsure where I would even look to try and find that as a cot item.
Thanks for the suggestions, the design has been constantly being cleaned up and remodeled, hopefully soon I can have some friends build it and test it out, then we can work on cleaning it up based on testing.
This clearance actually increases backlash but helps to minimize grinding and jams caused by imperfections and tolerance stacks.
So Is it better to have the tolerance?
2 thousandths is a good clearance for a normal FRC geartrain. In this case, you want minimal backlash for a low load encoder, so I would probably be comfortable taking it down to +0.001" or even 0.
I’m sure someone give you a magnitude for the difference in backlash; it’s probably negligible.
If you are looking to use COTS forks, I would recommend ours. They will work well with our wheel and bevel gears. All the spacing will be correct for proper bevel gear mesh. The bottom of the module would be the same as an SDS module.
For our robot this year we had a non-symmetrical module but we just used the same one for all 4 corners. Granted, our robot is very oddly shaped but I would say it’s not a big deal in most robot designs
I love the design of the SDS module, especially Mk 3. Unfortunately your forks aren’t drop-in compatible with a simple “3 plate” swerve design. They are shorter than the radius of the wheel (because the SDS module pockets the wheel into the steering pulley). So you’d have to buy the Base Pulley as well, which is bumping up the cost ($84 for all four parts).