nothing happen with motors while sending command for control drives

[dvogureckiy99]

I sending manually massages to the motor via CAN (according to the CAN Communication Protocol) with raspberry pi 4 B. I sent different commands and I expecting that motors will hold position and follow to reference, but nothing happen https://drive.google.com/file/d/1LtS5n0lSDeGayjM9ZJD-b_18vWQHuJuq/view?usp=sharing.
For example I send

cansend can0 000#0000000000000004
cansend can0 000#0000000000000005

And motors don't hold their reference positions:

cansend can0 008#FBF3A591FA98DE4B

When I am getting motor velocities via CAN, there are sharp changes in speed with not the slightest fluctuation of the joint and sometimes the speed is equal to the maximum with a complete lack of movement:
https://drive.google.com/file/d/19Be1c6AE1e3po4SyYLn3NkL7sYe2rJzr/view?usp=sharing

https://drive.google.com/file/d/1dengz049L4UW2oc1zU-DXJd5IyM3HucQ/view?usp=sharing

On some udriver I have got encoder error. What does it mean?

[luator]

I am sorry for the confusion. The CAN firmware actually does not implement a PD controller, you can only send torque commands.
There was some internal work on implementing this some time ago and by accident the corresponding CAN messages were added to the public documentation. I updated the documentation to remove the messages that are not supported.

I'll have a look into the status of the PD controller implementation when I find some time. Maybe it can be finalised and released. However, at this point I don't want to promise anything.

Regarding velocity: What you see is not the maximum velocity but a very small negative value. The velocity is a signed value. FF FF FF EC (from your screenshot) is the byte representation of -20 (assuming two's complement). As values are provided in Q24 format, it needs to be divided by 2^24 to get the actual decimal value. In this case -20/2^24 = -1.2e-6. So what you observe is just a bit of noise around zero.
You can verify this by manually moving it first in one, then in the other direction. When changing the direction it should switch between values starting with zeros and values starting with F's.

Regarding the encoder error: In addition to the normal ticks, the encoder has an "index tick" which appears only once per revolution. Whenever this index tick is observed, the firmware checks if it is at the expected position (e.g. a full revolution after it was seen the last time). If the difference between the observed and the expected position is too large, the error is triggered.
If this happens, it means there is either a problem with the encoder (maybe a dirty, damaged or misplaced encoder disc, resulting in some ticks to be missed) or with one of the cables connecting the encoder with the board (e.g. a broken cable).

[dvogureckiy99]

Thank you very much for the answer, did I understand you correctly that by torque commands you mean sending IqRef for motors?

If I implement PID controller for more accuracy in CAN implementation myself, you publicate it in this repository?

there is a link to draw.io diagram of dual_motor_torque_ctrl.c file and a pdf.