I’ve developed some classes throughout the course of build season this year that have extend off some WPILib classes to provide added functionality.
I pushed them into another repository so that they can be easily cloned if you’re interested.
Some features include a base class for stall detection on Jaguars and analog channels, as well as a Joystick extension that provides support for different drive modes.
Check it out! There’s a lot more that can be done with this, and my thinking is that a lot of other teams have to frequently build off WPILib to add a feature that they need. If you’ve done this in the past, please fork and submit a pull request so we can build a more comprehensive library of features that people might need to use. This might be helpful to teams who are tight on time or with rookie programmers.
-For stallable, there’s a much more efficent way to implement this that dosen’t require For loops (those are always the enemy of realtime embedded controls) - using a racheting error counter. Basically, you have a single number which is the number of iterations of good or bad data. You sample the data at a constant frequency and perform the delta comparison each time. If the data is good, you decrement the error counter by some number (for 100hz systems, 3 or 4 seems about right). If the data is bad, you increment the counter. To sample the state, you return a gt check on the counter vs a constant. To reset the state, you just reset the counter to 0.
You could also replace the entire limit switch class with an inlined function for efficiency. Also, I believe you want the comparison to be 0== instead of 1== due to the pull-up resistor (the logic line would idle high and be pulled low by pressing the switch, a 0== compare would return 1 when the switch is pressed).
Thank you very much for your sound advice. I did not know what an inline function was in C++ until you gave me your suggestion to implement one it did make sense to use a simple function.
Originally we had thought of using a Queue for Stallable so that we could easily push data through (we shuffle through our array of collected voltages right now), but the rookie we were working with did not know much about programming so we thought it would be a good idea to teach her some basic concepts like looping and such before handing her more complicated data structures. Even though iterative looping might not be the best approach on our hardware, the array is very tiny, and we have a hefty 700Mhz processor to work with so we should be fine for now.
Your solution was still much more efficient than dancing through a queue, and we will implement it once we’re actually done with our main robot code.