project-sternbergia / cybergear_m5

M5 stack library for cybergear
MIT License
108 stars 10 forks source link

Mutli motor control and status reading #32

Closed titanX108 closed 2 months ago

titanX108 commented 3 months ago

I am attempting to control 6 motors and read their status. I used the cybergear_bilateral.ino for help and expanded the code for 6 motor IDs, they are simply changing velocity (not follow).

My issue is a set number of motors always return null values, when I check their ID its reads 0x28 (not what I assigned). The motors which behave like this are predictable in a order; when controlling 6 motors, the 3rd, 4th, 5th return null, when controlling 5 motors, the 3rd, 4th return null, when controlling 4 motors, the 3rd, return null, in order of IDs in the vector. Its never the first few or the last.

Can this be a issue with the library? Have you ever tested with more than 2 motors?

chikuta commented 3 months ago

@titanX108

Thank you for sharing the information and analyzing the isssue. I recognize this issue. Since Cybergear uses CAN bus communication, it is likely that packet collisions are occurring due to the continuous data transmission. Although it is not mentioned in the datasheet, Cybergear seems to send a response packet within 250 microseconds after receiving a packet.

Therefore, instead of transmitting data continuously, it is necessary to transmit data at certain intervals. The CybergerController class has the following arguments available, so please try using them.

The API is described here.

https://github.com/project-sternbergia/cybergear_m5/blob/26c91f98165e353e24772d1d4c5e29997e16e9c6/src/cybergear_controller.hh#L129-L142

I show you some sample.

Before

  controller.init(motor_ids, MODE_POSITION, &interface);

After

  // wait 250usec after sending packet
  controller.init(motor_ids, MODE_POSITION, &interface, 250);
titanX108 commented 2 months ago

Thanks for the suggestion. I tried the wait response time delay for 250 and many other values, but the issue is prevailing. Now however the number of null responding motors have reduced to 1. I will update If I find a permeant solution. Please post some ideas how to get around this issue if you have any others.

chikuta commented 2 months ago

Thank you for trying it out. In my environment, I have confirmed up to 6 motors like this post. https://x.com/chikuta/status/1790401397412028464

By the way, which board are you using? Could it be a board that uses the MCP2515?

chikuta commented 2 months ago

It has been almost a month since your last reply, so you may have already resolved the issue. However, as we are currently unable to use HW interrupts for the MCP2515, depending on the processing method, it might only be possible to control 2-3 Cybergear devices. How would it work if we send the data one by one and call the process_packet function each time?

chikuta commented 2 months ago

As there has been no response, I will go ahead and close this issue.