We have a quadrature encoder wired to the encoder inputs on the Jaguar, yet niether the TI utility, bdc-comm nor labview can use the jaguars in speed mode. In the bdc-comm utility, the option to use encoders is grayed out (see picture attached). Controling the jaguar and motor via Voltage mode works perfectly, but controling it via speed or position mode does not. does anyone have any ideas on how to fix this problem?
pic.bmp (89.8 KB)
pic.bmp (89.8 KB)
I couldn’t see in your picture, but I assume you switched over to speed mode.
What this sounds like to me, if everything is hooked up correctly, is that you did not set your P, I, and D constants. With them at the default 0, your motor won’t turn no matter what speed you tell it to go.
Start by setting a P value of a few hundred (P is the proportion correction to the error between the desired speed and actual speed) and see if that gets your motor spinning. Be careful, while tuning your PID constants the motor can sometimes move erratically. Leave I and D at zero for now.
Make sure you set the number of encoder lines (ticks per revolution) in the configuration tab.
The encoder/potentiometer radio buttons are grayed out in speed mode because speed mode only supports encoders at this time.
Whether this works or not, also be sure you’re running the latest firmware on the Jaguars and the latest BDC-COMM (all version 87). They can be found here: www.luminarymicro.com/jaguar
If you are still having trouble, post some more info about your setup, and a full screen shot of the BDC-COMM screen.
-David
Thanks for the tip. We updated the Jaguar, and it now works.
There are still a few problems, though.
The motor jerks on-off at low speed (50 rpm or so and lower), and runs at much higher than the target speed in reverse. We set P=100, I=0, D=0, and set the encoder to 360 segments, as that’s how many it has and it is on the output shaft of the KOP transmission.
Now that you’ve got it spinning, it is just a matter of tuning your constants.
I saw the same behavior when I was playing with a kit encoder, CIM, and a toughbox on our robot. I found that a much lower P with a little bit of I seemed to work well. I was using P = 0.3 and I = 0.001. It just takes time to find the perfect values for your system.
Good luck with tuning!
-David
Thanks for the tip. We updated the Jaguar, and it now works.
Is this running on the cRio, or through BDC-COMM?
If it is on the cRIO, then which language are you using C++, Java, or Labview?
The reason that I am asking is because, in a few days, I will be wiring up the robot.
On the 1 jag that I used with the potentiometer, the position couldn’t be read by the jag, but the position set-point could be sent.
If the encoder can be read in by the cRIO,
then I will use the speed control of the jaguar,
otherwise I will wire the encoders to the digital sidecar as I need them for autonomous.
So far we are running the Jag only through BDC-COMM, but today we will try it on the cRio and see if we can read the encoder. If not, we may wire the encoder both to the Jag and the cRio, as we also will need it for autonomous.
We’ll update our progress on this forum.
e tweaked the PID values and it now works perfectly.
Here’s a screenshot of what we used on the Toughbox:
http://chantillyrobotics.org/temp/important_values.png
We tried getting it to work on the cRio, and made some progress, but aren’t there yet.
More tomorrow.
Has there been any more progress made?
Luckily for me, I haven’t fully wired the robot yet, so I still have time to wire it to the cRio if needed.
Which programming language are you using?
Has anyone gotten the speed control to work without using the BDC utility, or Labview? I tried writing my own speed driver, but it doesn’t work at all. I cannot use the utility because we don’t have a black jaguar (yet, just ordered it).
If you have gotten the speed control, could you kindly post the code, or point me in the direction of a repository? The first forge hasn’t been updated in a while, and only works for percent voltage. We are using C++.
Have you looked at the subversion repository on FIRST Forge? It looks to me like it’s been updated in the last 2 weeks and does have speed control.
I was looking at ‘File releases’.
I setup an account (wow I hate those password restrictions) and I downloaded the current versions. I’m shocked at how close my code was to this. It gives me the (false) impression that I know what im doing haha.
Can’t wait to test this tomorrow, (well technically today :0)
Thanks Joe.
Ok, So we have it working with BDC-Com perfectly. Sadly with the Crio it does not.
We set every thing up the same as we do on BDC-COM then confirm that by getting the values back from the jaguar.
This leads me to believe there is a problem with the labview library.
In fact we had it working one time, I have a video of it.
On BDC-COM it ALWAYS works.
I have been trying to compare the serial output from BDC-com and the Crio.
I have even looked at the source code of the Jaguar, which does not seem to match the protocol BDC is sending, this is very frustrating.
Any ideas?
Here is it working on labview properly, some how…
And then it stopped working properly, now the speed is way to fast. And it takes a long time to reverse direction, I will post a video soon
Have you made any progress on this?
We succeeded last night in getting something sort-of working with a slightly modified version of the C++ CANJaguarPositionControlExample from FirstForge (you have to sign in and download from the FirstForge SVN server to get it).
We modified the code to select the encoder, instead of the potentiometer, as the position sensor. We also changed the CAN channel to match one of the Jaguars on our robot. We were able to make the motor move, but we have not successfully adjusted the PID constants to stabilize the position control.
We are using a Black Jaguar with the serial port from the cRIO. We are using standard CIM motors and the AndyMark gearbox with the standard encoders installed (we had to modify/shave the standard mounting plastic hardware to fit around the motor – if you force it, the encoder will bind and you won’t get any signals from the encoder).
A few things that we learned:
- it is essential to update the Jaguars to the latest version of the firmware (we are using version 87) from the www.Luminarymicro.com/jaguar site. This allowed us to use the BDC-COMM application to control the CAN network of Jaguars directly (we are using a http://www.iogear.com/product/GUC232A/ USB --> Serial port device to bridge between our laptop USB port and the serial port into the Black Jaguar).
- The 3 PID constants all default to 0.0 – nothing will happen with these at 0.0.
- The cRIO has to have it’s firmware updated and configured to include the black Jaguar code. Get the code here: (http://firstforge.wpi.edu/sf/frs/do/listReleases/projects.canjaguar/frs.blackjagbridgeplugin).
The update/config instructions are here: http://firstforge.wpi.edu/sf/projects/canjaguar - To effectively run this example, also run the “Position Control Tuning Dashboard” project from the “CANJaguar Dashboards” folder from the FirstForge SVN server. This allows you to modify the PID contstants & visualize the results. You have to configure this dashboard as your robot control station dashboard, either by installing it on the drive station or setting it up as a “Remote Dashboard” from the Driver Station Setup tab.
We would very much like to get this working with LabVIEW, but as yet we keep getting -52007 errors when we try to use the equivalent LabVIEW version of the position control example (again from FirstForge).
Anyone succeeding with LabVIEW?
I just deleted the can receive from the code…It is not needed.
What I am looking at doing is re-writing the library. Tough it seems to have everything it needs.
I been looking at what BDC-COM sends the jaguars.
I am filtering for packets with Additional data
When I click on speed mode in BDC-COM:
BYTES: 0xff06020205c018db
Packet Size: 6 MSG: 0x020205c0 DevID: 2 Data: 0x18 0xdb
BYTES: 0xff050202058000
Packet Size: 5 MSG: 0x02020580 DevID: 2 Data: 0x00
When I click on Voltage
BYTES: 0xff0602020100f34f
Packet Size: 6 MSG: 0x02020100 DevID: 2 Data: 0xf3 0x4f
When I click current:
BYTES: 0xff0602021180de91
Packet Size: 6 MSG: 02021180 DevID: 2 Data: 0xde 0x91
When I click Position
BYTES: 0xff0a02020ac0894f00000000
Packet Size: 10 MSG: 02020ac0 DevID: 2 Data: 0x89 0x4f 0x00 0x00 0x00 0x00
MESSAGE ID
HEX DEC
EN_SPEED 0x020205c0 33686976 <two bytes non consitant data>
0x02020580 33686912 0x00
EN_VOLTAGE
0x02020100 33685760 <two bytes non consitant data>
EN_CURRENT
0x02021180 33689984 <two bytes non consitant data>
EN_POS
0x02020ac0 33688256 <two bytes non consitant data> 0x00 0x00 0x00 0x00
SET_SPEED 0x02020600 33687040 <two bytes non consitant data> (UINT32 RPM)
SET_VOLTAGE 0x02020140 33685824 <two bytes non consitant data> (two bytes voltage data format==???)
The Most significant byte has flags about the manufacturer 0x02 = Luminary Micro
the second MS Byte is the Can Bus type, 0x02 means motor
the next 6 bits are the actual message ID, the last 6 bits hold the device id
device id is a number from 0(broadcast) to 63, you OR it with the message ID
The packets are as fallows
a header consists of two bytes
First byte = 0xff
Second is message size
msgSize = size of msgID (always 4 bytes) + number of data bytes
< HEADER > | <MSG ID> | <data> |
byte 1 | byte 2| byte 3 - 6 | bytes7-n
0xFF 0xXX 0x0202XXXX
0xFF is escaped by 0xFE for the data
0xFE is escaped by 0xFD for the data
THere is no end of packet, end of packet is determined by second byte in the header (size of packet);
If the amount of data read in is not the same as the data declared in the header the packet, it is thrown out.
After a few hours of slamming our faces into the keyboard with these same problems we finally figured them out. If you are having a long delay when switching from forward to reverse that means that your I value is too high in your PID. Lower this value and you should see some improvement.
BTW we are using the FirstForge code for Labview so if you have any questions feel free to ask. We have successfully gotten the speed control to work.
We also fixed our -52007 error, but for the life of me I cannot remember what we did. Do all of your Jaguars have unique ID’s? Is your console out on or off? Try switching it and see if that works.
In speed control you will be sending a value of rps to the jaguar instead of the rpm’s that the BD-COMM application looks like it sends. Our PID numbers are P = 10, I = 0.002, and D = 0.
Sure would be nice to know how you got rid of the -52007 errors. I believe that error is causing the robot to trip the watchdog.
We aren’t doing anything with PID at this point. Just using the simple drive system. We can see the Jaguars responding, but they periodically flash off when the watchdog is hit.
Glad you got things working.
Our PID values we are using are the same we are using on BDC-COM,
It is highlighted in the image we posted earlier.
We do a get on our PID values from the device to check that it is the same, and it is… It is very frustrating :<
Hi Guys,
Could you post your code to set up the jags to run in speed mode? Are you using a shaft encoder? If so, could you also post the set up sequence you’re using to set and read the encoder position? I’d like to add it to my Jaguar how-to document.
TIA,
Mike
Here is a pic of our 4 motor drive setup. What we did was modify the FirstForge 4 motor setup vi to set it up for speed control instead. To do this we had to set the encoder rate, set the pid values, and enable it to allow the jaguars to have control. Then all we did was calculate the direction and magnitude and used the holonomic vi FirstForge provided. W actually never read the encoder rates while they are running and never set encoders up to use, the jaguars do all of this for us. What we did realize is that once you put the jaguars in speed mode you now send the jaguars the rate you want the motors spinning in rotations per second, unlike what the bd-comm application does.
