Speed direction in CAN?

[MikeE]

When using quadrature encoders directly connected to the Jaguars, we noticed that the speed returned over CAN is always positive, whichever direction the wheel rotates. We see this both via our Java code and using the BDC-COMM utility.

This causes difficulty running closed loop since the signs of the PID values would depend on the wheel direction, and I'd rather not change PID values on the fly to avoid possible instability.

The most likely explanation is that we made a wiring error and are only getting a single A or B channel from all of our wheel encoders - I won't be able to check until tomorrow - but I'd like to confirm that the Jaguar firmware is working correctly.

So has anyone successfully seen a negative speed returned over CAN from a Jaguar?

[dyanoshak]

Originally Posted by MikeE

When using quadrature encoders directly connected to the Jaguars, we noticed that the speed returned over CAN is always positive, whichever direction the wheel rotates. We see this both via our Java code and using the BDC-COMM utility.

This causes difficulty running closed loop since the signs of the PID values would depend on the wheel direction, and I'd rather not change PID values on the fly to avoid possible instability.

The most likely explanation is that we made a wiring error and are only getting a single A or B channel from all of our wheel encoders - I won't be able to check until tomorrow - but I'd like to confirm that the Jaguar firmware is working correctly.

So has anyone successfully seen a negative speed returned over CAN from a Jaguar?

Currently you cannot get direction from the returned speed data. You can, however, configure your Jaguar to use the encoder for position measurement and monitor the position when running in speed control mode. You can determine the direction of rotation by whether or not the position is incrementing or decrementing.

In BDC-COMM you would go momentarily into position mode and click the encoder radio button. Then you would go back into speed mode and run it as normal. You should now see the position value updating.

In Labview/Java/C++ you don't have to ever leave speed mode, you will just configure the position measurement off of the encoder.

*Once you set your PID values for, lets say, forward rotation, they will act the same in reverse rotation. This is because of how speed control is implemented in the Jaguar.

The current implementation of speed control prevents cases where the output of the PID function differs in direction from the desired speed. Say your robot was driving down a steep hill. The PID is trying to maintain a certain speed, but gravity is causing the robot to accelerate. There might be a point where the output of the PID function tells your motors to start driving in reverse, aka bad for the drivetrain. Setting the output to zero and braking, for example, would be the better option. So, the speed control firmware sets output to zero whenever this "opposite sign" situation occurs.

Hope this helps,
David

Edit: *My above explanation holds true only if you're using the Jaguar in speed control mode. It looks like you are doing your own control loop, so you have two options: hope that the motor is turning the same direction you're telling it to, or get actual direction from monitoring the position.

[MikeE]

David,

Thanks for the excellent explanation. I hadn't thought through the case of an external force changing the drive direction. It's great to learn something about the implementation subtleties.

We are using the Jaguar in speed control mode (i.e. PID on the device) rather than running our own control loop, so we'll log delta position as well and rerun our tests.

[Happily we did verify correct encoder operation.]

Thanks again.

[taichichuan]

Greetings!

Could either of you guys post the C++ or Java set up commands you used for you jaguar? I understand setting the thing up in speed mode (are all of the jags in speed mode or just the one with the shaft encoder?), but the initialization sequence for setting the shaft encoder and the periodic reading portion of your code would be peachy to see. Also, from what I can see in testing, the value of the position goes from 0 to 65535 as I'm going backwards if I simply print the value as a float having unpacked it. Is this what I'm supposed to see? Or, should I hack the top 2 bytes off and cast it as a singed integer to show negative position?

TIA,

Mike

[MikeE]

Originally Posted by taichichuan

Greetings!

Could either of you guys post the C++ or Java set up commands you used for you jaguar? I understand setting the thing up in speed mode (are all of the jags in speed mode or just the one with the shaft encoder?), but the initialization sequence for setting the shaft encoder and the periodic reading portion of your code would be peachy to see. Also, from what I can see in testing, the value of the position goes from 0 to 65535 as I'm going backwards if I simply print the value as a float having unpacked it. Is this what I'm supposed to see? Or, should I hack the top 2 bytes off and cast it as a singed integer to show negative position?

TIA,

Mike

Mike,

We wrote our own Java code based on the C++ code which is posted at FirstForge, and while we were debugging our code an update to the Java code was also posted there. My suggestion would be to get a FirstForge account and check out the posted code.

Position is returned in 16.16 fixed point representation, i.e. take the 4 byte value and divide by 2^16. This is in full rotations, assuming that the "encoder line count" parameter was set up correctly. It should count correctly in both positive and negative direction when using a quadrature encoder.

Mike.

[taichichuan]

Hi Mike,

OK, so just so I'm clear here. The Encoder Line count isn't the number of lines from the encoder, but rather the number of pulses per revolution? And, that would mean that the number of Potentiometer turns would be 1 if we're using an encoder? You don't happen to know the units of the voltage ramp setting do you? Volts/revolution? Volts/Second? Volts/light year? I really wish the API guide was a bit more, er, fleshed out.

TIA,

Mike