I want to thank all of the folks who have updated to the beta firmware and all of the feedback you have given us. We have made a few additional changes, run through extensive testing, and are ready to take this to a full release.
With this release includes an update for the C++/Java/LabVIEW APIs, as well as a GUI update. You can find all of this on our software resources page, or with the direct links below:
As always you can keep up to date on our development process on our public Trello board.
Known Issues
=================
There has been a reported issue with following Phoenix devices in modes other than Percent Output. Thank you @juju_beans for the suggested work-around. We have done what we can to support this feature, but unfortunately this has been a moving target as this has changed from our initial support. Without a spec it is difficult for us to officially support it. We have reached out to the vendor for a spec but have been unable to get the required information. As such, this feature is not officially supported. Instead of focusing support on this function we have worked to implement our new features such as REV Smart Motion and others on our roadmap to remove the necessity of following other motors/controllers.
Firmware Changelog
=================
v1.1.31
Adds new Smart Velocity mode - uses same constrains as the Smart Motion mode but outputs velocity instead of position. This is not a motion profiling mode, but rather provides acceleration limiting as opposed to simple ramp rates.
Improvements to heartbeat implementation.
CAN ID of 0 now considered ‘unconfigured’ and will not be enabled.
Changes the default output range for all PID slots to be [-1,1] instead of [0,0]
Changes setpoint commands to ‘stick’ instead of relying on periodic frames from the controller.
Follow mode can now persists through a power-cycle.
Periodic Status 2 (position data) frame rate default changed from 50ms to 20ms.
Watchdog changed to 220ms.
Proportional blink codes while driving now have a minimum blink rate (minimum is same as 10% applied output blink rate).
Fault flag ‘over voltage’ replaced with ‘IWDT Reset’.
Velocity and Position conversion factors are now used for all internal PID calculations.
v1.1.26
Adds new Smart Motion mode utilizing trapezoidal motion profiling
Improvements to velocity decoding for low speeds and associated PID control loops requiring control at low speeds
Improvements to gate driver fault handling
Adds voltage compensation mode
Adds ability to set the stored sensor position
Adds ability to set the max PID integral accumulator value to prevent integral windup
Adds ability to set the PID I accumulator value
Adds filter function to PID derivative value
Adds closed loop current control
Adds closed loop ramp rate separate from open loop
Adds ability to follow Phoenix 4.11 motor controllers
Note: The ability of this feature depends on the firmware of the Phoenix controllers, and is not controlled by REV. We will do our best to build this functionality, but this is not an officially supported feature.
Adds ability to set a unit conversion for both velocity and position units
Adds ability to reset to factory defaults
Improvements to smart current limits
Improvements to current data sent over CAN
Improvements to internal settings table implementation
Calling the constructor no longer resets the encoder count, this must be done manually by running CANEncoder.setPosition()
API Changelog
=================
1.1.8
Adds smart velocity mode
Fixes inversion issues for IMaxAccum and Output Range
Updates heartbeat implementation
Adds default slotID for setDFilter() functions
Updates heartbeat rate from 50ms to 25ms
Changes fault flag for Overvoltage to IWDTReset
1.1.6
Improvements to setInverted()
New API calls for new firmware features
Better error message in Java when CAN is not connected
Not real thrilled with this change. We like to set the CAN ID to match the PDP slot so that the graphs/logs we obtain from the driver’s station match the CAN ID as it makes things easier. We started this practice a few years ago. It has made things a lot easier than having to look at the log and then either the IO list or the robot (which may be in a bag when we review all logs after the competition is over to see if there is anything to learn – and there often is). We have found it a lot easier to refer to it as motor X and know that the PDP slot and the CAN ID are in sync (never have to ask if what ID is being referred to).
I have recently found a possible bug with firmware v1.1.26 and v.1.1.31. Our team had a PID tuning that was working on firmware version v1.0.385 and library version 1.1.5-beta. When we updated the library and firmware to the latest version, our devices now does this weird jittering. We decided to start playing with the PID values and determined that the functionality of the I term has changed. It also seems like the D term isn’t doing anything. The only reason I can think of for this is we need to set the IZone, IMaxAccum, or even DFilter variables. This problem does not occur on the old firmware.
The control itself isn’t affected, however there have been some improvements fault handling and other things that improve overall operation regardless of the control interface. I recommend updating, but ultimately it is up to you.
Updated now. Filling in some additional details throughout the afternoon.
@jakebacker44 Take a look at the change log for changes related to closed-loop control and the compatibility with firmware versions and API releases. @Will_Toth may be able to chime in with additional questions.
Even with the new firmware we are still noticing two issues:
PWM control is very choppy going one direction or the other, the motor will run very intermittently. (this is using RIO or Spark Client). Does not happen over CAN
The issues we see over CAN are more of timing. We get constant 0.02 Loop overrun issues. And watchdog not fed only when we using the CAN Sparks. This is the one I care about most.
We have measured that is our RIO CPU is around 50% -60% the entire time, and CAN utilization is around 28% the entire time.
Setting the CAN motors (4 motors) takes anywhere from 5ms to 8ms each loop iteration of our 20ms loop.
We have set can timeout for each motorcontroller to 1ms, 5ms, 20ms, 100ms each with no real impact.
We have not been able to get this down to tolerable levels. For comparison PWM take 0.0001ms on average to set.
We are also seeing very long set times writing to the SparkMax via CAN. We use 7 of them, and routinely get loop overruns. I’ll try the same timing test tomorrow to confirm.
So based on everything I’ve seen and toyed around with my team today, it seems that the Spark Max API calls seem to be blocking. It would be very much appreciated to have them be asynchronous and / or cached to avoid occupying CAN bus to send the same thing or interrupting executing PID commands.
In the mean-time, I highly suggest extending and overriding the setpoint command / caching the desired setpoint locally, that way it’s not re-transmitting unless it changes. For example:
public class SnailMax extends CANSparkMax {
@override
public void setSetpoint(double setpoint) {
(...)
else {
super.setSetpoint(setpoint);
}
}
}
If we tuned a velocity PID on 1.1.26, are there conversion formulas for how to change our tuned gains after updating firmware to maintain same behavior?
Rob from 195 spent the night working on an update.
We traced the issue to the API, and he re-wrote the portions of the API that needed to be patched.
I am testing it right now, and it is way better. The heart beat takes around 0.4 - 0.8ms to execute, and executing set commands to 4 SPARK Max Motors over CAN now is on the order of 0.1ms - 0.3ms.
Will test more throughout the night, and hopefully rest of the world will see the release soon.
Beyond the point most folks are already making about the loop timing problem.
We have been testing smart motion on our elevator and no amount of clever tuning we’ve done has stopped our motors from extremely rapidly micro-ocilating when the motor reaches the setpoint in smart motion mode. I will post a video of it tomorrow. The occilatilion movement is so slight the pinion gear barely moves but the motors still make quite a bit of noise. Increasing our D value, and lowering feed forward values helps some, but the problem doesnt go away completely. We even tried setting the error threshold wider and the problem continued. Overall the movement from setpoint to setpoint is smooth, but this behavior once the motor arrives at the setpoint is very strange.
We were running firmware version 1.1.31 and API version 1.0.26, which caused our two updated motor controllers to run sporadically and continue running even when disabled and emergency stopped. Updating the API to 1.1.8 fixed it. Almost broke our elevator, please be careful.
my apologies!