Announcement

Collapse
No announcement yet.

CAN and Java

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • CAN and Java

    [Cross posted to Chief Delphi]
    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
    Re: CAN and Java

    Originally posted by MikeE View Post
    [Cross posted to Chief Delphi]
    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?
    I was surprised by this as well, but after speaking with TI, they said that is expected... the default position reference and speed reference is nothing. That means that even though there is only one possible reference, you still need to set it.

    -Joe

    Comment

    Working...
    X