Provided that nothing changes in the rulings about the use of CAN for the robots between now and kickoff. How many teams are going to be using CAN this year on there robots?
I’m trying to decide if we should look at investing in a set of the new jaguars for this year(1 on the robot for the CRIO to CAN bridge, and one spare) providing that we don’t get one in the KoP.
Being a network/phone technician I already have all the tools/cable that we will need for making the CAN cables. One thing that I really like about them over the PWM is the connector. Seems like it will stay in place much easier and should be easier to crimp. then PWM cables.
Another thing is the possibility of hanging the encoders off them. Seems like if your Jags are located near the motor/encoders then you won’t have the 4 conductor wire for the encoder and the 3 conductor wire for the PWM needing to run back to digital sidecar.
We used CAN last year and had good success with it, so most likely we will be continuing with it this year with some of the more advanced features. The electronics people were also happy with the reduced number of wires
I plan on using the CAN bus this year for several reasons:
It simplifies wiring. I like the idea of one cable going from the cRIO to the motor controller as opposed to 3 or more cables leading from the DigitalSideCar to motor controllers. Our coach and pit crew leader like the “click” that comes with plugging it in. This ensures that it is locked in place.
Enhanced feedback from motors. I would like to utilize the current sensing capabilities of the Jaguars without wiring a separate sensor. To tie in with the above point, I can now route the encoder wire to the motor controller, as opposed to cutting, extending, and crimping the wire to the digital sidecar. I have also read that the jaguar can handle the PID loops, leaving the cRIO to do more important things, like image processing.
Success with using this system last year. Depsite minor problems, The three programmers on the team enjoyed using it. Use of this system led to the acquisition of the Rockwell Collins Innovation in Control Award @ Arizona
In the past, we used the current sensing capabilities to sense a ball in our pinch roller, and during testing to determine that we were pulling 60+ amps while climbing the bump.
Despite the little problems, I definitely recommend that your team uses the CAN bus
We’re planning to use CAN this year as well. All of the pluses for control and reporting that were mentioned earlier come to mind. We also had good luck with the CAN controls as long as you make sure the termination is working correctly.
I added a fair amount of code to the CAN library last season and most of my additions should show up in the WPILib version of the CAN code this year. Some really cool features like group commanding so you can issue commands to all of the Jags to prep and then a single group sync command will activate all of the Jags at once.
I’m also interested in using a TouCAN Ethernet to CAN bridge this year. That should address some of the latency issues of the serial interface flavor that we encountered last season.
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.
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:
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.
Thanks for the reply. I rigged it to do something similar last year, but the issue is with encoders. If the Jag dies it forgets its last position. This requires re-initialization with the motor in the correct orientation.
One method to fix the initialization issue would be to use pots for feedback instead of encoders. OR we could continuously read the current position and use that for initializing the position upon instantiation (it defaults to 0).
A quick note about that:
There’s currently a bug with the Jaguar firmware. The first time the “position enable” is called after the Jaguar powers up, it sets the position to 0, regardless of what you wire in.
So, if you’re doing this, make sure to call “enable” twice, and just wire the value to the second one.
If you’re using Black Jaguars, they will function down to 5.5v, but they need 7v to start up. The Tan Jaguars can function as low as 6v.
For your uses, however, it does sound like a potentiometer would work best.
