Quote:
Originally Posted by Bryscus
That's interesting that you experienced latency problems last year. We were using 6 Jaguars at one point and we did not experience any noticeable latency (any more than PWM connections anyway). Another help this year could also be the synchronous command - even though if it's truly a latency problem, you'll still experience a delay; all motors could be delayed the same amount however.
There was ONE minor (major at the time) issue we had that most teams should not run into. Last year SPAM used a swerve/crab drive train that used one position motor (to rotate all four wheel modules) and four wheel motors. We used off the shelf modules but we didn't get the ones that continually rotate. Instead, the modules would turn only so far and then spin 180 degrees and reverse the wheel direction. Every now and then when this happened the robot would stop moving for a second or two and then start again, but the position motor would no longer work. If we power cycled the robot it worked again.
Needless to say, it was VERRRRRYYYY frustrating that this was happening. What I finally determined was that when this reversal condition was happening a huge current spike would drop the voltage input to the Jags and reset them (especially when the battery was low). The position motor Jag was set up for position PID control using an encoder. Well, when the Jags reset they go back to open-loop voltage control - hence the reason it would no longer work. The Jag was receiving position commands and just ignoring them because it was in voltage mode! We found that we could even re-initalize a Jag and make it work without power cycling!
When we finally (correctly) diagnosed the problem, we limited the ramp up time of all the motors and corrected the issue. However, this has left a sore taste in our mouths. We will use CAN again this year, but be sure to limit current spikes because Jags CAN be reset when the input voltage dips.
- Bryce
|
You may be interested to know that, with the new Jaguar firmware, the Jaguars send an enumeration message when they start up.
This means you can have a CAN Receive waiting for an enumeration message, and reconfiguring when it does so.
In fact, in LabVIEW I have code that does just that. The latest version can be found in the "Reconfiguration" directory here:
https://github.com/kamocat/CAN
The version attached is the latest as-of-posting. I recommend placing it in your user.lib so it's easily accessible. Unfortunately, there's no context help documentation yet. Please let me know if you find any bugs, or have questions about how to use it.
EDIT:
For a C++ version, you want to talk to RadicalPi. His version may still need updating from the preseason release.