I’m working on a multi-modal robot (flying & wheeling) where I want to reuse the drivetrain to reduce deadweight in either mode.
I understand that ODrive is best for lower-speed and precision control, typically in robotic arms etc. This would fit the ground mode of our robot well. However, I wonder if ODrive is available to be used as the motor driver in a quad drone setup, i,e. the Air mode of our robot?
I think the maximum speed of ODrive is no doubt sufficient for this purpose, but typically hobby ESCs have simpler signal interfaces (less processing & shorter delay). So, will ODrive be “responsive” enough if I connect it to a flight controller, such as PX4, ArduPilot etc. ?
One thing to consider is that when an odrive encounters an issue it fails safe and disables the axis, this is understandable, but annoying, for a ground vehicle, for a quadcopter it could be disastrous.
How big a robot is this going to be? You have me intrigued!
ODrive will be fine for this application - and any error states can be fully avoided through proper configuration (ignoring issues such as a motor failure, encoder failure, etc). I’d recommend using the UART or CAN interface on the ODrive if possible.
Happy to provide additional guidance / recommendations if you’re able to provide some details:
Bus voltage
Motor choice
Encoder choice
Interface (PWM/UART/CAN)
ODrive S1 is available in a board mount configuration, if this is of interest to you to optimize system integration.
Drone motors don’t typically have encoders though, and though I don’t doubt that it would be possible to configure them for this usage, this is flight were talking about and I’m not sure it’s worth the risk to recommend something not tested for the purpose. What steps would you suggest to guarantee there are no errors in flight? Testing on an AGV where an axis throwing an error state is an annoyance, it happening on a drone could be catastrophic and possibly lead to injury or worse.
I can 100% understand the loyalty to ODrive, but it has to be the right tool for the job and the risks need to be laid out in order for them to be mitigated.
I will decide on those parameters soon and come back for further discussion.
I think at the higher end of RPM, the encoder may not work well. Most of hobby ESCs do not need an encoder, then I wonder if there is a ‘‘blind mode’’ on ODrive that I can switch to where I no longer use the encoder and only want simple speed control on motor like that of ann ESC?
I do plan to get an S1 dev board to play with. By ‘‘board mount’’, did you mean stacking the S1 dev board onto the main controller of mine? I’m not sure if I get the idea.
When you say reuse the drive train, are you hoping to use one controller to control both the wheels and rotors? As in, the ODrive is controlling the wheel motor, then through some kind of relay or switch, the motor controller is then connected to the rotors?
What’s your experience with other motor controllers too? It may be easier with newer models but I found it can be tricky to configure and tune for non-standard motors. I’ve a friend who has an awful lot more experience than me and he found the same too.
ODrives support sensorless operation - however, there’s definitely encoders that can handle that sort of higher RPM. What sort of RPM ranges are we talking about though?
Yes - by board mount I mean stacking. S1 was designed to be able to be integrated into a carrier board, if you look at the “daughterboard” configuration on the CAD.
Also - definitely worth being mindful of testing to make sure axis errors aren’t an issue - but I’ve seen ODrives used in production applications where they never throw an error - just takes proper configuration.
