Liking the use of VS Code for programming Hopefully the exposure we’re giving it in WPILib will make teams like it even more. Reading through the blog one thing we are looking at adding is a JNI template to make it trivial for Java teams to use C++.
On the technical side, just wow. No wonder the undefeated season. The attention to detail is immense.
I’m surprised by your use of physical limit switches instead of the number of software based options (monitoring current to detect hardstop, dead reckoning into hardstop with a low current limit set, starting robot within 1 rotation of absolute on the mag encoder, etc.). While I generally agree with the “Don’t use software to fix hardware” sentiment, physical limit switches seems to me like an additional point of failure that could of been avoided considering your control system prowess.
Without having read their code yet, I assume that they used the limit switch to re-zero the elevator whenever it triggered, not just at the beginning of the match. We did the same thing to keep our closed-loop control accurate: whenever the elevator was commanded to zero our PID loop took it there, triggering the magnetic limit switch, zeroing the elevator encoder counter. Running a zeroing routine multiple times during the match would be a lot harder than implementing an indexing switch. And if the switch were to break, the elevator (probably) starts at zero at the beginning of auton so it would be no less accurate than only zeroing once at the beginning of auton.
The REV hall-effect limit switches are great. We used them all over the place. My favorite feature is the LED, which makes spot checking power and magnet placement dead simple.
We wire the switches directly to the Talons they control, providing a hardware interlock to safeguard our robot from bugs (oops, wrong sign!) or bad tuning (wonder what happens if we multiply Kp by 10) during development, bringup, and practice. We used the LEDs on our carriage to communicate that everything has been properly detected as homed before the drive team leaves the robot.
There are tons of reasons why this is a superior solution to doing something entirely software based:
You are robust to the robot being turned on in the wrong configuration, which in our experience will happen at least once regardless of your best efforts to train people.
Current limits for hard stops mean are hard to implement well. There are lots of reasons why current can suddenly spike, leading to false positives.
You can home the robot by hand while disabled, which means you don’t need anything to start moving automatically once the robot becomes enabled. This is huge for safety in the pits.
As mentioned above, gives programmers freedom to iterate with the knowledge that the Talons will keep the robot safe. Plus at some point, someone will wire something backwards…
Replacing an encoder doesn’t require any sort of recalibration to be done.
Generally handles unexpected situations gracefully. For example, we had issues with our wrist Talon encoder browning out (long wire run) before moving it to a CANifier, leading to all sorts of unexpected movement that took a while to debug. The hard limit kept us from smoking motors or bending metal.
You can pair the limit switches with redundant layers of soft limits to mitigate against hardware failure. For example, we have sanity checks on the setpoints we generate and then use Talon soft limits as well. By the end of the season, I think we were only using the limit switches for homing, once all of our controls had stabilized and we had de-gremlified things. But earlier on, the ability to use the sensor as a true limit switch saved us several times.
That’s not really what I’m asking. In industry as more advanced control system have become widely used It’s become pretty common to try to remove physical limit switches (hall effects, inductive switches, etc.) as they foul, become disconnected, shift or can be triggered accidentally.
Here are a few ways of zeroing without a hardstop:
Dead Reckoning: Have the mechanism drive itself for a number of seconds into a hardstop at a low voltage or with a low current limit set so that nothing will be damaged when stalled. After a certain amount of time you can assume the mechanism has reached zero and zero out your position (usually you’d want to have your robot start close to the hardstop). If you want to get a little fancier you can try to monitor your encoder and detect when the mechanism stops moving but is still being given voltage. That would then be your zero. There are a number of 3D printers that zero like this (set stepper driver current to a low amount and run into the hardstop)
**Current monitoring: **I’ve seen this one used a couple times on industrial servos and it would be straightforward to implement in the Talon SRX. Just drive the mechanism into the hard stop and look for the current spike when it hits the hard stop. That then is your zero. You might need to add something to filter the current spike during initial acceleration.
Using absolute mode as a index: Using an absolute encoder is a straightforward way to remove the need for a limit switch but it may not always be possible to mount the absolute encoder on the final output shaft. On something like a wrist you might have a VP with a mag encoder stage on the final output of the VP and a 3:1 Chain reduction going to the wrist. This would normally make the absolute mode of the mag encoder useless but what you can do instead is always start your robot with your wrist within the same 1/3 of it’s rotation (1 rotation of the mag encoder) and use the absolute reading to reference your relative wrist positioning.
It’s also always a good idea to implement some sort of manual mode in case your encoders fail or zeroing fails for some reason. This saved our butts a couple times this year.
Obviously these solutions may not be optimal in all cases and there are of course situations where using a limit switch may be easier/simpler to implement. I’m just a little surprised that these alternatives aren’t more common. I’ve used these sorts of strategies on a few different robots and it’s always been a successful way to increase our robot’s reliability.
I was wondering about using a hall effect as the limit switch for the Talon SRX. From the description in their datasheets, the Talon SRX is looking for a switch closure for their limit switch connections. In order to use a hall effect you would need to power and connect the hall effect to the Talon in order to voltage reference it to the Talon. Could you please comment on how you connected these sensors to the Talons?
The hall effect is just a switch. Just run the power and ground to a Talon breakout and then run the signal line to the limit switch pin.
We did something similar but we weren’t happy with the hysteresis on the REV hall effect switches after some testing - I’m guessing it would have been fine but it caused some worry. LittleFuse makes some hall effect limit switches with integrated timers (and a handy LED) that seemed to have more repeatable results.