CAN and Java

Technical CAN
1

[Cross posted to official First Forum http://forums.usfirst.org/showthread.php?p=38765]
We have spent the past couple of weeks attempting to get on-device closed-loop speed control working using Java, and can now report some success. We are using the Black Jaguar serial/CAN interface.

We initially looked at the CANJaguar project (both released and latest code) and discovered there was no Java support for the closed loop methods. Following Joe’s advice, we used the C++ implementation as a template to create equivalent methods for Java. [We are lucky to have a very competent High School Senior on our team who has both the coding ability and the time to devote to this work!]

However our Java code only partially worked. The Jaguars did not set up correctly to use closed-loop speed control, and we always received a speed of zero from the Jags. We could run closed-loop speed using BDC-Comm. If we set up the Jags with BDC-Comm, we could subsequently use closed-loop control with the Java code. But power-cycling the Jags left them back in voltage control. We concluded that the problem was our set up code.

Meanwhile there was an update to the Java code on FirstForge, so we looked at that. It was essentially the same as our attempt, and using this update we still found that both our driving code and the posted sample code failed to set up the Jags to speed mode after power cycling.

Last weekend we borrowed a CAN analyser and looked at the messages on the bus. There were a few differences between the messages sent from BDC-Comm and those from our Java code or the posted Java code. BDC-Comm used the standard “setpoint” API call while the Java code uses the trusted version, which was mostly expected.
One other significant difference was that BDC-Comm called set speed reference (LM_API_SPD_REF) during initialization, although the documentation implies this is unneccessary. When we tried explicitly setting the speed reference source to encoder in our Java code, everything worked correctly, even start-up after the Jags are power-cycled.

So, we seem to have a solution, but I can’t explain why we needed to send the extra configuation message. Any ideas?

2

I’ve seen this before. The speed reference defaults to potentiometer rather than encoder. And, you can’t get an absolute speed from a potentiometer easily. So, it really only works if there’s an encoder attached. BTW, could you share your Java code that sets up the Jag? I’ve been trying to get position mode working in C++ and having a working reference would be of great value. Some of the elements in the API are counter-intuitive to say the least.

TIA,

Mike

3

MikeE & Mike,

This is extremely useful information. We have also been trying to get Speed mode working without much success so far. (Seems like someone would have tested it before now…) We will try your suggestion this afternoon.

We would also be very interested in seeing your working code. Of particular interest is if there is any dependency on the order in which you do things, i.e. enable speed control and then set speed reference, or vice versa?

The CANJaguar code (SetPositionReference()) implies that setting a reference while in Speed mode is “Error, Invalid”. Does there exist a “real” documentation reference that gives the details of the Jaguar CAN messaging protocol? Somebody must have one…

Again - thanks for your investigations on the bleeding edge.

  • Scott
4

Right after I posted the above, I checked FirstForge, and low and behold, there was new CANJaguar code posted just this morning. Looks like Joe has been busy while we were pondering this issue, and discovered the same thing that you did. He has added a Speed Control example and modified the CANJaguar code to handle the proper settings.

Can’t wait to try it out this afternoon!

Thanks Joe!

5