paper: DIY 'encoder stage' for VersaPlanetary

Thread created automatically to discuss a document in CD-Media.

DIY ‘encoder stage’ for VersaPlanetary
by: Nate Laverdure

Procedure for embedding a hall-effect gear tooth sensor within the input stage of a VexPro VersaPlanetary gearbox.

A procedure for adding a hall-effect gear tooth sensor within the input stage of a VexPro VersaPlanetary gearbox. Requires modification of several inexpensive COTS parts; these modifications can be done by any moderately-capable FRC team in a reasonable amount of time and without use of external machining resources. This results in a robust encoder “stage” which performs comparably to a high-quality optical encoder, but for approximately 1/3 the cost.

Versaplanetary gearbox rev2.pdf (1.76 MB)

This is pretty great. A little mad I never came up with this one.

Using the space where the bearing used to be is a great choice. The bearing was removed in the 2nd year because it was causing some misalignment issues since that bearing would have been the third bearing in the VP assembly including the two in output section.

Any reason you couldn’t use the 30 tooth gears in the VP dual input stage adapter? They have an OD of right at 1 in and spin freely in that space. The teeth are a bit smaller but I don’t see anything in the sensor spec sheet to prevent it from working. You would also get a bit more resolution by going up to 30 teeth.

Also were you running the sensor at 12v or 5v?*

OMG awesome sauce!!!

The spec sheet lists the min supply voltage at 4v; so you may be able to get away with running it directly off the DIO port or the data port on the Talon SRX at 5v.

As I’m still looking at this, does anyone know the max encoder rate for the roboRIO and Talon SRX? With 21 or 30 counts/rev at 20000+ RPM we may be coming pretty close to or surpassing that spec. For the cRIO I think we are over the spec. For lower speeds it would be fine and we could also possibly remove some teeth, but I’m not sure how easy that would be.

I don’t post here a lot any more, but I wanted to say congratulations. This is a really awesome design, and brings together so many of the principles I love in good FRC designs: low parts counts, using COTS parts, compatibility with existing systems, etc. A VP planetary with an encoder really has been a holy grail in my mind for a while, and you guys did it (well, did it and then posted it).

I worked on a couple of designs for stuff like this, like an encoder in a hex bearing package, but never got anything as elegant as this. I wish I’d thought of this or that this design had been around in my 100 days.

these modifications can be done by any moderately-capable FRC team in a reasonable amount of time and without use of external machining resources

Well, it’s certainly clear that our team is not yet moderately-capable! (I’m not entirely sure that our mentors are, but I’d give us a 50/50 shot at it, after spending a few more thousand dollars on tools that we never let a student touch.)

Why wouldn’t you let students touch?

I think this can all be done with a hacksaw and a drill press. They did it very well with a lathe but I don’t think any part of this needs a lathe to be functional.

Wow, very cool way to add an encoder. I hope Vex seriously considers adding something like this as an option for VersaPlanetarys in the future.

The only concern I have (aside from the potential issues others have already pointed out regarding high RPM applications) is that, though this setup does track rotations at the motor, it isn’t fault tolerant if some other part of the gearbox breaks.

One of the nice things about most gearbox-mounted encoders is that they are usually connected directly to the output shaft and show its actual rotation (short of a shaft failure, I suppose). With this, if you strip (or partially strip) a gear, the sensor has no way of detecting or compensating for it. Granted, I have never experienced this failure mode on a VersaPlanetary (actually, the only failure I’ve ever had with one was the input coupler itself), but it seems like it could be plausible.

Or I could just be paranoid. :rolleyes:

That didn’t come across quite like I meant it. We would never buy a tool that we would not let the students touch - it makes much more sense to outsource on so many levels, including inspiration. I meant that a couple of our mentors might be able to do the job with tools that our students had never touched; we have yet to have a band saw or drill press or soldering iron see more than a few dozen hours of student use without becoming a less precise tool than it was designed to be. Until we can teach students not to damage the tools, there’s no use in spending thousands of dollars on a tool. It is sort of a catch-22, but so far we’re stuck in it. I recognize that at the root this is more a mentor problem than a student problem - we only have one mentor who uses cutting tools on a daily basis (and those hand tools, not shop tools), and he can’t be everywhere at once.

Also, back to the original project - it might be more efficient (especially if you were to put this into production) to start with 3/16" steel plate (or even better a thick washer) and cut the teeth. The teeth could also then have a more rectangular encoder-like shape.

For production you would probably choose to replace the entire bronze input coupler with a ferrous version that includes the external teeth.

All lathe operations were done on a machine that I picked up off Craigslist for $200.

This is fantastic. I had an idea very similar a couple of years ago, but it never amounted to more than thoughts in my head. We’ve got enough Versaplanetary spare parts, we should be able to try this out. Also, I loved the nice touch of using the potting compound.

AWESOME! This is an amazing modification! A VP encoder stage without adding extra space is amazing! It seems a bit tricky to do right now, but not to the point that it can’t be done. I’ll have to try this on our mill.

EDIT: The Talon SRX has 80,000,000 / CPR maximum RPM. So 80,000,000/ 30 = 2,666,666 max RPM. I think we’ll be fine as far as counting ticks goes.
Does the sensor sense direction? It appears to have a quadrature detection scheme, but I was not sure.
EDIT2: For the CRIO, Ether mentioned that the max polling speed for a quadrature encoder is 2,129 RPM for a 360 CPR encoder in the worst-case scenario. For a 30CPR encoder like we have here, that’s 25,548 RPM max. That should be compatible with your typical FRC motor.

Oops, I have a correction from one of our electrical & controls mentors:


Both optical [US Digital S5] and the Hall effect [Allegro] sensor were powered with the 5V from the RoboRIOs DIO ports.

There was another question about sensing direction - yes the sensor has both A and B channels going to the DIO just like a quadrature sensor.

The RoboRIO samples faster and has much higher bandwidth then the cRIO. 30 cpr at 20,000 rpm is still well within the capabilities of the roboRIO.

What is the limit? Would 10000 cpr at 5krpm work?

Great work. Inspired to look at this sensor for our swerve module. Question. How were the pull up resistor and caps added?

What brand/model of lathe is that? We have been looking for a good one second hand but size is our limiting factor right now :confused:

It’s a Chinese 7x10 similar to Harbor Freight 93212. I’ve since rebuilt it as a 7x16 with a number of other modifications, but stock it would have been able to do this job just fine. They sell new for $550.