Hi there!
Odrive v3.6 56V (firmware ver 0.5.3) with sensorless BLDC motor.
When entering odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL the motor starts endless spinning till I enter odrv0.axis0.requested_state = AXIS_STATE_IDLE.
What could be the reason for this?
1 Like
Yeah, this is because you’re in sensorless mode, which has a minimum speed requirement. What are you actually trying to do? What’s your desired functionality/behavior?
1 Like
I’m setting up PWM control now. My goal is to reach that when the DC is turned on, the motor doesn`t spin until I change the position of the joystick connected directly to the ODrive.
Unfortunately that isn’t possible in sensorless mode alone using PWM control. If you had a microcontroller such as an Arduino connected to the joystick and the ODrive, you could put the ODrive into idle/closed loop depending on the position of the joystick.
1 Like
Oh, I see…
Thank you for your kind help!
Is there any other way for me to make it work? I`m gonna control two same sensorless BLDC motors on my boat by RC/PWM, change revolution and direction by joystick for each thruster.
I also have a Orange Pi 5 Plus so I could use it somehow.
Orange Pi should be able to talk over UART or USB just fine 
1 Like
Which connection scheme should I use to control Odrive via Orange Pi to solve my problem? Is there any example? Its not clear for me now what function is assigned to the OPi with my motor control scheme. Am I right thinking that the joystick will be connected via GPIO to OPi, and OPi will be connected to Оdrive via usb/GPIO? Whats the difference between this type of connection and direct connection of a joystick over GPIO to the Odrive?
I will be grateful for any help you can provide!
Yep, something like that – that being said, the OPi might struggle to precisely read the PWM from the joystick – something like an Arduino would be a better solution, if that’s an option.
Either way, having something between the ODrive and the joystick allows for preprocessing of commands and data – the ODrive can only map between input PWM and a single property, however in this case you’ll need to actively set the axis state based on the joystick position. The ODrive is generally designed to function with an external motion controller, things like PWM input are more of an afterthought/holdover, so more advanced functionality isn’t supported.
Here, you’d use an Arduino or OPi or similar (may have to be an Arduino) to read the joystick PWM, then decide the correct control mode and direction, and then send that command to the ODrive over UART.
Thank you! I wouldnt like to think that such a powerful product as Odrive is not able to solve the elementary task of managing two sensorless BLDC. This is the level of a radio-controlled children's toy, because here Im not even talking about using OpenCV to recognize and bypass obstacles on its moving direction. I believed that I could simply connect a receiver with a remote control to the Odrive, as is done for an FPV or skateboard. In addition, there is an example that for some reason does not reproduce in my case. Why can he control two motors with a joystick over the radio channel, but I can’t? After all, I need the same thing. And it’s not about the presence of Hall sensors.
ODrive is very powerful, and because it’s designed for high-precision motor control, it generally expects that there’s an external motion controller giving it commands – for instance, in a CNC machine or a 3D printer you have the control board sending position commands, or in a robot you have a computer sending velocity commands. As such, we expect the ODrive to be used in a situation where you have a bidirectional digital communications protocol to communicate both motor pos/vel/torque commands and read the ODrive status. RC PWM is a unidirectional, low precision protocol, so it was never a priority to have much support for – it’s really just in there as a bonus / nice-to-have. Specifically, it’s extremely low frequency (~50Hz) and can’t be used to read the ODrive’s status or any errors, so it’s not very useful as an actual communications protocol for a precision system.
And yes – this actually is about hall sensors/encoders – or really, the sensorless mode. Sensorless control (for all ESCs) has a minimum speed requirement, and thus require an open-loop spinup (without velocity feedback). Specifically, cheap sensorless ESCs don’t actually implement any sort of velocity control or precise control methodology, and they don’t give any guarantees of functionality or operation during motor spinup. When operating in sensorless mode, the ODrive will first accelerate the motor with a configurable open-loop acceleration sequence, and then switch to sensorless mode once the motor’s at a sufficient speed for the sensorless control algorithm to work. In sensorless mode, the ODrive will begin to ramp the motor as soon as it’s put in closed-loop control, so that further velocity commands received will be immediately implemented – that way you don’t send a velocity command and then have to wait the 1-2 seconds for the motor to ramp up.
Because the sensorless control requires a minimum speed to operate, the ODrive must be put into idle and the motor stopped before it can spin back up again when switching directions.
Specifically, to start the motor in a given direction, the ODrive must be in idle, and the sensorless_ramp parameters must be changed so that vel has the desired direction (positive or negative sign). Then, once the ODrive is put into sensorless mode, it’ll spin the motor up in the direction given by vel, and then you can provide your desired velocity setpoint.
In the example you linked, the reason the ODrive can be used bidirectionally with an R/C receiver is that there’s no minimum speed limitation when using a motor with hall sensors or an encoder.
Here’s an example script and video for bidirectional sensorless control with an ODrive Pro, though the v3.6 will be quite similar: sensorless - Google Drive
It takes a bit more legwork, but it’ll result in high precision sensorless control.
1 Like
Thanks again! I owe you a lot! I tried the script- it works quite well with my board.
Based on your recommendation, I started testing motor control via Orange PI. Now I want to try a virtual joystick for controlling motors over my OPi. If you have some articles or tutorials in mind, it would help me a lot.
Glad to hear that worked! Not sure of any good methods for a virtual joystick - I’m more of a command line guy but you could probably use a GUI framework in Python or something.
1 Like
Thank you for the tip! I will definitely try this tool. 