Problem using encoders on Jaguar

[simpsonboy77]

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++.

[Joe Ross]

Originally Posted by simpsonboy77

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.

[simpsonboy77]

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.

[Mr-Shutter]

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...
http://www.youtube.com/watch?v=v9y6Q13V2oE
http://www.youtube.com/watch?v=RAgxE...eature=related

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

[darrellt]

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/...gbridgeplugin).
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?

[Mr-Shutter]

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.

[notmattlythgoe]

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.

[duane]

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.

[Mr-Shutter]

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 :<

[taichichuan]

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

[notmattlythgoe]

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.

[notmattlythgoe]

It would help if I attached the pic >.<

[Mr-Shutter]

Hmm, It appears that there is an Over flow on the accumulator for the PID loop
I think the Labview code encodes the Double wrong when it sends it as a u32 Int. I am going to try sending it bytes i captured from bdc-com and see what happens :3