Custom CAN-bus controlled robot goes randomly to STATE_AUTO_READY for no reason

support
1

Hello,

For a project with a customer, we acquired a FarmNG Amiga and we need to control it from an existing industrial PC running Linux via the CAN bus.

I found my way to control the robot by sending RPDO1 and reading TPDO1 frames from a pytohn script, and it runs smoothly most of the time.

However, the dashboard sometimes switches from STATE_AUTO_ACTIVE to STATE_AUTO_READY for no apparent reason, which can be very annoying in practice since the robot will stop in the middle of its task for a few seconds. The problem is that I am not sure what the dashboard exactly expects and what can cause this transition. Does anyone has some idea on the reasons that can trigger this specific state switch on the dashboard side?

Among others, some element of my configuration that I thought could play a role on the dashboard side:

  • Physical CAN line: my computer is directly plugged to the dashboard CAN connector with a 1m cable, no resistance added. I did not connect the ground of the CAN bus since the ground is already connected to the power supply cable (and I suspected this could cause a ground loop on the computer but maybe I am wrong)
  • Linux CAN interface: atm, I use a restart period of 100ms, a buffer size of 30 frames, and a bit rate of 250.000
  • CAN frames frequency: RPDO1 sending frequency is currently 20Hz in my software (I tested changing this but without success). I send the heartbeat signal at 2Hz.
  • Speed command values: I don’t smoothen the speed and acceleration of my command so it can be that one CAN frame request a velocity of 0m/s and the very next one requests 1m/s with no transition.

Thank you very much for the help!
Gabriel

2

Hey Gabriel,

thank you for your question… impressive work there!

So, when we see this in the past, most of the time the problem was on the frequency of the RPDO1 frames received by the dash. Did you debug that?

3

Hi @MScatolin ,

Thank you for the quick reply and the encouragements. I did not evaluate it thoroughly but at first I was sending it way too fast for the bus (100 Hz) and I decreased it to 20 Hz. I did not try much further.

Do you have a ballpark estimation of the expected frequency on the dashboard side?

4

If you are higher than 5Hz you should be good. I think a good test would be checking if your script is indeed delivering frames at 20Hz. Maybe some resource constraints are reducing the real frequency to something lower than 5Hz sometimes?

5

Hi,

@MScatolin, the problem was indeed there! :open_mouth: Due to the use of async, publishing my messages was delayed randomly from time to time… I fixed it!

Thank you for your help!

6

Wonderful! Thanks for letting us know!