odriverobotics.com support

[wernerdaehn]

Status update: I can read and control the odrive's velocity mode now. Similar to the VESC. Need some more testing but then I can release the new build.

[Willyfan]

I must rebuild a cablecam in order to test this solution. I seen that the odrive controller is available now (but only in USA and not in europe for now), so I will order one of this at begin of next year. As I have many AS 5047 encoder with a custom designed board, I will try with this encoder instad the amt 102. I hope that this is ok. When you are ready, I want ask you what do you think about position encoder, If we need our encoder or the motor encoder is good.

[wernerdaehn]

I don't know the effects of slippage. And I expect it to be dependent on many external factors. A heavy rig on a steep hill and aggressive driving and running for a long time will have pronounced slippage. For sure. The opposite of above extreme situation might be okay.

But frankly, it does not matter for the Controller. We have two position value sources, motor controller (VESC or oDrive) or running wheel. You can switch to either one. It does matter for you of course because you need to decide if the hardware needs that or not.

The perfect solution would be to have both and the running wheel has an encoder as well. I am just struggling to find a mounting solution that is easy enough for the majority of the people.

[Willyfan]

If you remember, some times ago I request for a "goto" feautures. You suggest to use the odriverobotics controller because it have this features but I guess that it work only with the encoder on the motor. We can use both as you suggest but maybe need to be inplemented in the controller in this case.

[Willyfan]

Hi Werner, it's many time that I dont see you in this page... I have only a little question: some message above, you speak about use VESC (or oDrive) as position sources. It's possible now or maybe we need to write some code for it?

[wernerdaehn]

There are three things to consider.

1. Do we send position commands to the ESC (or thrust or speed)?
2. Where do we get the actual position from?
3. What if it should hold the current position?

The problem is, all of these three questions are in flux. It depends on the current capabilities of the ESC.

Ideally, we would sent the ESC constantly the desired position and the ESC drives towards that or holds the position. The actual current position comes from an encoder on one of the other wheels as the driven wheel has slippage. Hence it would be good if the ESC has that encoder connected and when sending the desired position, it is based on this encoder's position. Third, the motor encoder should be a relative type, meaning it reports the angle. The position encoder should be a hardware absolute encoder ideally.

For the VESC I have no hope any of this will get implemented. For the ODrive they were moving slowly into that direction but I did not check the state for a long time.

Hence this code should be considered as work in progress.

[Willyfan]

I must review the actual status of the firmware. I'm using a cablecam that is well working with VESC. I'll like to try oDrive but for a lot of reason (Covid and working problem) I cannot try until now. My question is because my cablecam lost the end point - or, better, the endpoint is moving and after some trip of the camera, they are moved some metres. I agree that is better have position sensor on orther wheels. As you know, oDrive is working well actually? I can start from this point... Now I will read all docs here (and comments) in order to understand the project status. Thank you for your answer, very happy to hear from you!

[Willyfan]

Dear Werner, I not found instruction about oDrive connection. It is connected just like vesc? How configure firmware for using oDrive?

[wernerdaehn]

Best starting point is the source code for now. https://github.com/wernerdaehn/CC3D-CableCam-Controller/blob/master/src/odrive.c

Yes, it is connected just like the VESC via UART.