My team’s software is going to record the number of balls we’ve shot by detecting dips in flywheel speed. How would one go about implementing this given that we’re using encoders and recording data periodically to determine speed.
Maybe bybusing PID you xould do a function that checks the D value and hownit changes after shooting each ball. Also checking speeds with encoders.
Once your shooter’s up to speed, you can just look for sudden negative spikes in the acceleration (take the discrete derivative of encoder velocity)
Spikes in the current, as measured at the PDP, will correspond to dip-and-recovery of the shooter speed.
or as simple as(if you have pid) just reading out the percent output of the motors
In industry, I have seen similar problems solved using an “arm and trigger” algorythm. In this case, you would measure the speed of the motor. If your speed typically dips by 10% with each shot but otherwise stays within 1% of the set speed, you set an “arm” level at 98% of the set speed and a trigger level of 95% of the set speed. As the motor comes up to speed, it passes through the “arm” level. Once the program is “armed” it is watching for the speed to drop below the trigger level. When it does, you record the event. After the shot, as the motor comes back up to speed, it will pass through the arm level again and the whole process starts all over. There are more sophisticated algorithms, but this should work well and is very simple to implement.
I concur with @wgorgen 's answer.
Choose a metric based on what you see fluctuate the most in response to shooting a ball (Current draw? voltage output? shooter speed? shooter speed error? shooter speed derivative?).
Regardless of which you choose, there will be some level of filtering or debouncing to remove the noise:
The elegance of the “arm and trigger” method, is that the trigger occurs on the first crossing of the threshold on your plot. The system does not arm again until the speed rises up to the arm level again so you only get one trigger even though the speed signal might have a lot of fluctuation. There is no need for filtering or smoothing.
Right - I interpreted the arm&trigger algorithm as a specialized “debouncing” algorithm. One or the other, probably not both.
The point I was really trying to get at: The trivial single-if solution:
if( value < threshold && prev_value >= threshold){
count++;
}
isn’t going to produce happy results in the presence of noise.
Gotcha.
And I agree.
What @wgorgen is describing is called “Hysteresis”. It is commonly used to reject noise in industrial systems and can be implemented in hardware or in software. I have come across systems that used noise filtering preceding the hysteresis function when there is the possibility of noise phenomena that is of very short duration (i.e. one or two samples long) relative to the signal that one is wanting to detect.
Detecting the spikes in motor current, as @Richard_Wallace suggests, may be the most straight-forward and most way to do this. The mass of the flywheel naturally damps out most noise sources. Even teams that do not closed loop control (no encoders) can use this method if they are using motor controllers with current detection.
Gotcha - I’d assumed this was sort of a “belt and suspenders” thing, but thinking through it I could probably construct a system where this makes sense.
Shot noise could definitely mess up the an algorithm that looks for single loops of samples above/below a threshold. However, shot noise is easily countered with a median filter.
Also, on a speed sense system, shot noise often indicates a deeper mechanical or electrical problem, not just something “inherent” to the system.
Yup yup - even the PDP might suffice for this operation.
Any signal can be susceptible to EMI noise spikes and those noise spikes could pass through these arm and trigger levels. If this EMI noise cannot be filtered out of the signal using a low pass filter of some kind, the most robust arm and trigger systems employed on a noisy sensor signal would use “hold off” functions where the arm or the trigger is delayed by a short time to ensure that the signal remained above or below the respective threshold. But it is better to filter out the noise if you can.
The arm and trigger algorithm can be used on any parameter you can measure. It works just as well on current at the motor controller or speed at the wheel; whatever parameter you have available to feed into your detection algorithm. I would pick the parameter with the cleanest signal or the parameter that you are controlling to. If you are controlling speed of the wheel, I would use speed of the wheel (and since the OP used that in his topic, I suspect he has that). But, if you have a flywheel where the speed dip is low and it is easier to see the effect of shooting the ball in the motor current, it is completely valid to use that.
The key is to have a wide acceptance band in your thresholds. If the speed typically dips by 10%, you don’t want to set your threshold right at 90% because if it only dipped 9.9% on one shot, you would not trigger. This is why I used 95% in my example as this gives you a lot of margin for shot to shot variation in the speed dip. Similarly, if the “typical” speed fluctuation when not shooting (when just holding a steady speed with no load) is 1%, you want to at least double that (hence my arm level of 98%) to give yourself some margin for tolerance. You can play around with these values and see what works.
I have also seen examples where the arm is below the trigger, so you would arm early on the upsweep and then trigger immediately on a noticeable downsweep. This is typically used when you are trying to get accurate event timing rather than just counting events. This case does not seem like that is needed.
If you’re using Command-Based, you could write a Class that extends Button or Trigger that “triggers” based on the various arm and trigger and other suggestions shown above and have it schedule a command to do the decrement.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.