Linking this here for visibility
Our website backend won’t allow this at the moment. I’ll post back in the other thread when we have a solution.
Don’t forget when my teams buy parts; 686 Bovine Intervention & 4638 Jagbots. I want the. Fred & Robin discount. Maryland discount. The crabcake discount and now the Mike discount. Get the picture. Thank you vary much.
Will do. Thanks for your help.
We tested with the arbitrary feed forward and confirmed it’s working as intended now.
Is there any roadmap to support any post loop voltage compensation?
Also the Get() routine - does that return the duty cycle after all closed loop calculations? Including arbitrary feed forward?
Additionally, the SetReference command’s arbitrary feed forward component is the only real mention of ‘output voltage’ is this genuinely a scale of duty cycle from -32 to 32?
As another question - is there any guidance on how to use cascading control loops? The API documentation hints that you can configure an inner and outer loop but it’s not clear to me how that would work, if you use gain sets 2 and 3 do they automatically cascade to the inner loop? How would you specify the inner loop gain set?
My team decided to do a little testing with our Neo and SparkMAX. I believe we got all the software setup properly and everything is wired correctly. We used the “Basic” configuration editor to set the CAN ID, but changed no other values. Using the “run” tab in the REV client app, we couldn’t get the motor to spin. After a few minutes, we realized that firmware v0.0.0 is likely a problem, so we updated the firmware and tried again, no dice. Realized the LED blink pattern likely means something (Orange/Magenta blinking). Per this page, that blink code indicates a “Brushless Encoder Error”. We double-checked all the connections, and everything seemed good, but still no luck.
Now, here’s the kicker. We decided to try using the mode button, and noticed the LED pattern changed. On a hunch, we decided to try the “Run” tab functionality again, and it worked flawlessly. Deploy the configuration from the “Basic” (or Advanced) tab again and the encoder error status returns.
I can’t tell if I’m missing a step somewhere, or if there’s a problem with the motor or controller, or the app has issues. I haven’t tried deploying robot code and controlling via CAN, since this was just a simple benchtop test. Any help or insight would be greatly appreciated though!
Yes we plan to support a voltage output mode for the closed loop controllers. Right now our public roadmap includes features we plan on working on in the near term as well as progress and any issues found. If you have a trello account you can comment/vote on cards as well.
The Get() only returns the result of Set() for the frc::SpeedController interface. To get the actual duty cycle value set to the motors use GetAppliedOutput()
The value is an actual voltage not a duty cycle. We will improve the description on this to make it clear.
Unfortunately this feature is not available at this time. We will update the docs to reflect this as well.
Thanks for the detailed description, we’re tracking this here.
How are you controlling this voltage that’s applied to the output as part of the arbitrary feed forward? Are you attempting to emulate that voltage by converting it to duty cycle based on a nominal voltage? If so, what calculation are you using? Otherwise, how does it work?
Also, I would like to see the Trello roadmap board. Is there a link I need to access it or is it public?
So minor question / request, the CANEncoder object in the Java (and C++) API has no reset function. Is it possible to add one in like WPILib and the NavX have for their sensors? Thanks.
The SPARK MAX measures the supply voltage directly. So both the voltage output mode, and the arbitrary feed forward uses that value to convert to a duty cycle. The value for arbitrary feed-forward is actually passed as a fixed point number, which is where the value ‘32’ comes from.
The trello board is public here: https://trello.com/b/DOsaf6hW/spark-max-software
This is a planned near term feature, you can track the status of this card on our trello https://trello.com/c/ZhflQBbH/11-add-ability-to-set-the-stored-sensor-position
Oops, missed that card. Thank you Will!
Could you in theory use the arbitrary feedforward with zeroed gains as a hacky way to do voltage compensation in open-loop?
Yes that would work. For open loop voltage control you can also use voltage control mode directly by calling SetReference() with ControlType::kVoltage (since it is open loop the gains do not have an effect here). You will notice the same results between using that control mode and the arbitrary feed forward.
Oh, I thought that feature wasn’t implemented yet (hence the trello item for it). That would make more sense!
Edit: I am dumb, implemented for open loop, not for closed loop. Gotcha.
Is there anywhere we can put in feature requests? There are a few things missing/that I would like to see different in the API that aren’t already on the trello
Having an issue with a new Spark Max out of the box that is giving a blink code that doesn’t appear to be on the blink code list. It’s blinking a slow purple and amber. It also is showing multiple different firmware versions at different times when it connects. And then sometimes it just blinks purple (for brushless motor). Here is a picture of the client showing different firmware versions after two consecutive connects to the same Spark Max
Is this device broken?
I have no answer for the firmware versions, but your “purple and amber” is actually “orange and magenta”, and is listed 2nd from the bottom as an error code indicating “brushless encoder error”. It’s the same as I reported above. Solid(or flashing) magenta is brushless mode(flashing is brake or coast), and I’m guessing it happens after pressing the “mode” pinhole button on the top of the sparkmax