ODrive and hoverboard motor based "onewheel design" ideas

[bg10389]

Hello Everyone, I am currently working on my ideas for a dual-motor, o-drive based, "onewheel" with doubled up hoverboard wheels.



I just wanted to start off stating that I have tried many things before getting to the point that I am at. I have:

1. attempted a design using a stock hoverboard motor controller (could not get balancing correct) and it sped off on it's own into a wall at top speed, and destroyed itself doing so. (a friend of mine also tried this, and his also kept going away on its own.)
2. attempted a design of hacking the firmware of a separate hoverboard controller, to fix the PID balancing issue. however, something went awry and it let the magic smoke out during testing. I would attempt another with one, however i've run out of usable hoverboards in a 30 mile radius to buy and all of mine have died or been scrapped.
3. Attempted a separate design using an arduino, two brushless controllers, an mput6050, and a custom high speed switching mosfet board. this one was close, but a friend who was better at programming than I am accidentally killed the controllers while performing a PID tuning test.
4. I also think i should mention, that I've only spent maybe 100 in total between all the attempts to make these, since i've been lucky enough to get a majority of my components from my work, friends I've made in college, or from scrapping other electronics/hoverboards.

with that being said, I have recently ordered a ODESC 3.6 from sequre, given the mid autumn festival sale going on i got it for under 80 dollars and that was a steal for me. I was thinking given how it's a smart FOC controller, that it should be able to control two different motors that have been connected together face to face. I understand I will need a CAN - based inertial measurement (gyro) input to control balance, and I understand this won't be an easy task as usual.

I have experience successfully bolting a pair of hub motors together and getting them to run together without many issues, by using a pair of 350w chinesium ebike controllers together (individually hall sensor based control) and it worked well however it was not perfect and the motors were not perfectly concentric to the wheel I mounted them to, so the frame I had built was flexing while the motor shafts slightly wobbled. While there were issues, it still performed very well and got scarily fast (probably 28+mph with an 16in wheelbarrow wheel as the tire and hub.)

So my main question is, does anyone with experience with the dual motor odrive have any suggestions, concerns, or any other comments that could help me along my way?

I currently have two ideas on how I will go about this project.
1) a more feasible approach, wherein I use two delta-modded hoverboard motors facing away from each other, with shortened shafts to more closely mount the motors with each other. This one jumps out to me since it sounds less involved to make the motor assembly function as it needs to, and how the motors will not be bogged down by each other. Think swagtron zipboard but made for adults. My frames I make are normally welded and bolted together from aluminum c channel and plate, since I worked at an aluminum extrusion manufacturer and have an abundance of aluminum scrap at my disposal from my time there.
With delta modded wheels, I believe it would get much better speed out of the hoverboard wheels due to the nearly doubled rpm under load.

2) A more involved approach, similar to the hoverboard based onewheels made online, but with different electronics. I would bolt the two hub motors face to face, add a racing gokart tire that would fit the hubs properly, and make a proper "onewheel" design for the unit. I currently own a homemade electric skateboard, made from the same delta modded hub motors, with a hall-less controller from LingYi. it works flawlessly and I believe the same idea could be applied here.

Any input would be appreciated, please keep it constructive if you want to critique me, im open to listening.

 

[amberwolf]

Do you require the motors to operate independently (like for steering) or do you want them to do exactly the same thing at the same time?

For the latter, if you can physically lock them together so their rotor/stator positions match each other exactly, then you can use a single controller to drive them both, wired in parallel. If you need hall sensors, you can use just one set of them (having the second set as a spare). As long as the controller used can handle the lower resistance and inductance and increased current, this makes them virtually one single motor and should be a lot easier to control.

 

[bg10389]

So i originally figured that if i do a locked hub motor design, than I only need to rely on me leaning to turn well given the large tire i will put on. However my plan is to try the two hubs facing away from each other. So as of this moment my plan is to have the leaning also control turning via a reduction in rpm in the motor i lean towards more.

As for the other part of your message,

For the latter, if you can physically lock them together so their rotor/stator positions match each other exactly, then you can use a single controller to drive them both, wired in parallel. If you need hall sensors, you can use just one set of them (having the second set as a spare). As long as the controller used can handle the lower resistance and inductance and increased current, this makes them virtually one single motor and should be a lot easier to control.

This is wrong from my testing. The motors cannot run off of the same controller, regardless of how you run the hall sensors. I have tried, and the only way to properly do this is if the two motors were PERFECTLY clocked together during mounting, and the rotors have to be exactly identical to eachother in their angle. If you run one hall sensor, the other one would just be blind and spin like the motor that is being actively sensed, but the issue here is that your other motor is not going to be perfectly clocked with the other one unless you machine them to be that accurate.

I have tried a few times to run them both off one controller, and it actually leads to mosfets going boom and controllers not being happy at all. The only way I can reliably do it is by running each motor individually with separate controllers. If I do the doubled up motor, it means I can't get the turning right at all with the two outward facing motors.

I did a little more research, and the swagtron zipboard has a weird function to turn. both foot panels on it are tilting, and if you tilt your feet either direction it turns on that tilt, similar to how a standard hoverboard works, i don't know if that will work for me, but i definitely like the idea of a controlled turn using either load cells or something to determine turning, or maybe it will just turn if i lean and I'm wrong. i dont know yet but maybe someone will come up with a better idea.

 

[amberwolf]

I don't have a solution for the way you'd prefer to do it, unfortunately.




FWIW, the locked-together motors has been done successfully (there are at least two threads about it somewhere around here, from years past); I guess the ones you have are just not good enough QC to be close enough in characteristics / assembly precision. (they don't have to be identical characteristics, just identical positioning of all the parts to keep timing the same) If the motors are correctly built (all the same) and you have them correctly "synced" as you mechanically lock them together, they'll work without causing problems as long as the controller can handle the halved resistance and inductance and doubled current.

The simplest way to sync them is to make sure they are positioned in parallel, axles (for hubmotors) or shafts/drive-plates (for nonhubmotors) aligned, and parallel the same phase pair on both motors, and run a small current thru that. It will self-align the rotor with that phase, and then with it aligned this way, current still flowing, perform whatever locking procedure you have planned.
For motors with unknown build-quality it's safer to open them both up first to be sure the itnernals are actually identical, and make alignment marks on the outside that show you the alignment of the insides.

 

[bg10389]

I don't have a solution for the way you'd prefer to do it, unfortunately.




FWIW, the locked-together motors has been done successfully (there are at least two threads about it somewhere around here, from years past); I guess the ones you have are just not good enough QC to be close enough in characteristics / assembly precision. (they don't have to be identical characteristics, just identical positioning of all the parts to keep timing the same) If the motors are correctly built (all the same) and you have them correctly "synced" as you mechanically lock them together, they'll work without causing problems as long as the controller can handle the halved resistance and inductance and doubled current.

The simplest way to sync them is to make sure they are positioned in parallel, axles (for hubmotors) or shafts/drive-plates (for nonhubmotors) aligned, and parallel the same phase pair on both motors, and run a small current thru that. It will self-align the rotor with that phase, and then with it aligned this way, current still flowing, perform whatever locking procedure you have planned.
For motors with unknown build-quality it's safer to open them both up first to be sure the itnernals are actually identical, and make alignment marks on the outside that show you the alignment of the insides.

I would love if i could get both motors synced properly. another thing i was going to do was just mount both stators together via a 10-12mm linear rod in the middle of both, aligning both motors up concentrically. it would make it so they do not have to be perfectly locked, and would make it easier hopefully to use the ODRIVE i have. Im gonna look at how people did it previously since i still cannot get it properly working

 

[scianiac]

While the Odrive is a great controller I do wonder if it wouldn't be easier to start with VESC as it already has packages available for making onewheel devices and some even come with IMUs built in for this exact purpose so if you had one motor you can just follow the setup and have it working without any coding (but a fair bit of tuning of course). With two motors you could use two VESCs or cheaper to just buy a dual VESC and they are already designed to communicate with CANBUS and for one to control the other. It may be possible to just set them in balance mode and synced but the dual wheel control would require custom coding and really there isn't much of a point in using the hoverboard motors if you aren't going to have them spin independently. (You could just buy one of the one wheel clone motors designed for exactly this purpose)

 

[bg10389]

While the Odrive is a great controller I do wonder if it wouldn't be easier to start with VESC as it already has packages available for making onewheel devices and some even come with IMUs built in for this exact purpose so if you had one motor you can just follow the setup and have it working without any coding (but a fair bit of tuning of course). With two motors you could use two VESCs or cheaper to just buy a dual VESC and they are already designed to communicate with CANBUS and for one to control the other. It may be possible to just set them in balance mode and synced but the dual wheel control would require custom coding and really there isn't much of a point in using the hoverboard motors if you aren't going to have them spin independently. (You could just buy one of the one wheel clone motors designed for exactly this purpose)

id love to use a vesc however i already have the odrive, and dual vescs are quite expensive. if I were to spend more money on another good controller i would just use the single vesc i own, and buy a 145 dollar hub from spintend. If i need to spend more on another controller i will just buy the motor in the future, but ive done too much work to give up working to build a hoverboard conversion to a onewheel and I gotta keep trying. My plan was to use the IMU i already have with the odrive, and to attempt a PID tuning program to get it even smoother given it works to begin with.