Good question. Here’s what we’ve experienced from a mechanical and software perspective:
This year we went with a belt-driven hood actuation instead of a rack and pinion mostly due to space constraints. The shooter & tower were originally designed for a 2 position pneumatic hood, so we didn’t have the foresight to leave much room behind the hood for any activities, such as a rack and pinion. Additionally, the belt-driven actuation didn’t require a ton of parts to be redesigned which helped us save some time on manufacturing & assembly and gave us more time to tune it and rigorously test it in practice.
We were initially using a 3D printed pulley here because we needed an abnormal tooth count to account for improper belt tension (a manufacturing issue). That plan changed when we found that the pulley teeth were being crushed — this was probably a combination of this pulley making the belt too tight and also the high amount of torque at that stage of the reduction. To circumvent this, we ended up using an aluminum 18T pulley and adding a makeshift tensioner.
If we were to design a motorized hood in the future, we would more than likely try to go with a rack and pinion. From what I’ve seen and heard, it appears that the rack and pinion hood designs are generally pretty robust and avoid some of the issues that our hood design had this year. It seems to be what most teams are doing with motorized hoods nowadays, so there are a ton of great designs out there that we would shamelessly copy (1678 2022, 2910 2020/2022, 254 2020/2022, 4414 2022 to name a few).
It’s worth noting that the rack and pinion hood designs become a bit different if your shooter is atop a turret, especially for a game like 2022 where your lowest hood angle is probably pretty low. The rack doesn’t really have much room to exist since it can’t interfere with the turret feeding path, which greatly reduces the amount of rack that is available to move. As far as I can tell, I think this is why 254 and 4414 have their rack as the stationary part and located at the “edge” of the turret, while the pinion is the moving part (which is different than the “typical” design where the rack is attached to the moving hood, like 1678 2022). You can see this in 4414’s & 254’s behind the bumpers.
I know @saikiranra might get upset with me with all this turret talk, but I figured I’d mention it just in case
From a software perspective, our main concern has been maintaining an accurate measurement of the hood’s position based on the NEO’s encoder. Backlash in the system turned out to be less of a concern than we expected since the weight of the hood was sufficient to keep it in tension. However, we had some issues at Greater Boston where the belt would slip by one tooth on the small pulley. This caused an error of ~10° in the hood measurements.
We initially noticed this because of some significant errors in the robot’s vision pose measurements, which rely heavily on the hood angle. Starting midway through many matches, all of the measurements would be several meters too far from the target. After further investigation, we discovered that the individual corner translations didn’t form a very accurate circle for the odometry pipeline (left image below). Shifting the hood angle by 10° in replay fixed the issue completely (right image below). By pressing down on the hood, we discovered that it could slip relatively easily — the difference in angle was almost exactly 10°.
As if that evidence wasn’t sufficient, here’s an example of what the calculated poses looked like before and after the change. The solid robot is the original pose and the translucent robot is the corrected pose (along with a screenshot from the match video).
This is yet another example to add to our list of “problems that were solved many times faster because of logging.” The code for the circle fitting visualization above was written after Greater Boston, and we were only able to run these tests because we could replay the matches in simulation with extra features added (including shifting the hood angle). Plus, careful version control at events (see the repo link below) allowed me create the visuals for this post by replaying the exact version of code running during this qualification match at a previous event, despite numerous code changes since then.
See also: EventDeployExtension
At Greater Boston, we homed the hood once at the start of the match by applying voltage downward until it reached the hard stop (which we detected based on when the speed dropped below 1°/s). For Houston, we fixed the slip issue by automatically re-homing the hood a few seconds after each shot. Here’s an example from one of our matches — the robot is to the left of the field, and you can see that the hood briefly runs to the minimum angle several seconds after we take the shot. This strategy proved to be an effective workaround, but the issue of maintaining accurate angle measurements is definitely an important consideration for any hood design.
Hope this is helpful!