I might have missed it, but is there any chance the speed feedback/speed control on the Spark MAX will be fixed before 2023?
(it’s not broken)
When using the integrated sensor on the NEO, it’s nearly indistinguishable from open-loop at stable gains. Position feedback is fine, though.
Oh, did they fix the 100ms velocity filter while I wasn’t looking? That would be great.
I’m still waiting for someone to show me they’ve used Neos and suffered from this alleged “broken” feature. We’ve been using Neos in closed loop position and velocity mode since 2019, and afaik it hasn’t affected our performance. But maybe I have a blind spot.
I did some simulations to confirm what I saw on a real robot in this post:
Back in 2019/2020 it had me convinced there was a unit conversion error in the REV libraries, because gains that ought to have been quite stable were wildly oscillatory. That’s how we found that there was a filter in the first place.
6328 has published the only real data I’ve found on the topic here:
The plots in this post explain the issue perfectly. The speed control latency is a huge disadvantage when controlling things like flywheels (or even potentially drivetrains). People have implemented RIO-side fixes, so I’m confused why REV can’t just make this a configurable window or improve the latency some other way. Personally, I can implement 6328’s library, but it’s cheap ammo for Spark detractors.
If the 100ms filtering window is what is holding your robot performance back, I am envious of your team.
not directed at Anand specifically, just at teams who think that this is the biggest issue to solve in control.
Technical limitations. The hall effect sensors being used for encoding are really noisy and low-resolution, so a lot of filtering is needed. This amount is hard-coded for the built-in “encoder” because reducing the filtering makes the results worse in other ways. Maybe they could use some fancy Kalman filtering based on the current vectors to get a cleaner signal, but that’s hard.
The Spark Max’s alternate encoder support has configurable filtering.
I mean if you want to handwave away problems, go for it, but that just guarantees that those teams who actually do care will just keep using Falcons. Read 6328’s post to see the real-world implications of the filter - it’s not long.
I have read it, and tuned velocity loops with Sparks. It is a problem and can use improvement, but the Spark velocity control isn’t fundamentally broken like your original post seemingly implies.
It is for low-inertia mechanisms like flywheels, as my post demonstrated. The only way to fix it is with an alternate encoder plugged into the Spark Max.
As someone trying to decide on motors and speed controller can you explain in lay people terms what the issue is and what your current solution is?
If this were completely true, then why would it be possible to improve the performance by sampling position and time like 6328? I wonder if they could use a tap from the last 6-42 hall commutation events to calculate the average dT and use that to get velocity, instead of just averaging position samples over a fixed time window. Or averaging hall commutation event dTs over the fixed window.
How much of a difference did you see on controlling your flywheel? Did you use NEOs or Falcons?
See the 6328 post. Basically, the NEO has a large latency attached to velocity readings, so your speed control loop will be operating on an old measurement of velocity. This means that for high-inertia systems, the output is more likely to oscillate when you have high gain (which you need if you want a snappy response).
Our current solution is to do nothing. Our Neo/Spark-powered flywheels for the past two years have not suffered from any PID velocity control problem that I am aware of.
I’ll also point out that for those tests we used a very naive approach to tuning the controller (increase kP until it oscillates at steady state). We were much more careful during the season, relying more on feedforward and being intentional about the shot spacing. For us, working around the filter is more about saving a bit of tuning rather than maximizing performance.
As for the low resolution encoder, the point of deriving the velocity on the RIO is that we can adjust the filtering. The default parameters still provide some filtering, since the unfiltered data is pretty noisy.
Sparks have ~100 ms filtering window on encoder for velocity control, meaning that your current measurement does not fully reflect the actual speed of the motor.
If you are using just PID to control your velocity, you can get too aggressive with your P and introduce oscillations that are hard to get rid of especially with low intertia systems that respond to voltage change easily.
In practice, you should be more heavily relying on feedforward to maintain expected velocity and use PID to get to your velocity faster, as well as should be using a flywheel with more intertia anyway.
You can get more aggressive with your loops on a Falcon compared to a Spark on a few specific configurations of flywheels, but I would argue the difference is negligible in practice (most teams are not limited by spin up time).
I understood some of those words!