Hi,

I make a servomotor controller called ODrive. Some people are using Duet together with ODrive via step/dir signals. However, this interface is very limiting, a lot of velocity and acceleration feed-forward information is thrown away from the motion controller.

I am very excited to see that Duet 3 will support a CAN connection for synchronized control from the master controller to slave boards. I am very interested to know what is sent over CAN?

I hope it is either some sort of Position Velocity Time (PVT) data, or some polynomial/spline primitives, and a time sync mechanism. This would make it possible to track the trajectories locally on the ODrive and hence have full access to the feed-forward terms. This would allow for very high performance and dynamic tracking accuracy.

Very excited to hear what is currently the plan for the CAN interface, and if there is any possibility to get early access.

Thanks!

Cheers,
Oskar

Great, it's actually pretty much only the movement commands that would pertain to us, since we would just be implementing an axis without much else. At least to start with.

Do you think it's best to wait for the protocol to mature a bit before we start with implementation on our side? Or do you think we can get started now?

Thanks!

Is there any documentation as to what these parameters mean? The accel, steady and decel clocks I can guess are the timing parameters of a trapezoidal profile. I take it the actual displacement target is int32_t steps;.

What are initialSpeedFraction and finalSpeedFraction?

I think we are OK to skip the delta specific stuff for now.

Great thanks for the clarification.

What would you suggest is a good next step when it comes to implementing compatability? Are there any docs or code that pertains to the other parts of the CAN configuration?

What you said about clocks vs microseconds (or maybe nanoseconds?) would be great. Please keep us (or others that may want to implement compatibility) in mind for the future too!

Thanks!

Great, it's actually pretty much only the movement commands that would pertain to us, since we would just be implementing an axis without much else. At least to start with.

Do you think it's best to wait for the protocol to mature a bit before we start with implementation on our side? Or do you think we can get started now?

Great thanks for the clarification.

What would you suggest is a good next step when it comes to implementing compatability? Are there any docs or code that pertains to the other parts of the CAN configuration?

What you said about clocks vs microseconds (or maybe nanoseconds?) would be great. Please keep us (or others that may want to implement compatibility) in mind for the future too!

Thanks!

Thanks!

Is there any documentation as to what these parameters mean? The accel, steady and decel clocks I can guess are the timing parameters of a trapezoidal profile. I take it the actual displacement target is int32_t steps;.

What are initialSpeedFraction and finalSpeedFraction?

I think we are OK to skip the delta specific stuff for now.

Hi,

I make a servomotor controller called ODrive. Some people are using Duet together with ODrive via step/dir signals. However, this interface is very limiting, a lot of velocity and acceleration feed-forward information is thrown away from the motion controller.

I am very excited to see that Duet 3 will support a CAN connection for synchronized control from the master controller to slave boards. I am very interested to know what is sent over CAN?

I hope it is either some sort of Position Velocity Time (PVT) data, or some polynomial/spline primitives, and a time sync mechanism. This would make it possible to track the trajectories locally on the ODrive and hence have full access to the feed-forward terms. This would allow for very high performance and dynamic tracking accuracy.

Very excited to hear what is currently the plan for the CAN interface, and if there is any possibility to get early access.

Thanks!

Cheers,
Oskar