Done both, most recently NEO flywheel on the 581 robot. No issues getting that working.
7 Likes
I think the obvious solution here is just an âalternate encoderâ. Sure, its some extra hardware over the falcon, but the Neo is also significantly cheaper. We ran into this issue with our shooter, and ran it mostly with feedforward (it had some PID constants, but they were fairly small). I think we would have gotten some small benefits with an external encoder, and I think we were to do a flywheel again, we would run that external encoder to at least see if we get some improvements.
I wonder how a CIMcoder would do in this application.
2 Likes
Does this discussion warrant moving to a different thread?
14 Likes
It does, somewhat, but thereâs two problems with doing that. The first is that sending the encoder values to the roboRIO adds up to 20 ms of CAN latency because the robot code doesnât act on the measurements synchronously. 3512 tried decreasing the status frame period to 10 ms and below, but that resulted in zeroed out data frames, even with just the shooter motors on the bus.
Hereâs what 112 ms of delay looks like with the optimal feedback gain (using the Python script from my earlier post), for comparison:
and with 20 ms of delay with the optimal feedback gain:
The second problem is your time measurements must be accurate relative to your position measurements. If they arenât, you can get velocity measurement noise on the order of 100-200 RPM (mattered for us, but may not for you). I donât have the original data from 3512âs tests, so Iâd have to mock up a simulation, but I donât have time to do that right now, and I donât even know if that would convince you versus actual data.
Application of a moving average filter doesnât help because it delays the signal too much, so the flywheel doesnât react quickly to disturbances. What 3512 ended up doing was using a real-time thread to do the quadrature encoder and time sampling.
Tapping into the encoder wires is going to be super noisy, if thatâs what youâre suggesting.
By the way, Iâm not saying a flywheel with NEOs canât meet performance requirements. Iâm saying that velocity feedback with the built-in encoder wonât work; youâll be operating with feedback gains so small, itâs effectively feedforward-only. That can work for some teams, but it didnât for mine.
6 Likes
How many Lâs turned into Wâs or Wâs turned into Lâs do you think the collective group of teams most angry about this 100ms filtering window would have had over the last 3 years, had it been fixed already?
17 Likes
It definitely impacts odometry and tracking for autonomous and we also had to work around it for our move and shoot code to work better by using acceleration to predict actual current speed via a 0.100s*Accel type adder. Using a time-based pose estimator is not perfect here either because the module rotation is almost real time from the analog encoder.
Obviously, it is not going to make or break anyoneâs abilities, but less latency does help make things work better. I hope REV has at least investigated making some improvements here, heck even a small configurable range or multiple modes where the teams can choose to accept the chance for noise issues.
7 Likes
We are working on a firmware update to the SPARK MAX that will enable configuration of the filtering parameters so that the filtering delay can be reduced. You will be able to adjust the sampling delta (8ms to 64ms) as well as the number of taps (1,2,4, or 8).
This feature is in development so I canât share any additional details at this time and it may change before release.
45 Likes
Is it possible to say if this firmware update will come before kickoff?
1 Like
Yes, we intend to release before kickoff.
19 Likes
Is it possible to say if this firmware update is free? Asking for a friend.
13 Likes
While I know this is a joke, I wanted to say that I would gladly pay for new software features that were not advertised in the initial product release.
Paying for previously advertised but not yet delivered upon features or bug fixes is lame, but paying for new software features makes sense, as long as itâs priced appropriately.
9 Likes
You know, I was thinking similarly, but on the other side of the situation. If something appears as a feature in a new product release, should my mind wonder âgee I wonder if this promised feature is a paid feature or included feature.â
Sad days.
1 Like
This and future updates will be free of charge. 
61 Likes
Glad to see this update is FOC (Free Of Charge)
27 Likes
Chief delphi dislikes single reaction gif posts, and instead likes some words to help keep a high quality of conversation. I donât have any great words to describe my emotions about this, so instead Iâll describe the no-single-reaction-gif guideline rather than do anything really meaningful. Hopefully this helps reduce any potential issues.
Re: adjustable filtering parameters
12 Likes
Can someone dumb down some of this for me? as stated above, was the 100ms filtering due to noisy hall effect sensors, . will the unlock of these features yield noisy results?
Or does this feature (free) addition make the neos one step closer to falcons in terms of programmability.
Well TBD. Iâm mostly excited about having the number to play with, as it enables teams to pick an appropriate level of filtering for each application.
There was some talk many moons ago how the underlying sensor hardware may still have a lot of noise in it [Citation needed]. That may mean, ultimately, âbest performanceâ means turning a bit of filtering back on. Maybe even all of it. Not sure.
In any case though, allowing the user to control it is a good upgrade for the teams looking to squeeze every ounce of performance from the hardware.
For a lot of teams though, probably not revolutionary?
Weâll see more details this season. But itâs either neutral or better, which makes me happy.
(hopefully obvious, I donât work for rev, and am making a lot of assumptions about whatâs coming from the description provided. But even if I got all the assumptions wrong, Iâm still excited).
2 Likes
At lower speeds, using a filter smaller than 100ms will yield weird results, if youâre just counting edges in a period. For example, at 500rpm, a NEO only has 35 hall sensor edges in 100ms. That means that it might fluctuate from 34 to 36 depending on where you take your measurement, which is a wiggle of around 6% total. So it might measure 485 to 515rpm. If your filter was only 20ms, that uncertainty would go up by a factor of 5, leading to what looks like a noisy measurement with +/-75rpm of noise. This is why time-stamping and averaging like 6328 does works well - it relies on the precision of the timestamps, not the number of samples. I wish the SMAX did this natively, but Iâll be satisfied with an adjustable measurement window.
2 Likes
So 6328âs approach is not just a configurable version of whatâs done natively?
1 Like
Would it be equally as effective to use an external encoder like a Cancoder using PIDController to set voltage?