Source Code Flow

#1

Greetings ODrive’rs and happy new year!
Is there documentation that shows the architecture and flow of the source code (something like this http://smoothieware.org/howitworks), I’m trying to understand how modules work together and get registered with RTOS events, what are the key functions in the code

I’m trying to program some macros on top of the existing functionality
example : set torque to 0.5, then change to 0.2 when encoder reaches positions X, then stop at position Y

I’ve been thinking about using the CAN bus for something like this, but I will have to continuously poll the encoder position and I don’t know what the performance impact will be

any discussions or opinions are welcome

thanks!

#2

Hi sherif, @Samuel is the right guy to answer the first part of your question.

Yeah, this kind of stuff is best done off-board by the motion controller.

The devel branch can now return encoder position and velocity as a cyclic message on CAN with a specified cycle time, so the overhead is reduced vs polling.

#3

There is currently no high level documentation of the firmware architecture, it’s also still in heavy flux.

The function that is probably of central interest is ODrive::control_loop_cb. It is called at 8kHz from board.cpp in an interrupt context at a fairly high priority (higher than communication interrupts except SPI encoder interrupts). This function calls the update() functions on all components that need it.
The components have InputPort<T> and OutputPort<T> members. When you enter a specific state, the input and output ports are connected in a way that makes sense based on the configuration and state. This setup happens on the axis threads in axis.cpp.
Many data paths are still hard coded though, i.e. they bypass the input/output port design and directly access variables from another part of the system.

Regarding your use case: In case you want to avoid additional hardware you could make a new axis state in which you constantly poll the variables that you’re interested in and set the setpoints accordingly. You can look at AXIS_STATE_CLOSED_LOOP_CONTROL to get started.

#4

thanks a lot @Samuel, I will look into it, so far I’m successful using a Teensyduino 4 to control odrive, which comes in very useful if I want to control more than 2 motors. The interesting part would be how to sync operations over CAN bus, which I think is doable
if we can load the operation (such as move to position or something), then create a separate command to run, that way we can sync across multiple motors, can be be used for a gcode controller

#5

@Wetmelon any documentation on how to specify the update cycle time in the devel branch?

#6

You mean the motor control update time or the CAN cycle time?

#7

yes, update rate for encoder position data over CAN, I’m assuming it will be related to heartbeat? 0x001 command ID

#8

In devel, position and velocity data is returned via the get_encoder_data command ID cyclically. You can pick the rate.