Just write zeros to them.
I 2nd eMTea’s request.
It would be fantastic to be able to enable/disable an option to enter “streaming mode” where the Odrive streams “Encoder Pos & Current”
How would such a ‘streaming mode’ be configured?
Perhaps we could have a few ‘streaming data slots’ that are configured a bit like the analog/PWM inputs - they could have an ‘endpoint’ parameter (which is a pointer to any variable in the ODrive system) and some config options for frequency, priority / message ID modifier etc.
However, I think the limitations of ‘CANsimple’ would soon be apparent, because CANsimple does not make use of CAN’s message priority system at all. Since the node ID occupies the most significant message ID bits, a lower ID node will always take priority over a high ID node, and the same node can’t send messages at different priority levels.
At the other extreme, someone could implement CANopen and we could set up process variables remotely- but only with a proper CANopen controller…
2 Likes
I actually started on this a bit ago but quickly ran into ODrive side implementation details with the ST controller and tx message queuing. I had to work on other things first but fixing it is the next thing on my list 
Endpoints would be cool but I think for now it’ll be just position & velocity streaming, which should cover 99% of the use cases
1 Like
I guess it would be helpful to specify my need for such a function as I think it may be different to eMTea.
eMTea lacks the ability to write a RTR bit (at least my understanding, correct me if I’m wrong) so is looking for a workaround to get the pos data.
I’m looking to get position data from multiple motors and by sending a single “start streaming pos” command I can minimise the amount of traffic/requests.
However I think we are both after similar functionality.
PS big shoutout to wetmelon and towen for getting me on my CAN feet!
Perhaps we could have a few ‘streaming data slots’ that are configured a bit like the analog/PWM inputs - they could have an ‘endpoint’ parameter (which is a pointer to any variable in the ODrive system) and some config options for frequency, priority / message ID modifier etc.
Yea, this sounds like a good idea. Not sure if this is appropriate, but you could edit the heartbeat message by changing what other Odrive variables are included in it (and edit the heartbeat interval as needed).
@PaulM @towen I just pushed an update to the can_improvements branch. It now lets you configure a cyclic encoder message. I tested it, and it’s sending data consistently now, but I don’t actually have a motor set up at the moment to test that the data is right. Please test it!
1 Like
Awesome, good stuff Wetmelon! Looking forward to testing it 
Hey Wetmelon,
Great work and it works like a treat!
I had a chance to test the new updates on a couple of Odrives running motors & connected to the same CAN bus. Worked ‘right out of the box’.
For those interested, under the CAN settings you can change the update frequency for both motors. Default I believe is 10ms which sends pos updates.
The update is helpful to reduce the volume of messages as we don’t need to send a position requests each update.
Sounds perfect!
Is there a hex file ready for me to load to my odrive?
I’m not at home with my odrive/maxxecu for another week, but looking forward to test!
1 Like
Wetmelon/All: Not sure if this is a challenge on the receiver side or the Odrive side but when I set the encoder rate to be the same I would loose one of the packets. (eg; if both were set to 10ms, one would get lost). Quick workaround is just to offset them (eg; 10ms & 11ms).
eMTea: I’m not sure if there is a HEX included. If you PM your email I can send you the HEX with the RTR modifications I mentioned.
Hmm. That should be fixed, as of 9/22. It re-tries if all the mailboxes are full now (it used to just drop the packet)
1 Like
I’m stuck at the Set Input Pos.
canMsg1.can_id = 0x6c;
canMsg1.can_dlc = 8;
canMsg1.data[0] = 0x0A;
canMsg1.data[1] = 0x00;
canMsg1.data[2] = 0x00;
canMsg1.data[3] = 0x00;
canMsg1.data[4] = 0x00;
canMsg1.data[5] = 0x00;
canMsg1.data[6] = 0x00;
canMsg1.data[7] = 0x00;
mcp2515.sendMessage(&canMsg1);
It only move a little bit. Then I changed byte from 0 to another, and it just stop moving. I’m new at this, kindly give advice
The input pos command is a floating point value, not an integer. Try this:
float desired_pos = 10.0f
memset(canMsg1.data, 0, sizeof(float)); // Clear the float space
memcpy(canMsg1.data, &desired_pos, sizeof(float)); // Copy the position into the data
@Wetmelon I did follow your instruction, but it still don’t move.
I also try this:
float set_point = 50.25;
tx_message.can_id = 0x6c;
tx_message.can_dlc = 8;
tx_message.data[0] = (uint32_t)set_point;
tx_message.data[1] = (uint32_t)set_point >> 8;
tx_message.data[2] = (uint32_t)set_point >> 16;
tx_message.data[3] = (uint32_t)set_point >> 24;
Turns out it only move a little bit again.
Please suggest
That’s not how floating point works… Your options are to use the memcpy, or do cast, or use a union (I recommend the memcpy)
float set_point = 50.25;
uint32_t* set_point_int = (uint32_t*)(&set_point);
tx_message.can_id = 0x6c;
tx_message.can_dlc = 8;
tx_message.data[0] = set_point_int;
tx_message.data[1] = set_point_int >> 8;
tx_message.data[2] = set_point_int >> 16;
tx_message.data[3] = set_point_int >> 24;
Also, I assume you are able to move the motor using odrivetool and USB, correct?
float desired_pos = 10.0f
memset(canMsg1.data, 0, sizeof(float)); // Clear the float space
memcpy(canMsg1.data, &desired_pos, sizeof(float)); // Copy the position into the data
Thank you very much for your suggestion, I just got it done.
But still stuck on the ‘Set Input Vel’, please kindly give advise on this task.
Oh, I suspect you need to put it in velocity control mode first.
Hi Wetmelon,
I do have the same problem as Cooper, could you able to help me with that?. i have odrive 3.6-56V version and ODrive control utility v0.5.4. i could not able to make it move, axis_id = 63 and i am sending the message as “cansend can0 7ec#08”. Does not make it move. And sometime a small jerk in the begining and then nothing happens.
TiA
Dp
7e is correct for axis ID 63, and 0xC is correct for the command ID. The 0x08 in the data field is wrong. The first 4 bytes need to be the hex representation of a floating point value, in little-endian byte order. You also need to transmit all 8 bytes, even if they’re 0’s.
1 Like
my bad i missed that, cool, I got it working now. Thank you.