I am looking for a controller able to drive hoverboard style motor-in-wheel. Similar are also used for unicycles and/or e-bikes. For an example of such a motor see https://github.com/EGG-electric-unicycle/documentation/wiki/Motor. The motors are usually LRK outrunners with hall feedback sensors. I don’t see a way to add encoder. Smooth ride with high torque in low speeds would be needed.
Your being a little ambiguous, but I’m assuming you mean the encoder implementation.
My answer may or may not be what you were looking for, but there is two ways (I see) to do this:
One way to do this is to make the entire wheel the encoder. I am guessing you want a quadrature output (as that’s what the ODrive uses), so placing two reflective sensors offset from each other and painting alternating white and black sections axially on the wheel would work.
Another less obvious solution (one that is a bit fiddly in nature) is to use an optical flow sensor to measure rotation. This might sound complex, but optical flow sensors are easy to find - an old webcam plus a source or a optical mouse could work really well. Downside is that you would need some way for it to talk to the ODrive.
Yes, I meant the encoder implementation. Can I use the hall sensors built into the motor instead of optical encoders for low speed operation? The high speed operation would be covered by the sensorless mode. I am specifically trying to find out if this can be realized without modifying the motor.
I don’t mind doing the work. Right now I am trying to find out if I am going to hit any road blocks on the way.
I see in the odrive hw spec that it is for 24V. However all hoverboards I could find (including the one I have) have 36V battery pack. How hard is the 24V limit? Any chance to raising it to 36V?
We would like to create a simple reference robotic platform using the hoverboard wheels and battery packs and I am really excited about the possibility of using and supporting an open source motor controller! The platform should be able to work in http://robotour.cz/ settings - that is a competition that we are organizing for the past 11 years.
The on-board MOSFETS (ON Semiconductor NTMFS4935NT1G) have a Vds of 30 volts, so they’d be toast.
Your application reminds me of the 2005 DARPA Grand Challenge. A couple of vehicles were taken by the Smithsonian (I remember going to DC approximately a decade ago and finding an entire exhibit for it. Don’t remember much, I’m a junior in high school.) My favorite vehicle was Ghostrider, the only motorcycle of the bunch. Sadly it never qualified, but there are some low quality videos of it working really well.
A while ago, a friend of mine implemented hall sensor feedback. He used it to replace the driver on his off-the-shelf electric skateboard, which had hall effect sensors:
I won’t bother to find his code though, since I think it was a fairly unmaintainable bodge. But he did do it in one weekend, just to give you a sense of the work effort involved. He didn’t do sensorless though, just straight hall -> rotor angle.
Here is how I would do it:
You can repurpose the encoder pins to be hall effect inputs. You can set up the pins to be interrupt-in pins, and do the hall effect state to rotor angle decoding in software. [EDIT]: GPIO in, and just sample in the control loop, is probably fine.
Make a PLL (similar to the encoder or sensorless PLLs) to track the rotor velocity
Use the hall PLL’s velocity, and with some hysteresis, do switching between using the hall rotor angle and the sensorless rotor angle for control.
It may be a little messy to get all the units to line up, but it should work in principle. My suggestion is to convert the hall state to electrical radians, and do everything in those units.
The voltage is indeed pretty hard-limited at 24V. The first thing you hit is the capacitor ratings at 25V. I don’t think they blow up at higher voltages, but they degrade very quickly. Once you hit the breakdown voltage of the MOSFETS at 30V, they will just conduct the battery voltage straight to ground and let the smoke out.
That competition looks super cool! Reminds me of the Sparkfun autonomous vehicles competition ;D
This is pretty related to work I’m doing. One of my goals is a self-driving bicycle too (some old info https://wiki.base48.cz/Velobot, soon it will get complete firmware revamp and a switch from RPi to STM32).
For sensing wheel position I’m probably going to use either DIY optical encoder along the wheel or flow sensor as suggested by Eric.
We would also like to build some “normal” e-bikes, but that needs a bit higher voltage as discussed.
Are you planning a ROS integration for you robotics platform? Can you stop by in Brno at https://base48.cz hackerspace for a longer robotics discussion?
@madcowswe Thanks for the hints! I am right now working with 36V battery pack so I am keeping the original controller and simulating inputs from the hoverboards IMUs (like on Open Chair). If I move to a smaller battery pack I will revisit odrive again. I have also notified my colleagues - odrive can be very useful for smaller robots. If I don’t move to a smaller battery pack I will either keep the original controller or use some VESC variant.
@srk I’ve sent you a PM regarding the meeting in Brno
There has been lots of people who have asked for higher voltages. So just to check what the distribution is, I’ve created this poll. Maybe we can do a higher voltage version for ODrive v3.4 if there is enough demand.