Encoder friction

So my team is learning about PID controllers and we decided to build a NBN bot based on some of the world champs, with a heavy influence from DiscoBots - Klay. We are in the initial testing phases and when we add the encoder to the shaft it generates a significant enough load on the system that an rpm drop is noticed. The shaft is as straight as it can be, and the structure has been aligned very carefully. Is there a secret method people have developed for optimizing the encoder coupling to the shaft? Do you grease the inside?
nbn bot.jpg
nbn bot.jpg

Well, first of all, encoder placement is very precise. And what’s said, I’d just prefer putting it one gear lower if I were you. That’s what we did… If you want to do that with your encoders, I prefer zip ties to allow movement and less friction instead of screws.

Been a while since we looked at this, but I would use an IME. IME’s are terrible with static and absolute position, but they are fine for relative position (velocity). So you sample them every 20ms and take the difference between the IME position between samples. The word size is big enough to handle the counts for the 2 mins no problem.

But, we personally didn’t use PID (although we started with it) we went to bang bang. It was simple and quick response for this design.

If you want to use the mud-encoder, then make sure it is back at the motor, no ton the shaft, too much speed for it.

I was told the IME’s were not as good for this application; is that not true? I will try both of your suggestions with the team.

Is the encoder mounted to the flywheel itself? What RPM are you looking at? I seem to remember somebody telling me their encoders literally melted in NBN when they were mounted on the flywheel.

IME’s were fine for the application, our 6430B team used them and were undefeated in World quals. They never failed us and the speed was consistent.
The bang-bang control gave us very good reaction time. However, we didn’t bang-bang all the way down to 0. We would range from 70ish when too fast and 127 when too slow. There is more you can do with that though

@FullMetalMentor Yeah this is the second encoder; the first one seized up. We are really just experimenting at this time but it seems like direct connection to the fly wheel is not going to work.

@[TVA]Delta_III thank you, we will try that.

@TriDragon thank you, an IME would be the most elegant solution so we will definitely try that too.

I’ll try to dig up the code from @Scarr , he had developed it for 6430. It was neat because he even went to the trouble to sync up the motor updates so they wouldn’t lag. This is a limitation of the cortex config, but the solution was pretty neat. @jpearman had a quick example and Sean built on that.

@TriDragon that would be awesome if you could share that with us. I been researching all of the old posts from @jpearman and the many other excellent contributors. I want to have the team try “bang bang”, “TBH” and “PID” just so that they know what they are and how to use/tune them. We have a lift built too and we plan to experiment and learn how to use them in that application as well.

You definitely need to place the quad encoder on a slower axle than the flywheel.

Hard to tell exactly how it’s mounted, but I’ve found that floating the mounting of it helps reduce a ton of friction. Basically mount it with nylock nuts and don’t tighten it all the way. This way the encoder won’t be able to rotate but it will be able to float around a bit to let the shaft find the least resistance possible.

I also believe the IME’s have a bit higher resolution. The being said, since you are just doing this for fun, you can also modify the black/white disk in the IME to increase your resolution. VEX had a printout sheet of these for regular resolution so I asked Karthik during NBN if we could make new ones since the sheet already existed, but he said we couldn’t increase the resolution for tournaments.

1 Like