Our team has been using Victors for a number of years. We finally want to embrace Jaguar and try CAN bus for this year. We’ve got 4 Black Jaguars and a 2CAN (not V2 though). I quickly written some simple code to test the Jaguars but it doesn’t work. There must be some sample code written somewhere for CANJaguar on 2CAN. Would somebody point me to it? To summarize what my simple code does:
I printed the joystick values to dsLCD and I got reasonable values when reading the sticks. So it means the m_jagXXXX.Set() is not doing anything. All the jags are assigned correct IDs (2 and 3) and have firmware version 92 on them. The 2CAN has a green light and I can access its web page in my browser on http://10.4.92.10. I even plugged in the serial cable directly to one of the jags and ran bdc-comm-92.exe tool. The tool enumerated saw the jag ID 2 and 3 and I was able to set some values on each of the jags and made them turn. That means the CAN bus is wired properly and the 2CAN interface with the CAN bus successfully (through the web interface). The only thing I am unsure is if the cRIO can communicate with the 2CAN. I assume the cRIO knows how to communicate with the 2CAN since I have imaged the cRIO with “2CAN” selected, so the 2CAN driver should be running. And I am also assuming the cRIO will communicate with the 2CAN using 10.xx.xx.10 as its IP address. What else did I miss?
What version image are you running on the cRIO? I don’t think the cRIO will talk to Jags with out the latest FRC image for safety reasons. I would check this link. On the side it has BDC-COMM v100, as well as FRC firmware v100. Try flashing that firmware and see if your results change.
Thanks for the info. I have flashed all the Jags with firmware version 100 but it is still not working. The NetConsole has a lot of messages about timing out waiting for the Jag.
<Code>-44087 ERROR: status = -44087 (0xFFFF53C9) sendMessage …in setTransaction() in C:/WindRiver/workspace/WPILib/CANJaguar.cpp at line 406 FRC: JaguarCANDriver timed out waiting to receive a response from a Jaguar.
<Code>-44087 ERROR: status = -44087 (0xFFFF53C9) sendMessage …in setTransaction() in C:/WindRiver/workspace/WPILib/
The 2CAN acts as a gateway to CAN the cRIO simply passes the CAN frame over UDP, the 2CAN has no other interaction with the CRIO.
What you see in the web dash is the result of interactions between the 2CAN and the JAG’s over CAN, this and the green led on the 2CAN means you are successfully communicating with the jaguars over CAN and you are successfully communication with the 2CAN plugin on the cRIO. Your problem is most likely in your code.
I noticed that you are calling the closed loop functions. If you are trying to just control the Jag in voltage control mode you do not need to to do this. Also I do not see where you init the Jaguars.
The functions used in CAN are the same regardless of the gateway used (serial or 2CAN). The only difference is the plugin. Make sure you have the most recent plugin and 2CAN firmware (version 2.18).
A couple questions:
What is the state of the Jaguar LED? blinking orange or solid orange.
What version of 2CAN firmware and plugin are you running?
What do you mean? The loop is reading the joystick values and programming the Jaguar in speed mode accordingly. If that’s not the proper way to program the Jaguar, please show me the proper way.
How do you initialize the Jags? Wouldn’t the CANJaguar constructor initialize it for me? I looked at the source code for the CANJaguar module and it calls the InitCANJaguar method. In the InitCANJaguar method, it checks the firmware version to make sure it’s between 92 and 3329. Then it send a transaction to the Jag to enable the specified operating mode. That should be enough to initialize the Jags, right?
When I imaged the cRIO, I selected 2CAN. According to documentation, this will automatically add the 2CAN driver to the cRIO plug-in list.
The Jaguar LEDs are blinking either Yellow or Green depending on which angle you are looking at them. According to the Diagnostic page of the 2CAN web dash:
Version: 2.5
Build Date: Mar 13 2011 04:56:34
Is it the latest? If not, please point me to the latest firmware. It’s not easy to determine which version I should download. According to the web site:
I took a risk and tried flashing the latest date firmware which is v2.18 (12/21/2011). It looks like the old 2CAN can take this firmware as well. After the firmware update, I can still access the 2CAN dashboard and can see the jags and their data. But unfortunately, the cRIO is still timing out waiting for the Jags to respond. I must be missing something simple.
I have attached the whole code since it is highly likely I missed something in the code.
As long as you are getting a timeout from a send message call, there is something wrong with either your wiring or your configuration. Once you get past that, then you’ll need to make sure you are calling all the right methods to enable the closed-loop control. Your first code snippet was much closer than this most recent post.
Calls like this are needed:
speedJag.SetSpeedReference(CANJaguar::kSpeedRef_QuadEncoder);
speedJag.ConfigEncoderCodesPerRev(360);
speedJag.SetPID(P, I, D);
speedJag.EnableControl();
speedJag.Set(stick.GetAxis(axis) * 150.0);
Try using the jag in speed mode outside of RobotDrive first.
Wiring should be fine. I have tested it with the bdc-comm-100.exe tool and was able to see and run all motors. So it means the CAN bus is good. I am also able to see the 2CAN and all the Jags on the network (i.e. can access the 2CAN dashboard on 10.4.92.10 and see the status of all the jags). So it means the ethernet connection to the 2CAN is good. What other wiring could be wrong?
Yeah, I decided to redo the program with standard template and thinking I don’t care about the encoders yet so I skipped the encoder related initialization. So you are saying they are still required?
Probably nothing. Are you checking for errors or messages on the console being printed by the 2CAN plugin? Have you tried a BlackJag bridge?
They are required for closed loop mode… without some process variable, the controller does nothing. You may want to try simple PercentVbus mode first. Start simple and all. Verify you can talk to the Jags at all. Make sure your device numbers in the constructors match what you configured.
I changed the program as you suggested (new code attached). Notice that I added the jag.Set(30.0) in there outside of the loop. When running it, I heard the motor noise like it had moved but then stopped. When I looked, nothing happened. Then I noticed my voltage is getting low and the Jags are no longer powered. I think my battery is now exhausted. Unfortunately, the mechanical mentor has the charger. So I guess I am done for tonight. But I am excited, it may mean the motor really moved but then the battery died because of the current drawn. If that’s the case, it means the jag.Set() outside of the loop worked. If so, the next step is to find out why the ArcadeDrive inside the loop did not work. Since you suggested “speedJag.Set(stick.GetAxis(axis) * 150.0);”, does it mean the full range of the Jag is -150.0 to 150.0? How about the ArcadeDrive call? Would the RobotDrive object do the scaling to 150, or do I need to call SetMaxOutput myself? I can’t find anywhere in CANJaguar that it scales the outputValue. If that’s the case, that explains why the motors didn’t move because the outputValue will be below or equal to 1.0 in a full scale of 150.0. I thought everything in WPILib scaled to 1.0. Why is it that we need to multiply 150.0 in jagSpeed.Set()? If the speed mode is really in the range of -150.0 to 150.0, is there documentation somewhere telling me what range is the motor in which mode?
Wait, I found the scaling code in CANJaguar. It is in packFXP16_16. It means the full range is actually +/- 65536. So like I suspected, the outputValues in jag.Set() should always be in the range of +/- 1.0 and the CANJaguar module will scale it to +/- 65536 and send it to the jags. Then why do we need to multiply 150.0? I am confused.
The latest version is back wards compatible with version 1 2CAN hardware. The only difference between 2.5 and 2.18 is 2.18 supports the device id for a different version of Ethernet silicon inside the 2CAN. All new versions of 2CAN firmware will support both devices.
One thing to note if the 2CAN has a Green LED your problem is not on the CAN side(wiring, termination) the LED can only be green when at least one Jaguar is present on the BUS and responding to enumeration requests from the 2CAN and the the plugin has successfully loaded. If you had bad termination or faulty wiring you would see a red strobing LED and the Jags would not appear in the web dash. Since you are able to see all of your jags in the web dash and the 2CAN LED is green your problem is not in the CAN wiring or termination. This is a very useful tool that can be used to provide quick diagnostics when setting your robot up on the field. Green is good red is dead.
Follow Joe’s advice regarding your code as it seems you already have.
It appears that at this point all you want to do is control your Jags using voltage control mode, this is the mode that provides the same functionality as pwm and is the default mode in the CANJaguar constructor.
You pass in a throttle value between -1 and 1 into Set(). To simplify things I would remove all but one Jaguar from the CAN bus. Make sure you are only calling Set() for the Jag that is on the CAN bus as this will also cause the
-44087 error to appear. Open the web dash to verify the Jag ID. Using only one JAG eliminates the possibility of having more than one jag on the BUS with the same ID, this will also cause the -44087 error as well.
Make sure the 2CAN LED is green if it is RED power cycle the Jag and the LED should turn Green. (FYI if you remove the CAN cable from the JAG the 2CAN led should turn red, removing the Ethernet cable should cause the LED to turn orange, removing both will cause a red LED.)
If the LED is green and you have the correct ID’s and you are not sending requests to any other JAG’s that are not on the BUS your code should work.
Thanks for the info. I will try that tonight. One question though, if I run the Jags in Voltage mode (kPercentVbus), it means it doesn’t need encoder (as versus Speed mode or Position mode). Can I skip the encoder related initializations just to make it even simpler? For example, SetSpeedReference, SetPositionReference, SetPID and ConfigEncoderCodesPerRev?
The actual range depends on the mode. Look at the documentation for CANJaguar::Set.
/**
* Set the output set-point value.
*
* The scale and the units depend on the mode the Jaguar is in.
* In PercentVbus Mode, the outputValue is from -1.0 to 1.0 (same as PWM Jaguar).
* In Voltage Mode, the outputValue is in Volts.
* In Current Mode, the outputValue is in Amps.
* In Speed Mode, the outputValue is in Rotations/Minute.
* In Position Mode, the outputValue is in Rotations.
*
* @param outputValue The set-point to sent to the motor controller.
* @param syncGroup The update group to add this Set() to, pending UpdateSyncGroup(). If 0, update immediately.
*/
Everything you see inside the CANJaguar class is to convert from the WPILib API formats (such as -1.0 to 1.0) into the binary format to send to the Jag. Since in speed mode, the units are RPM, I don’t want to control my motor +/- 1 RPM… that’s too slow. I set the RPM range in my example to +/- 150 RPM cause it made sense for the mechanism I was sensing with that encoder.
In the case of RobotDrive, it computes a motor output +/- 1.0 based on joystick inputs. If you are not using motors in Percent Vbus mode, then that’s probably not a good range. The RobotDrive class allows you to specify a scale value by calling SetMaxOutput(); with a floating point number to multiply by the +/-1.0 values that it computes before they are passed into the Set(); call on each motor.
Actually, few more questions: is the kPercentVbus mode essentially kVoltage but just scale to the range of -1.0 and 1.0? Only kSpeed and kPosition modes use encoder/potentiometer? Are kVoltage and kCurrent modes also considered close-loop modes? To me, close-loop means feedback. Monitoring output voltage and current so it can maintain constant values seem close-loop to me too even though it is not using any “external sensors” such as encoder and potentiometer.
If your battery voltage is 12V and you specify 0.5 in PercentVbus mode, you get 6V and if you specify 6V in Voltage mode, you get 6V.
If your battery voltage is 9V and you specify 0.5 in PercentVbus mode, you get 4.5V and if you specify 6V in Voltage mode, you get 6V.
Position, Speed, and Current (the sensor is inside the Jag, but external to the controller) are closed loop modes that use a PID algorithm with feedback. The Voltage mode is not closed loop because the setting is simply scaled based on the bus voltage, not corrected based on the resulting output. This is because unlike the other modes, the voltage can be controlled directly.
My encoders are not working, it could be the cable. We will figure that out later.
Apparently, if I do kSpeed mode, the motors jerk back and forth violently. Sort of vibrating loudly. That gave me the hint that the encoders are not working. I added a call to GetPosition and saw only zeros.
So I changed the code to use kVoltage mode and scale the joystick values by multiplying with 12.0. This doesn’t work either.
Then I thought since the encoders are not working, I would disable all the encoder related initialization. To my surprise, that works. I would have thought the encoder is ignored when doing kVoltage mode, but apparently not.
With the encoder initialization disabled, I changed the code to use kPercentVbus mode and removed the 12.0 multiplier. That also worked.
So the robot is totally tele-operating. Next step is to figure out what’s wrong with the encoders.
