Motor temperature affects the operating curve of the motor, but it’s tricky to measure/estimate and would add a whole lot of complexity to integrate with a controller. I don’t know of anyone who has actually done this in FRC.
Motor performance varying with temperature is one of the many reasons why we use closed-loop control. Over the past few years it’s become popular in FRC to use accurate models to provide feedforward “guesses” at what outputs we should be commanding for better transient response, but this is never going to be perfect.
One specific thing to keep in mind here is the idea of overhead. Hot motors are less efficient, drawing more current (and dropping your battery voltage) more for the same amount of mechanical work compared to cold motors. The same automated routine that works great with a full battery and cold motors will need to draw more current/cause more voltage drop with a half-dead battery and warm motors. Make sure that you design your entire mechanism (mechanically, electrically, and software) such that when your feedback controller needs a couple more volts to compensate, they are available.
We didn’t originally go through the trouble of making custom fits for our wrist gearbox. With COTS hex shaft and hex-bore gears, our wrist worked just fine, but we had to slow down the acceleration/velocity and feedback gains to avoid oscillation and overshoot. It was still in the realm of “good enough”, but we figured that spending a few hours making custom fits would let us get faster and give us more headroom for 4-cube auto (I think we were able to increase acceleration by ~50% and double our P gain afterwards), so we did it.
One note for others here: putting the sensor on the output-side of the backlash helps for some aspects of the problem, but not all. Here’s a great article on the topic of motor control in the presence of friction and backlash.
The big part of colocating the sensor is that it provides observability to the system. However as Jared mentions it doesn’t necessarily improve controllability.
Ever since out first swerve total system backlash on the wheel steering has been a problem. Auton has been a nightmare for long runs. Last fall we looked into the sources of the backlash. We eliminated the mechanical wear on shaft pulley interface but, the 2 planetary gear boxes typically used in FIRST simply wear over the course of competition to the point they kill our autons. We searched for better low backlash planetary gear boxes. The price of the good ones is a killer. We found some Chinese NEMA 17 100:1 precision planetaries. These are typically used with NEMA 17 steppers. To interface with an Andy Mark 9015 we source a RC car pinion. We also 3d printed a motor gearbox adapter plate out of PETG Carbon. The NEMA 17 nose mounting could not handle the torque. We Printed an adapter plate also out of PETG Carbon. We also used our previous design of using standoffs to mount and tie the mounting adapter and motor adapter together. These gear boxes are excellent. 3 districts, MAR champs,and worlds - No increase in backlash or wear. We could not have done our cross court autons without The backlash project. So glad we did this last fall. Backlash should be killed when ever possible.
Fixing the hardware instead of just “fixing” it in software?
Question for Jared, or anyone who’s been in a similar design discussion: How did the conversation go that led to this decision to re-build the mechanical side to improve the controllability of the system (and allow for more aggressive PID gains)? Traditionally, I’ve seen this being a very hard thing to do, from a team aspect (mechanical/software tend to be too “siloed” to accomplish this). Do the folks in charge of the mechanical side understand the control theory that drives this? Do your software team members discover/communicate this need back to the mechanical team? Are there individuals with experience on “both sides” who can coordinate this?
We are doing mechatronics. We learned the hard way over the years that we can not have programming and mechanical working in isolation. We take great effort to keep the teams working together. To solve some of the control problems we have had takes both parties working together to solve the problem. High speed video and graphing system inputs and outputs have helped immensely with the diagnosis. If on your team the programmers sit in a class room buried in their screens and the mech are out in the shop making noise, your team has a terrible problem. Find a way to make it a group interaction. Methods and process. We quite often have mechanical and programming getting into heated arguments. This is a good thing.
What is your practical approach to break down mechanical and programming silos. Do you make of point of telling the teams to consult each other on problems, or even have the two groups do robot design together? Do your programmers maybe work alongside in the same room as your CAD people? My team isn’t old enough to have developed silos but I don’t want silos to develop in the first place.
I came up with a simple and effective way to get rid of most of the backlash in hex bore gears. I put a hex shaft collar next to the gear, drilled though both of them and inserted a roll pin. This was done on a milling machine. Once assembled, tighten the shaft collar, and the backlash in the hex bore is essentially gone. Obviously this doesn’t get rid of backlash in the mesh of the gear teeth, but that’s a different matter entirely.
The nice thing about this method is it is very easy to do, and it much easier to assemble than shims or tight hex shafts.
But how does an inexperienced student design in that headroom? 192 solved it by making students build mechanism prototypes that “must work” off beheaded 12v NiCaD drills. Once the prototypes worked with the small batteries and finger triggers, making them work on the robot was a piece of cake.
So for 841 I picked up 8 of these 12v drills, cut off the heads, and put PowerPoles on them this spring. Looking forward to implementing next season.
Looking back at OP’s topic though… this tip definitely falls more under “give your team tools to observe backlash early and often” than “this is how we pull it out of our mechanisms”
If you use my calculator to help design your mechanisms, you can set the voltage applied to the motors to 10 or 11 volts. That way if your actual applied load should increase above what you put in the calculator as the expected load, you still have some headroom for the motors to give more power before maxing out.
And that right there is the roadblock that I’m getting around by asking students to “make it work” at prototype phase with limited power & control dexterity
One we have a functional prototype, we can measure stuff off it, and refine it with a calculator. But I’ve found that asking for too much math up front can intimidate my students into inaction ::ouch:: I’d rather meet them where they are than act as a mathematical gatekeeper.
We’re thoroughly off topic now.
Using spring loads to keep backlash in check is my favorite “FRC-ready” method for manipulators (<360 degree motion / single direction). Surgical tubing is magic, just wrap some on there & trust. Your students will need to experimentally determine what the “right amount of magic” is, you’ll probably never put a firm number on it for design, and for four hours (1 season) machine operation? I’m OK with that.
Love this. Could probably do it on a drill press?
I’d want to do it with a miniature VEX collar, but not sure how big a roll pin could fit through the “meat” of that shaft collar. What kind of loads were you putting on this?
For sure you could do it on a drill press. I think the roll pin was 3/16", but it might have been even smaller. The loads weren’t very high since the arm was very well balanced with a gas spring.
