The MCP2515 to MCP2515 communication was working fine at 16MHz, it was just the MCP2515 to odrive that only works at 8MHz.
That’s because both of your raspberry Pi modules were wrong in the same way.
I can check the frequency of the CAN on ODrive but I’m pretty sure it’s right.
Hi!
If can-bus is used to continusly send position of motor, would you prefer to use “pos setpoint” or “move to position”? Why choose one over the other?
1 Like
“Move to position” uses Trajectory control and “pos setpoint” does not.
Currently, sending continuously with “pos setpoint” or “move to position" is updating way too slow to be useful, no matter what baud rate it’s set at. I hope this gets fixed soon.
Would trajectory be preferred?
Sorry, what do you mean fixed? Is there a problem you’re experiencing?
When I continuously send different set points to the Odrive without using the CAN bus it works perfectly and it changes positions smoothly. As soon as I tried to do the something using the CAN bus the motor will stutter. I think the update rate is too slow when using the CAN bus for some reason. Using a baud rate of 100000 should definitely be fast enough so something else must be causing it to not run very smoothly.
1 Like
Hmmm… something to check I suppose. At 1mbps you can send a single command message at just under 8kHz, which should be plenty fast enough.
Make sure you’re not streaming “move_to_pos” commands though, those are slow because it has to compute a new trajectory every time.
Hi peeps!
Could someone help me get started with my setup?
For a start, I only want to send “pos setpoint” (0x00C) of axis 1. hopefully at 50hz, i think that would be plenty.
I want to do it from my MaxxECU Race (standalone Engine Control Unit), the value I want to send comes from a “User Table 1” and I can scale the numbers as I like, but the Odrive must be able to move from 0 - 10000 encoder pos.
(Velocity FF 3000 / Current FF 10A)
Please look at ECU setup screen, what to put in the boxes? 
I don’t understand how the Node ID and Command ID comes into play.
In the future, I’d also like to poll motor current and encoder pos in “realtime” for logging purposes, but for now, if you could help me send that one command, maybe I will understand more, and handle things myself 
Ah, good example problem.
Command ID: 0x00C
Axis 1 ID: 0x001
CAN Msg ID: 0x001 << 5 | 0x00C = 0x02C
So, to set up your ECU:
Message Settings
| Field | Value |
|---|---|
| Enable | Enable |
| CAN Bus | CAN 1 |
| CAN Msg ID Type | Standard (aka 11-bit, or CAN 2.0A) |
| CAN Msg ID | 0x02C |
| Message Rate | 50Hz |
| Endian | Little endian (aka INTEL) |
Data Value 1
| Field | Value |
|---|---|
| Type | Signed 32 bit |
| Variable | ??? |
| Offset | 0 |
| Multiplier | 1 |
| Divisor | 1 |
Data Value 2
| Field | Value |
|---|---|
| Type | S16 |
| Value | Fixed at 0 or variable according to trajectory |
| Offset | 0 |
| Multiplier | 10 |
| Divisor | 1 |
Data Value 3
| Field | Value |
|---|---|
| Type | S16 |
| Value | Fixed at 0 or variable according to trajectory |
| Offset | 0 |
| Multiplier | 100 |
| Divisor | 1 |
Ahh thanks, perfect, it makes more sense now!
So 0x02C is simply a result of a calculation? Ok!
But I don’t understand how they add together, could you elaborate that a bit more?
You have to know the symbols, I guess. Go to http://calc.50x.eu/ and type in 0x2C into the “Hex” field. You’ll see what I mean about the “upper 6 bits” and the “lower 5 bits”.
CMD ID is 0x0C and the axis ID is 0x01. But you have to shift the axis ID to the left by 5 bits (0x01 << 5), which becomes 0x20. Then you bitwise or that (or just add, in this case) to 0x0C, which results in 0x2C.
Thank you! makes more sense now
But your branch link is dead? 404 on github 
Thank you
Waiting for my ECU now, to start some testing.
As some already know, this will control the 4wd system in my project car.
“The Bastard Fiesta” on facebook if anyone’s interrested.
When sending to odrive 0x014, what id should I listen to, to recieve the message on my reciever?
The same ID, but without the RTR bit set.
To request, you need to set the RTR bit.
1 Like
This has been incredibly helpful in understanding how CAN works with Odrive.
I’ve followed everything but I get lost when trying to send the message.
In Towens post he sends a CAN frame as follows:
"pi@rpi:~ $ cansend can0 7f7#R"
Is anyone able to expand on this section here? Is can0 a variable that you have set or is it a function of the software library?
I think I am getting lost as I don’t know what the entire message is. Is it just the “7f7” or is there also frame/header data?
Thanks in advance :D!!
I am using the cansend utility under Linux. I have a Raspberry Pi with a CAN interface.
You need to follow the installation instructions for the PiCAN Hat (edit /boot/config.txt) to enable it
Then sudo apt install can-utils to install the cansend program.
can0 is just Linux’s name for the network interface, a bit like COM1 in DOS/Windows.
7F7 is the message-ID. Look up how CAN packets are structured.
Of course, 7F7 is hexadecimal. In binary it is 11111110111.
If you need a quick way to convert binary/hex, see the end of my post.
The first few bits of the packet are a (functionally unique) message ID (i.e. anything with the same ID should mean/do the same thing, but more importantly always be sent from the same node. So if you have more than one node that can send a type of packet, you should encode some sort of address within the bits of the message ID - but that is left to the application)
The rest of the packet is an optional data payload up to 8 bytes long. The length/format/meaning of the data packet can vary according to the message ID, but that is up to the user or developer of the high-level protocol over CAN. (in this case, ODrive’s CANsimple spec)
The #R is just a notation of the cansend utility to set the RTR bit (a special bit in the frame which indicates that this is a request for a remote host to send some data)
If RTR is set, then we don’t include a data payload. (because we are asking for one back)
Instead of #R we can put a data frame.
e.g. cansend 7f7#00000000 to send 4 bytes of zeros as a payload
Once you understand it, you’ll realise that CAN is an incredibly simple, reliable, yet powerful and flexible communications protocol for control (which is what it is designed for).
For a bit more detail, see: https://www.ti.com/lit/an/sloa101b/sloa101b.pdf
BIN/HEX: For anyone on Linux / Raspberry Pi, I find the interactive Ruby shell useful for this. sudo apt install ruby then run irb
irb> 0x7F7.to_s(2)
=> "11111110111"
irb> 0b11111110111.to_s(16)
=> "7f7"
1 Like