As a robotics hobbyist, I've found that it's hard finding information beyond surface level without moving into a formal education forum. These types of deep dives help bridge the knowledge gap that would take years to overcome. Thank you Austin!
Nice work. I decided against direct drive for my project. Once you gear down the different max RPMs of the different motors the torque values become a lot more competitive. Gearing down also helps with the encoder resolution. And Cycloid drives tend to be fairly low backlash. A 10-to-1 gear reduction gave me more torque than a hoverboard motor while also having a higher RPM on the limb for less weight.
I am beginning a project; RC Lawnmower, boring and begginnerish, i know, but it's my first project... I have the motors from a 'broken' hoverboard, and want to get drivers for them. I recently looked up ODrive and it looks like all their controllers are sold out . . . there are some on Amazon but, I admittedly do not know much, and cannot afford to make a bunch of mistakes to 'figure it out.' Thank you for sharing your experiences, like this. Your information about the hall resolution was especially helpful as i had no idea exactly how that worked, or how accurate or fine the feedback was. seems to be only good for speed, or maybe to prevent cogging at low RPMs or 'skipping' ...
Hey man, I just found your channel and I absolutely love how well you've educated your viewers in this video while staying interesting! You are cool bro.
This is a very well made video. Very informative. Hoping to see more :) And It's sad that RUclips algo does not help to promote more quality videos like these
YES! Time to go to ebay and buy up hover boards listed as "for parts or not working". I might get some nice usable lithium cells and motor drivers then too
Look I'm not a pro, and I don't really know what I'm talking about. I'm just thinking you need the torque and holding power that is only going to come from a reduction drive... this, also effectively gives you more precision over the movement: dividing one "state" of the sensor by the ratio of your reduction. Industrial robots use toothed belt systems because they have incredible holding power and minimal backlash when properly tension-ed. They also contort those belts in some amazing ways to squeeze everything into a small package. I think they usually run a 10:1 reduction of the pulley.
You can replace the binary hall sensor encoders in the blds motors with analog one and you will be able to read the magnetic field strength. That will give you higher resolution. One more thing to consider is that driving the motors is done with strong magnetic field that will also be picked up by any magnetic based encoder near by. You will likely have hard time dealing with thus interference. You will not get high resolution from magnetic encoder and drive the motor at the same time. You should consider using either optical or resistive encoders.
@@forbiddenera i have a hoverboard but can't find the custom firmware for it. The ones on internet use a single control board. Mine has 2 boards which act as master slave, i found one such firmware but though similar, it is a different board. could you help me out in finding the firmware for my board?
@@yashvardhanagarwal2740 I don't have one of those but I do remember seeing a firmware for that type when I was researching. There is a hoverboard hacking telegram channel, find that and they can help direct you
Great video. +1 sub. I'm using hoverboard motors but with a dual vesc board (custom firmware using simplefoc). Keep up the great work! I'll be interested to see how you mount the as5048 as there is no obvious place to mount (no static external stator and no exposed spindle)
Great video - would the ODrive S1 controller, with the on-board encoder, also work in this case? What might be the pros and cons of one vs the other? Thanks!
What's the maximum torque and weight of a hoverboard motor? For quadrupedal robot jumping, we can achieve around 40 cm jump height for a 9 kg robot assuming 18 Nm torque on some of the 12 quasi-direct drive actuators. My thinking is if hoverboard motors are so cheap and have such high output, and are backdrivable due to no gearing, then it would be great for legged robots.
Can you make a robotic arm for quadriplegics.. my left arm / hand is c4 damaged with contracture .. my right is c5 damaged . No splints could ever be used . Not a amputee, have the limb in the way
You mentioned that you want to use external power instead of the battery while testing. While this sounds like a good idea you will have hard time getting power source that can supply the current needed to drive the motors. My guess if you will need something im the neighbourhood of 100A to prevent brow outs. Also another issue is that the bldc motors will feed back current to the system sometimes and unless you have some way to clamp the power voltage it will lift it and you might end up damaging the electronics. You should consider keeping the battery in the system while testing and making something that will charge the battery while in use from external source. It will solve the issues with external power source.
How is the torque to weight ratio though? Cycloidal drove gearboxes have high efficiency and low backlash. I think that's what Agility Robotics uses in their digit robot. I wish their was some commercially available low cost options that were suitable for robotics. Hoverboard motors plus a cycloidal gearbox could produce some monstrous torques.
Good question on the torque to weight ratio so I looked into it and put a table below for the motors I talked about in the video: Hoverboard motor: 12.92 Nm @ 2177 g ODrive Robotics D5065 - 270kv: 1.99 Nm @ 420 g ODrive Robotics D6374 - 150kv: 3.86 Nm @ 890 g Tarot 4008 330kv: 0.63 Nm @ 80 g Turnigy Aerodrive SK3 - 4250-350kv: 1.18 Nm @ 266 g ACK 5312CP - 330KV: 1.25 Nm @ 230 g Turnigy Aerodrive SK3 - 5065-275kv: 1.80 Nm @ 530 g KEDA 63-64 190KV: 2.18 Nm @ 670 g Turnigy Aerodrive SK3 - 6374-149kv: 3.77 Nm @ 840 g 9235-100KV Turnigy Multistar: 4.71 Nm @ 674 g
@@AustinTronics Looks like the hoverboard is pretty competitive in terms of torque density. I still think a great reduction would greatly increase the torque density and be beneficial to your robot. Generally, the bigger the robot, the higher the torque requirements are, and output shaft speed requirements are lower. So as the robot increases in size the need for a gearbox becomes greater. A few practical examples : the mini cheetah robot has a "quasi-direct drive" transmission. The gear ratio is about 1:4. The call it quasi because the gearbox is very "transparent", as in, forces applied to the output shaft are transmitted to the motor so efficiently that they still retain some of the benefits of direct drive, like being able to sense force by measuring the motor's current draw. Larger robots, such as Agility Robotics's Digit, have a high efficiency gearbox (key word is back-drivable. A motor that is not backdrivable is not transparent, because forces at the output shaft cannot be detected by the motor) at a higher gear ratio, maybe 1:20. They lose some transparency, and achieve high fidelity force/impedance control using a series elastic actuator that uses springs as sensors. Force is measured by measuring the deflection of the spring. Longer legs means higher speed is achieved for the same RPM, plus the "natural frequency" of the system is lower, see "inverted pendulum". This inverted pendulum model applies most directly to bipedal robots, but quadrupeds are essentially a pair of bipeds stuck together when performing a trot gait, which is the most common gait used to control a quadruped. You might want to check out this paper from a lab I used to work at, they did a couple papers that explained their process of selecting motors, gearboxes, and overall design. www.researchgate.net/publication/287415855_On_the_optimal_selection_of_motors_and_transmissions_for_electromechanical_and_robotic_systems/link/573b492208ae298602e45159/download Anyways, you didn't ask for a hastily written lecture in robotic actuator dynamics, but I like what you're doing and want to share my knowledge if it can help.
@@NathanBuildsRobots Thank you man, I really appreciate this! I will definitely read the paper! It's insane to think about adding gear boxes to these things, but I'm all for it though. Maybe I can get the robot to stand on its hind legs all by itself with that amount of torque haha.
@@AustinTronics I would like to make a geared version of the hoverboard motors, but I've got a couple month's worth of 3D printing content to work on for now. Maybe in I'll tackle it in 3-6 months. It would make an insanely strong servo motor for the price.
Great project. As you mentionned, USB is not ideal. Have you considered using the CAN bus instead? You can get data back from the Odrive this way. Odrive can control the motor angle very precisely, you are not limited to the magnet resolution. Look at camera gimbals for example.
16:00 The FPGA has FFT built in. If you indeed were to rewrite the Open Source drivers _(considering you are thereby not using the serial compression when no longer using USB)_ you'd be able to compress using the FFT of the FPGA. My guess is that you have your own plans for what to do. However, my reason for mentioning this is in case you _(or anybody else making such a project)_ ever decide to (deliberately) divide up the FPGA (in some HDL) into multiple small CPU and MMU chips _(like basically how retro computer game upgrades do that such as the Vampire accelerator for the commmodore amiga with FPU and MMU)._ So I'm suggesting that you could thereby make _(akin to a freescale multiple CPU computer)_ a cloned (in HDL) multiple CPU computer (linking each CPU with a cloned MMU) per hoverboard sensor board encoder. You'd be able to compress on each "fake" CPU and you'd have less bandwidth _(as you'd have a mere 12th of the FPGA horsepower or far less to play with, including bandwidth)._ As such, compressing the serial might help because by then you might be somewhat closer to saturating.
I think I’m experiencing this sort of black lash from my robotic hands. I’m a robotics hobbyist and this so far what I’d encounter as part of my problem.
can you suggest some cheaper motor driver that would support some encoder to increase the resolution. I have 4 of these motors and am on a budget. Was thinking of building robotic arm using these.
I'm very curious about how your project is going, the hardware your using is very similar to what I have for my project. At this point I'm just watching to see how the parts you picked fit together lol
Great video! For extending the main arms out, wouldn't it better to use a smaller motor? We are also using these motors but communicating with the drivers via CANBUS, which seems to be a good protocol fit. Bi-directional and very precise.
I thought about using smaller motors for this, and perhaps in future builds I will. For now though I just choose to stick with the same motors since I already have their motor characteristics dialed in. I will have to use smaller motors for the 3rd joint down on the leg though no matter what since having 3 motors with the hoverboard size would be too bulky to realistically fit in the design.
This video is so well made, I really appreciate the amount of work you put in here. I am wondering why you choose Zybo board over the more popular PYNQ board that have the same Zynq chip? Or did it just happen cause you have a zybo on hand?
Thank you, I really appreciate that! I choose Zybo because I have one sitting at my desk and I wanted to use it. But I have seen PYNQ thought and it seemed interesting and would like to try it out. I think I'd still want to migrate to the Zynq MPSoC EV SoC though as it seems more capable in the long run.
Yes. RPi 4+ obviously doesn't have an FPGA built into the chip so you wouldn't be able to make make certain applications as efficient as they could be, but from a system and implementation level, it's totally doable. Although you'll most likely want some additional supporting electronics like microcontrollers, motor drivers, etc., to offload responsibilities on the RPi4+ so it can focus on the heavy lifting (e.g. imaging processing, navigation control, etc.)
Why would you generate your sine waves on the fpga if your bottleneck is SPI? Odrive generates the sine waves based off of position and torque required. Generally speaking you want dedicated hardware for this close to loop application.
Great point! Yes, this has been something I've been grappling with since the very beginning and there are pros and cons to both approaches. That's why for the prototype, I'm sort of doing both (i.e. having the odrives in the system as well as having encoder signals going to the FPGA so it can potentially drive the motors as well). If I can get the FPGA to generate the sine waves and implement the control laws, not only would I be able to reduce cost significantly by not needing the odrives anymore, but I would be able to implement/try out my own closed loop control algorithms as opposed to the fixed one in the ODrive. I think it'd be pretty neat to have pretty much everything you need to control the system in a single board. As for the bottleneck from the encoder over SPI, there are ways of getting around this if your just referring to not having enough chip select lines. If your referring to all the data for all encoders being pushed through SPI simultaneously being the bottleneck, I can instantiate additional SPI channels on the FPGA to increase the throughput.
Why can't you read the encoder from the original motor in connection with the read from your super precise addon? The combination of the two should keep you in check. Keep working on making great videos.
Suggested and subscribed asap. Nice thorough explanation. I've been building large 18650 packs for mobile robotics as a research assistant and would love to offer any help to save you some work
That's awesome! This is definitely an area I'm still trying to educate myself on. You should join the discord so we could further discuss things: discord.gg/39XFvRZtbK
Great question! The chip that's the brain for Raspberry Pi (BCM2711 if we're talking about the Raspberry Pi 4 Model B) is a System on Chip (SoC) that contains a bunch of fixed hardware giving it a lot of capability (e.g. Quad-core Cortex-A72 processor, various peripheral controllers, etc.). Naturally, one might say "well yah, isn't all hardware inside the chip fixed once the chip is manufactured", and normally that is correct...but it's a little different when you bring FPGAs into the mix. The Zybo board's SoC is a Zynq which contains both fixed hardware, like dual ARM Cortex-A9 processors and some peripherals, but it also contains an FPGA. This allows me to create pretty much any peripheral or even processor like RISC-V or ARM AFTER the chip is manufactured. This is why its called an FPGA (Field Programmable Gate Array); you can modify the hardware when your in the field. The Raspberry Pi is great and I've used it for all sorts of projects, and in all honesty, I could have probably gotten away with using it here too. However, my goal with this project is to make an extremely versatile RoboDog to accommodate a wide range of objectives. If I find out I need more processing power, or for some code to run in parallel while not tying up the existing fixed hardware, I could literally just create another processor in the FPGA. If I want some peripheral that the Raspberry Pi doesn't have, or want 10 channels of a single peripheral (e.g. UART) for whatever reason, I could instantiate the circuitry to make that happen with an FPGA. Hope this helps!
@@AustinTronics I'm thinking that the FPGA is only useful once you've got the hardware finalized, but could be added on at the end. The board looks expensive and as you say will be outgrown quickly. I'm wondering if you distributed the work between several cheaper processors, and then add a fpga for experimentation at the end might end up being a cheaper solution, and one that is more readily accessible to most people. I'm also understanding why a fpga is useful to you as most peripherals are fixed as digital or analog, which can be accessed already by microcontrollers. Can you give an example of where the fpga shines?
Hmm, here's one example that comes to mind. With FPGAs, the more HDL you write for it, the faster your system becomes. This is quite the opposite with processors. This is because FPGAs operate in parallel while processors largely operate sequentially. For example, if I have instantiated some logic on an FPGA that reads the inputs for 100 buttons, that can all happen at the exact same time completely independent of one another. If I added another 100 buttons for a total of 200 inputs, the FPGA still wouldn't slow down, whereas a processor would. Keep in mind though that just the Zynq chip alone contains both the processors and the FPGA on the same silicon die. I'll try giving a few cases of why that may be useful. All of the signals going from the processor to the FPGA are in one neat little package. The likelihood of messing up communication from one subsystem to another is 0% because those connections are already made when the chip is manufactured. You also eliminate the chances of introducing signal integrity issues due to faulty/bad wiring. Lets say that your prototyping some sort of system and you want scalability, but not necessarily at the cost of drastically changing your power budget by adding more electronics. Having a system where you don't constantly have to add a processor here, or a processor there, is nice for not only power reduction, but also simplicity and fewer points of failure (wiring will be a lot easier too; and as mentioned above, better signal integrity as well). Lets say you are building something that's proprietary and you don't want people reverse engineering it. By having your entire system on a single silicon die, it becomes MUCH more difficult to reverse engineer whats going on compared to having several physically separate processors communicating with one another (e.g. you can probe the line with a logic analyzer and see whats being communicated). Referring to your first comment where you were thinking it'd only be useful once the hardware is finalized. Lets say that I finally have the RoboDog completely built but later I think to myself "oh no, I forgot to add these smart tactile feedback sensors to the feet of RoboDog that give me pressure feedback and communicates via I2C!". If I've done my due diligence, I will have left a few IOs on the FPGA available for myself for unknown situations like that. The FPGA IOs can pretty much be anything (GPIOs, I2C, SPI, UART, RS-485, CSI, Ethernet, Camera Link, RapidIO, MIL-STD-1553, etc.), which results in me not needing to add additional microcontroller to the mix to get that one thing that I was missing (something I wouldn't want to do anyways because I'd have to find a microcontroller for just that peripheral I need, manage the code, supply power to it, make sure there is enough space in the enclosure, make sure there are no high-powered electronics near it that will effect its signal integrity, etc.). Sure, you could bit bang I2C from an existing microcontroller in your system to imitate an I2C interface in a pinch (assuming that microcontroller doesn't have an I2C channel, or its currently being used for something else), but that will always be slower/less efficient than a dedicated hardware peripheral, such as one that you can instantiate in the fabric of an FPGA. I guess the point I'm trying to make here is that you have the ability to make whatever hardware-dedicated peripheral you want on the fly and already have that customization baked into your system, just make sure to leave a few IOs coming off the FPGA accessible if your designing your own board or using a dev board like the Zybo.
@@AustinTronics I think I'm going to have to learn about Zybo. I once worked with Xilinx about 40 years ago. It was fairly new technology then. But haven't looked at it since. At the time it was on prototype board, which allowed different configurations as needed. It took days to program the thing.
@@chrisBruner Zybo is a good intro board but there are many others you could choose. The board is not really special though, It's the Zynq that makes it worth it. Might I suggest checking this book out www.zynq-mpsoc-book.com/wp-content/uploads/2019/04/MPSoC_ebook_web_v1.0.pdf. Its a fairly extensive overview of the Zynq SoC family. Highly recommended.
For me bigger motors are not ideal even if the motors themselves come cheap. The things around them need to be scaled like structure and power which feeds into the cost and more importantly a large space to test and integrate, which I don't have at the moment.
Yes, this is 100% true. Due to the weight of the hoverboards and some rough torque sizing calculations, I'll probably have to scale back to only using 1 hoverboard per leg and use other motors for other joints. Another option is to drastically modify a hoverboard motor to reduce the weight.
Sellers of motors says its around 6.5Nm at ONE drive (there are 2 of them on HB): I have this notes: Three-phase eight line with Hall DC brushless motor NdFeB 6.5" 30mm 2.95 kg DC36V 7.5Nm 350W 6.5" 25mm 2.65 kg DC36V 6.8Nm ATA36V1706253756 25A 300W 6.5" 25mm 2.7/2.3 kg DC24V 6-6.8Nm HC24V1803023986 250W Maybe it will be helpfull for someone.
You can use an Arduino for the motor control as long as you have the correct amplification circuity. However, using it as the main processor will be much more difficult. Arduino does not contain the processing power necessary to make the RoboDog fully autonomous with all the sensors I plan on having (e.g. cameras to do the image processing). If you don't want to use the Zybo or Odrive board, you could substitute them for a few Arduino's (for driving the output signals to motors and receiving input signals of some sensors) and 1 or 2 Raspberry Pi's (to receive input from some sensors and take care of the more computationally intensive tasks).
@@iqrobotics8960 Software and electrical development will not be the same as using a Zybo and Odrive. If you want development to be easier for you, go with something like an Odrive and a Raspberry Pi. If you want more flexibility/customizability, go with something like the Odrive and Zybo board.
Why not try a power wheelchair.. make it weather proof .. our joysticks bite & simply don’t hold up .. chargers melt the 3 pin connector on the joystick as so many are sold without a uL & get hot enough to melt .. batteries vary as much as the details not factual & misleading . I wouldn’t mind having a robo dog to be a service dog .. my dog died & I miss him dearly . This quad was made paralyzed by a device lacking a cervical patent .. I think it’s time technology help patients vs use our life to test what mfg’s had no data for & pressures of fda - they act as surgeons & a god while knowing the outcome is life changing adversely. Ty for the thought .. it’s nice to see the brain used. Oh, my Permobil c300 motor held well .. rovi motor perhaps ?
This video reminds me of this: ruclips.net/video/OZvjfbpXpro/видео.html Have you looked at the motor she chose and the controller she developed? Curious how you see these comparing. The motor she chose seems to have the advantage of lower cogging torque than a typical hoverboard motor and includes an integrated high resolution encoder.
I just watched her video. It's awesome that she did that because there is seriously a lack of large scale hobby BLDC motors like that. I love the mount that's on that wheel too (better than the shaft that you need to work with on the hoverboard motor). She also has the advantage of increase poles in her motor making a smoother rotation when having fine-grain control. Her solution of the wheel and built in encoder would be ideal for my motors. It's awesome that she also made a motor controller. ODrive seems to have more bells and whistles than her motor controller at first glance though, but I'd have to mess around with it or look at the spec sheet to know for certain. I will say though that by her having the motor controller and motor so tightly integrated with one another (i.e. making the data sheets and figuring out optimal configs for the controller for that specific motor) is a major plus since it takes out a lot of the guess work.
@@AustinTronics Yeah she was basically attacking the same problem from a different perspective. I've gotta say I like the look of the encoders you're using though. I'm interested in designing a 2-axis satellite tracker similar to this: github.com/YohanHadji/SuperAntennaz A brushless direct drive design is very appealing, so I've been researching what's out there recently. My use case would be with 1-4NM motors though. There's a really good motor controller that's designed to handle 3-axis gimbals which seems to be the most affordable option in that range and designed for fine control. It's called STorM32-BGC and both the hardware and firmware are open source. More here: www.rcgroups.com/forums/showthread.php?2055844-STorM32-BGC-32-bit-3-axis-brushless-gimbal-controller For your use case, I also came across this video yesterday: ruclips.net/video/Wb1gsJ4K4pM/видео.html He's comparing ODrive to MIT Mini Cheetah and MJBots Moteus at minimum speeds. There's some good comments from the Moteus creator.
@@AustinTronics Also, this isn't brushless direct drive, but this guy's dual-encoder based backlash elimination system to achieve high precision with servo motors is really cool: ruclips.net/video/RkNgRe8X4iY/видео.html
It does not make a lot of sense. Odrive already supports all that you need and you can use simple can hus to talk to odrives, encoders on them and you are good to go. Instead, you make a single cpu dependency... Does not make a lot of sense to me, but hey - you are building it, so you are the captain...
I don't think it's that simple. I could just as easily say having ODrives forces me with having a dependency on ODrives (hence additional wiring, cost, power, space, etc.). It ultimately depends on what your goals are. If you want to slap a bunch of off-the-shelf electronics together, then sure, absolutely. However, what if you want to try different solutions that would normally be fixed within the black box that is ODrive and learn diffrent things along the way? Regardless, I see pros and cons to both solutions.
@@AustinTronics I understand your poiny. However, oDrive is open source - both HW and SW. My point was more towards simplifying the control. If you need to control feedback loops, calculating pid, doing adjustments, calculate inverse kinematics, ... all on the main cpu, you might have problems. Especially with interrupt handlers, etc. Plus, offloading some coding to something done by community seems like a good idea. I don't look at it as slapping boxes together, but I understand the point.
Got it, makes sense. As for the control algorithms, inv. kinematics, etc., I was hoping to offload some of these tasks to the FPGA so they can run in parallel.
Nice video with well depicted info! Just an FYI; decimal values are read out in single numbers.. eg; 7.51 is second point five one, not seven point fifty-one. You can also find hoverboard replacement motors that are around $40USD for 2... Link below is an Australian seller. I assume you can find similar deals locally. www.ebay.com.au/itm/393256630352 For motor drivers, the stock mainboards for these things are cheap and have been 'hacked' so you can control them however you like. Much cheaper than the odrive system.
![Megan Thee Stallion - Mamushi (Remix) [feat. TWICE] [Official Audio]](http://i.ytimg.com/vi/5c0_u9PsrsQ/mqdefault.jpg)
As a robotics hobbyist, I've found that it's hard finding information beyond surface level without moving into a formal education forum. These types of deep dives help bridge the knowledge gap that would take years to overcome. Thank you Austin!
Thank you Chad, I appreciate the kind words!
Having no prior exposure to this technology I am again impressed in the knowledge one can gain on RUclips. Thank you very much!!!!
Congratulations this hoverboard motor used as a robotic motor will take on the internet by storm especially on hackaday.
Nice work. I decided against direct drive for my project. Once you gear down the different max RPMs of the different motors the torque values become a lot more competitive. Gearing down also helps with the encoder resolution. And Cycloid drives tend to be fairly low backlash. A 10-to-1 gear reduction gave me more torque than a hoverboard motor while also having a higher RPM on the limb for less weight.
designed an exo-suit for dogs using AX-12A motors and Pi and this really makes me wanna work on it and improve it. Really inspiring dude!
I am beginning a project; RC Lawnmower, boring and begginnerish, i know, but it's my first project... I have the motors from a 'broken' hoverboard, and want to get drivers for them. I recently looked up ODrive and it looks like all their controllers are sold out . . . there are some on Amazon but, I admittedly do not know much, and cannot afford to make a bunch of mistakes to 'figure it out.' Thank you for sharing your experiences, like this. Your information about the hall resolution was especially helpful as i had no idea exactly how that worked, or how accurate or fine the feedback was. seems to be only good for speed, or maybe to prevent cogging at low RPMs or 'skipping' ...
Love you video. Thanks for the update. I'll look forward to see more of your videos.
been waiting for someone to do this! love building stuff with hoverboard motors!
Hey man, I just found your channel and I absolutely love how well you've educated your viewers in this video while staying interesting! You are cool bro.
Man, you're just freaking sick bro!! Really inspires me!
Really looking forward to seeing this project coming to life. Great presentation !!
this guy. been thinking bout doing a mechsuit with hoverboard joints lol.
Great job! Really inspiring! It opens up road to so many ideas. Thanks for sharing.
Thanks for explaining everything, it's very educational.
This is a very well made video. Very informative. Hoping to see more :) And It's sad that RUclips algo does not help to promote more quality videos like these
Absolutely impressive content quality here :)
I also have an idea like this, but I can't implement it yet, I'm waiting for your next video, thank you for the information.
I'm 3D printing some prototype parts for the next video as I type this comment.
Glad I found your channel
YES! Time to go to ebay and buy up hover boards listed as "for parts or not working". I might get some nice usable lithium cells and motor drivers then too
I really liked your video so I’m subscribing 👍🏻😊
Look I'm not a pro, and I don't really know what I'm talking about. I'm just thinking you need the torque and holding power that is only going to come from a reduction drive... this, also effectively gives you more precision over the movement: dividing one "state" of the sensor by the ratio of your reduction. Industrial robots use toothed belt systems because they have incredible holding power and minimal backlash when properly tension-ed. They also contort those belts in some amazing ways to squeeze everything into a small package. I think they usually run a 10:1 reduction of the pulley.
You can replace the binary hall sensor encoders in the blds motors with analog one and you will be able to read the magnetic field strength. That will give you higher resolution. One more thing to consider is that driving the motors is done with strong magnetic field that will also be picked up by any magnetic based encoder near by. You will likely have hard time dealing with thus interference. You will not get high resolution from magnetic encoder and drive the motor at the same time. You should consider using either optical or resistive encoders.
Alright, someone else has discovered hoverboard motors, time for me to stock up before they become worth more than hoverboards ever where.
Uhh been discovered for a loong time ... we got custom firmware for most boards in hoverboards.. there's a nice telegram or discord channel and stuff
@@forbiddenera i have a hoverboard but can't find the custom firmware for it. The ones on internet use a single control board. Mine has 2 boards which act as master slave, i found one such firmware but though similar, it is a different board. could you help me out in finding the firmware for my board?
@@yashvardhanagarwal2740 I don't have one of those but I do remember seeing a firmware for that type when I was researching. There is a hoverboard hacking telegram channel, find that and they can help direct you
@@forbiddenera i was not able to findthe the channel, could you send me the link
Those motors are going have to move fast. Those escs are gonna be cooookin
Your channle is sooooo under rated
Thank you man, I appreciate that!
awesome explanation, gained a follower here
Great job thank you 👍
good idea with the motors
Great video. +1 sub. I'm using hoverboard motors but with a dual vesc board (custom firmware using simplefoc). Keep up the great work! I'll be interested to see how you mount the as5048 as there is no obvious place to mount (no static external stator and no exposed spindle)
Awesome, keep going
Great video - would the ODrive S1 controller, with the on-board encoder, also work in this case? What might be the pros and cons of one vs the other? Thanks!
What's the maximum torque and weight of a hoverboard motor? For quadrupedal robot jumping, we can achieve around 40 cm jump height for a 9 kg robot assuming 18 Nm torque on some of the 12 quasi-direct drive actuators. My thinking is if hoverboard motors are so cheap and have such high output, and are backdrivable due to no gearing, then it would be great for legged robots.
Can you make a robotic arm for quadriplegics.. my left arm / hand is c4 damaged with contracture .. my right is c5 damaged . No splints could ever be used . Not a amputee, have the limb in the way
You mentioned that you want to use external power instead of the battery while testing. While this sounds like a good idea you will have hard time getting power source that can supply the current needed to drive the motors. My guess if you will need something im the neighbourhood of 100A to prevent brow outs. Also another issue is that the bldc motors will feed back current to the system sometimes and unless you have some way to clamp the power voltage it will lift it and you might end up damaging the electronics. You should consider keeping the battery in the system while testing and making something that will charge the battery while in use from external source. It will solve the issues with external power source.
I use the flipsky vescs but they are expensive! Where do you get your motors from? Like can you buy them directly?
How is the torque to weight ratio though?
Cycloidal drove gearboxes have high efficiency and low backlash. I think that's what Agility Robotics uses in their digit robot. I wish their was some commercially available low cost options that were suitable for robotics.
Hoverboard motors plus a cycloidal gearbox could produce some monstrous torques.
Good question on the torque to weight ratio so I looked into it and put a table below for the motors I talked about in the video:
Hoverboard motor:
12.92 Nm @ 2177 g
ODrive Robotics D5065 - 270kv:
1.99 Nm @ 420 g
ODrive Robotics D6374 - 150kv:
3.86 Nm @ 890 g
Tarot 4008 330kv:
0.63 Nm @ 80 g
Turnigy Aerodrive SK3 - 4250-350kv:
1.18 Nm @ 266 g
ACK 5312CP - 330KV:
1.25 Nm @ 230 g
Turnigy Aerodrive SK3 - 5065-275kv:
1.80 Nm @ 530 g
KEDA 63-64 190KV:
2.18 Nm @ 670 g
Turnigy Aerodrive SK3 - 6374-149kv:
3.77 Nm @ 840 g
9235-100KV Turnigy Multistar:
4.71 Nm @ 674 g
@@AustinTronics
Looks like the hoverboard is pretty competitive in terms of torque density.
I still think a great reduction would greatly increase the torque density and be beneficial to your robot. Generally, the bigger the robot, the higher the torque requirements are, and output shaft speed requirements are lower. So as the robot increases in size the need for a gearbox becomes greater.
A few practical examples : the mini cheetah robot has a "quasi-direct drive" transmission. The gear ratio is about 1:4. The call it quasi because the gearbox is very "transparent", as in, forces applied to the output shaft are transmitted to the motor so efficiently that they still retain some of the benefits of direct drive, like being able to sense force by measuring the motor's current draw.
Larger robots, such as Agility Robotics's Digit, have a high efficiency gearbox (key word is back-drivable. A motor that is not backdrivable is not transparent, because forces at the output shaft cannot be detected by the motor) at a higher gear ratio, maybe 1:20. They lose some transparency, and achieve high fidelity force/impedance control using a series elastic actuator that uses springs as sensors. Force is measured by measuring the deflection of the spring.
Longer legs means higher speed is achieved for the same RPM, plus the "natural frequency" of the system is lower, see "inverted pendulum". This inverted pendulum model applies most directly to bipedal robots, but quadrupeds are essentially a pair of bipeds stuck together when performing a trot gait, which is the most common gait used to control a quadruped.
You might want to check out this paper from a lab I used to work at, they did a couple papers that explained their process of selecting motors, gearboxes, and overall design.
www.researchgate.net/publication/287415855_On_the_optimal_selection_of_motors_and_transmissions_for_electromechanical_and_robotic_systems/link/573b492208ae298602e45159/download
Anyways, you didn't ask for a hastily written lecture in robotic actuator dynamics, but I like what you're doing and want to share my knowledge if it can help.
@@NathanBuildsRobots Thank you man, I really appreciate this! I will definitely read the paper! It's insane to think about adding gear boxes to these things, but I'm all for it though. Maybe I can get the robot to stand on its hind legs all by itself with that amount of torque haha.
@@AustinTronics I would like to make a geared version of the hoverboard motors, but I've got a couple month's worth of 3D printing content to work on for now. Maybe in I'll tackle it in 3-6 months. It would make an insanely strong servo motor for the price.
For the chip select line you could use a multiplexer ore a I2C/serial port expander like the MCP23017 chip
Good idea, thank you!
Great project. As you mentionned, USB is not ideal. Have you considered using the CAN bus instead? You can get data back from the Odrive this way. Odrive can control the motor angle very precisely, you are not limited to the magnet resolution. Look at camera gimbals for example.
Thank you for the insight! And yes, I am looking into CAN bus currently, there seems to be a lot of benefits to it.
16:00 The FPGA has FFT built in. If you indeed were to rewrite the Open Source drivers _(considering you are thereby not using the serial compression when no longer using USB)_ you'd be able to compress using the FFT of the FPGA. My guess is that you have your own plans for what to do. However, my reason for mentioning this is in case you _(or anybody else making such a project)_ ever decide to (deliberately) divide up the FPGA (in some HDL) into multiple small CPU and MMU chips _(like basically how retro computer game upgrades do that such as the Vampire accelerator for the commmodore amiga with FPU and MMU)._ So I'm suggesting that you could thereby make _(akin to a freescale multiple CPU computer)_ a cloned (in HDL) multiple CPU computer (linking each CPU with a cloned MMU) per hoverboard sensor board encoder. You'd be able to compress on each "fake" CPU and you'd have less bandwidth _(as you'd have a mere 12th of the FPGA horsepower or far less to play with, including bandwidth)._ As such, compressing the serial might help because by then you might be somewhat closer to saturating.
I think I’m experiencing this sort of black lash from my robotic hands. I’m a robotics hobbyist and this so far what I’d encounter as part of my problem.
21700 P42A milocel lithium cells are very nice
can you suggest some cheaper motor driver that would support some encoder to increase the resolution. I have 4 of these motors and am on a budget. Was thinking of building robotic arm using these.
Well done 🇰🇼احسنت
For the torque/$ you should have the 6384 motors as well as those are only $99 and offer more constant current than 6374.
I'm very curious about how your project is going, the hardware your using is very similar to what I have for my project. At this point I'm just watching to see how the parts you picked fit together lol
Nice! Hopefully I can bang my head on the wall first so you don't have to lol.
@@AustinTronics we welcome you to the strong forehead foundation lol, I've been flattening my face for a few years now. I have hope for you
I saw two hoverboards cheap at a garage sale, I regret not buying them now
Great video! For extending the main arms out, wouldn't it better to use a smaller motor? We are also using these motors but communicating with the drivers via CANBUS, which seems to be a good protocol fit. Bi-directional and very precise.
I thought about using smaller motors for this, and perhaps in future builds I will. For now though I just choose to stick with the same motors since I already have their motor characteristics dialed in. I will have to use smaller motors for the 3rd joint down on the leg though no matter what since having 3 motors with the hoverboard size would be too bulky to realistically fit in the design.
for the hall effect sensors you could use i2c, that would only require clock and data o:
This video is so well made, I really appreciate the amount of work you put in here. I am wondering why you choose Zybo board over the more popular PYNQ board that have the same Zynq chip? Or did it just happen cause you have a zybo on hand?
Thank you, I really appreciate that! I choose Zybo because I have one sitting at my desk and I wanted to use it. But I have seen PYNQ thought and it seemed interesting and would like to try it out. I think I'd still want to migrate to the Zynq MPSoC EV SoC though as it seems more capable in the long run.
Can we use Raspberry Pi 4 +? alternative to Zybo Z7-20
Yes. RPi 4+ obviously doesn't have an FPGA built into the chip so you wouldn't be able to make make certain applications as efficient as they could be, but from a system and implementation level, it's totally doable. Although you'll most likely want some additional supporting electronics like microcontrollers, motor drivers, etc., to offload responsibilities on the RPi4+ so it can focus on the heavy lifting (e.g. imaging processing, navigation control, etc.)
Why would you generate your sine waves on the fpga if your bottleneck is SPI? Odrive generates the sine waves based off of position and torque required. Generally speaking you want dedicated hardware for this close to loop application.
Great point! Yes, this has been something I've been grappling with since the very beginning and there are pros and cons to both approaches. That's why for the prototype, I'm sort of doing both (i.e. having the odrives in the system as well as having encoder signals going to the FPGA so it can potentially drive the motors as well). If I can get the FPGA to generate the sine waves and implement the control laws, not only would I be able to reduce cost significantly by not needing the odrives anymore, but I would be able to implement/try out my own closed loop control algorithms as opposed to the fixed one in the ODrive. I think it'd be pretty neat to have pretty much everything you need to control the system in a single board. As for the bottleneck from the encoder over SPI, there are ways of getting around this if your just referring to not having enough chip select lines. If your referring to all the data for all encoders being pushed through SPI simultaneously being the bottleneck, I can instantiate additional SPI channels on the FPGA to increase the throughput.
Why can't you read the encoder from the original motor in connection with the read from your super precise addon? The combination of the two should keep you in check. Keep working on making great videos.
Suggested and subscribed asap. Nice thorough explanation. I've been building large 18650 packs for mobile robotics as a research assistant and would love to offer any help to save you some work
That's awesome! This is definitely an area I'm still trying to educate myself on. You should join the discord so we could further discuss things: discord.gg/39XFvRZtbK
Ehm... why did I learn about this channel just now? Subscribed af !
Thanks, It is interesting to see Hoverboard motor can provide that much torque for $40. But how much weight is it?
Without any modifications to the hub, it's about 4.8lbs.
@@AustinTronics oh, so it is about 4-5 heavier than a Cheetah Motor with gearbox
@@chuongnguyen4980 Sounds about right, the hoverboard motor is massive...this will be no small dog.
Looks like Blade Wolf by Metal Solid Rising.
I had the same idea
What is the advantage of the zybo over raspberry pi or something along that line? Great video. Looking forward to more.
Great question! The chip that's the brain for Raspberry Pi (BCM2711 if we're talking about the Raspberry Pi 4 Model B) is a System on Chip (SoC) that contains a bunch of fixed hardware giving it a lot of capability (e.g. Quad-core Cortex-A72 processor, various peripheral controllers, etc.). Naturally, one might say "well yah, isn't all hardware inside the chip fixed once the chip is manufactured", and normally that is correct...but it's a little different when you bring FPGAs into the mix. The Zybo board's SoC is a Zynq which contains both fixed hardware, like dual ARM Cortex-A9 processors and some peripherals, but it also contains an FPGA. This allows me to create pretty much any peripheral or even processor like RISC-V or ARM AFTER the chip is manufactured. This is why its called an FPGA (Field Programmable Gate Array); you can modify the hardware when your in the field.
The Raspberry Pi is great and I've used it for all sorts of projects, and in all honesty, I could have probably gotten away with using it here too. However, my goal with this project is to make an extremely versatile RoboDog to accommodate a wide range of objectives. If I find out I need more processing power, or for some code to run in parallel while not tying up the existing fixed hardware, I could literally just create another processor in the FPGA. If I want some peripheral that the Raspberry Pi doesn't have, or want 10 channels of a single peripheral (e.g. UART) for whatever reason, I could instantiate the circuitry to make that happen with an FPGA.
Hope this helps!
@@AustinTronics I'm thinking that the FPGA is only useful once you've got the hardware finalized, but could be added on at the end. The board looks expensive and as you say will be outgrown quickly. I'm wondering if you distributed the work between several cheaper processors, and then add a fpga for experimentation at the end might end up being a cheaper solution, and one that is more readily accessible to most people. I'm also understanding why a fpga is useful to you as most peripherals are fixed as digital or analog, which can be accessed already by microcontrollers. Can you give an example of where the fpga shines?
Hmm, here's one example that comes to mind.
With FPGAs, the more HDL you write for it, the faster your system becomes. This is quite the opposite with processors. This is because FPGAs operate in parallel while processors largely operate sequentially. For example, if I have instantiated some logic on an FPGA that reads the inputs for 100 buttons, that can all happen at the exact same time completely independent of one another. If I added another 100 buttons for a total of 200 inputs, the FPGA still wouldn't slow down, whereas a processor would.
Keep in mind though that just the Zynq chip alone contains both the processors and the FPGA on the same silicon die. I'll try giving a few cases of why that may be useful.
All of the signals going from the processor to the FPGA are in one neat little package. The likelihood of messing up communication from one subsystem to another is 0% because those connections are already made when the chip is manufactured. You also eliminate the chances of introducing signal integrity issues due to faulty/bad wiring.
Lets say that your prototyping some sort of system and you want scalability, but not necessarily at the cost of drastically changing your power budget by adding more electronics. Having a system where you don't constantly have to add a processor here, or a processor there, is nice for not only power reduction, but also simplicity and fewer points of failure (wiring will be a lot easier too; and as mentioned above, better signal integrity as well).
Lets say you are building something that's proprietary and you don't want people reverse engineering it. By having your entire system on a single silicon die, it becomes MUCH more difficult to reverse engineer whats going on compared to having several physically separate processors communicating with one another (e.g. you can probe the line with a logic analyzer and see whats being communicated).
Referring to your first comment where you were thinking it'd only be useful once the hardware is finalized. Lets say that I finally have the RoboDog completely built but later I think to myself "oh no, I forgot to add these smart tactile feedback sensors to the feet of RoboDog that give me pressure feedback and communicates via I2C!". If I've done my due diligence, I will have left a few IOs on the FPGA available for myself for unknown situations like that. The FPGA IOs can pretty much be anything (GPIOs, I2C, SPI, UART, RS-485, CSI, Ethernet, Camera Link, RapidIO, MIL-STD-1553, etc.), which results in me not needing to add additional microcontroller to the mix to get that one thing that I was missing (something I wouldn't want to do anyways because I'd have to find a microcontroller for just that peripheral I need, manage the code, supply power to it, make sure there is enough space in the enclosure, make sure there are no high-powered electronics near it that will effect its signal integrity, etc.). Sure, you could bit bang I2C from an existing microcontroller in your system to imitate an I2C interface in a pinch (assuming that microcontroller doesn't have an I2C channel, or its currently being used for something else), but that will always be slower/less efficient than a dedicated hardware peripheral, such as one that you can instantiate in the fabric of an FPGA. I guess the point I'm trying to make here is that you have the ability to make whatever hardware-dedicated peripheral you want on the fly and already have that customization baked into your system, just make sure to leave a few IOs coming off the FPGA accessible if your designing your own board or using a dev board like the Zybo.
@@AustinTronics I think I'm going to have to learn about Zybo. I once worked with Xilinx about 40 years ago. It was fairly new technology then. But haven't looked at it since. At the time it was on prototype board, which allowed different configurations as needed. It took days to program the thing.
@@chrisBruner Zybo is a good intro board but there are many others you could choose. The board is not really special though, It's the Zynq that makes it worth it. Might I suggest checking this book out www.zynq-mpsoc-book.com/wp-content/uploads/2019/04/MPSoC_ebook_web_v1.0.pdf. Its a fairly extensive overview of the Zynq SoC family. Highly recommended.
any update on the build?
Currently fine-tuning the inverse kinematics for getting the motors to move the way I want based on object detection. Working on part 11.
@@AustinTronics ty
have you ever messed with Savox servos?
I have! Super long time ago though.
13:04 but you wont be able to track number of turns after power cycle.
For me bigger motors are not ideal even if the motors themselves come cheap. The things around them need to be scaled like structure and power which feeds into the cost and more importantly a large space to test and integrate, which I don't have at the moment.
Yes, this is 100% true. Due to the weight of the hoverboards and some rough torque sizing calculations, I'll probably have to scale back to only using 1 hoverboard per leg and use other motors for other joints. Another option is to drastically modify a hoverboard motor to reduce the weight.
doesn't hover, has 2 wheels, never leaves the ground
ah yes this board hovers
We just sad BTTF didn't happen
Sellers of motors says its around 6.5Nm at ONE drive (there are 2 of them on HB):
I have this notes:
Three-phase eight line with Hall DC brushless motor NdFeB
6.5" 30mm 2.95 kg DC36V 7.5Nm 350W
6.5" 25mm 2.65 kg DC36V 6.8Nm ATA36V1706253756 25A 300W
6.5" 25mm 2.7/2.3 kg DC24V 6-6.8Nm HC24V1803023986 250W
Maybe it will be helpfull for someone.
Can i use xiaomi m365 electric scooter motor ?
Sure, I don't see why not.
Can we use ardino to control please. Answer
You can use an Arduino for the motor control as long as you have the correct amplification circuity. However, using it as the main processor will be much more difficult. Arduino does not contain the processing power necessary to make the RoboDog fully autonomous with all the sensors I plan on having (e.g. cameras to do the image processing). If you don't want to use the Zybo or Odrive board, you could substitute them for a few Arduino's (for driving the output signals to motors and receiving input signals of some sensors) and 1 or 2 Raspberry Pi's (to receive input from some sensors and take care of the more computationally intensive tasks).
It will work as same sir??
Thank you for help
@@iqrobotics8960 Software and electrical development will not be the same as using a Zybo and Odrive. If you want development to be easier for you, go with something like an Odrive and a Raspberry Pi. If you want more flexibility/customizability, go with something like the Odrive and Zybo board.
I am in school my age is 14 year
how about you use people units
Makes more robotics tutorials!!! please
You got it! Next video should be out soon!
Motors are too weak, you need a gearbox, someone made a skateboard with these and it didn't have a lot of torque
Too much dog, not enough robot lol
Why not try a power wheelchair.. make it weather proof .. our joysticks bite & simply don’t hold up .. chargers melt the 3 pin connector on the joystick as so many are sold without a uL & get hot enough to melt .. batteries vary as much as the details not factual & misleading .
I wouldn’t mind having a robo dog to be a service dog .. my dog died & I miss him dearly . This quad was made paralyzed by a device lacking a cervical patent .. I think it’s time technology help patients vs use our life to test what mfg’s had no data for & pressures of fda - they act as surgeons & a god while knowing the outcome is life changing adversely.
Ty for the thought .. it’s nice to see the brain used.
Oh, my Permobil c300 motor held well .. rovi motor perhaps ?
This video reminds me of this: ruclips.net/video/OZvjfbpXpro/видео.html
Have you looked at the motor she chose and the controller she developed? Curious how you see these comparing. The motor she chose seems to have the advantage of lower cogging torque than a typical hoverboard motor and includes an integrated high resolution encoder.
I just watched her video. It's awesome that she did that because there is seriously a lack of large scale hobby BLDC motors like that. I love the mount that's on that wheel too (better than the shaft that you need to work with on the hoverboard motor). She also has the advantage of increase poles in her motor making a smoother rotation when having fine-grain control. Her solution of the wheel and built in encoder would be ideal for my motors. It's awesome that she also made a motor controller. ODrive seems to have more bells and whistles than her motor controller at first glance though, but I'd have to mess around with it or look at the spec sheet to know for certain. I will say though that by her having the motor controller and motor so tightly integrated with one another (i.e. making the data sheets and figuring out optimal configs for the controller for that specific motor) is a major plus since it takes out a lot of the guess work.
@@AustinTronics Yeah she was basically attacking the same problem from a different perspective. I've gotta say I like the look of the encoders you're using though. I'm interested in designing a 2-axis satellite tracker similar to this: github.com/YohanHadji/SuperAntennaz
A brushless direct drive design is very appealing, so I've been researching what's out there recently.
My use case would be with 1-4NM motors though. There's a really good motor controller that's designed to handle 3-axis gimbals which seems to be the most affordable option in that range and designed for fine control. It's called STorM32-BGC and both the hardware and firmware are open source. More here: www.rcgroups.com/forums/showthread.php?2055844-STorM32-BGC-32-bit-3-axis-brushless-gimbal-controller
For your use case, I also came across this video yesterday: ruclips.net/video/Wb1gsJ4K4pM/видео.html
He's comparing ODrive to MIT Mini Cheetah and MJBots Moteus at minimum speeds. There's some good comments from the Moteus creator.
@@AustinTronics Also, this isn't brushless direct drive, but this guy's dual-encoder based backlash elimination system to achieve high precision with servo motors is really cool: ruclips.net/video/RkNgRe8X4iY/видео.html
what the hell, 13N is not a weight :D
Newtons are a measure of weight, you may be confusing mass and weight.
@@execration_texts Oh. Thanks, didnt know that
It does not make a lot of sense. Odrive already supports all that you need and you can use simple can hus to talk to odrives, encoders on them and you are good to go. Instead, you make a single cpu dependency... Does not make a lot of sense to me, but hey - you are building it, so you are the captain...
I don't think it's that simple. I could just as easily say having ODrives forces me with having a dependency on ODrives (hence additional wiring, cost, power, space, etc.). It ultimately depends on what your goals are. If you want to slap a bunch of off-the-shelf electronics together, then sure, absolutely. However, what if you want to try different solutions that would normally be fixed within the black box that is ODrive and learn diffrent things along the way? Regardless, I see pros and cons to both solutions.
@@AustinTronics I understand your poiny. However, oDrive is open source - both HW and SW. My point was more towards simplifying the control. If you need to control feedback loops, calculating pid, doing adjustments, calculate inverse kinematics, ... all on the main cpu, you might have problems. Especially with interrupt handlers, etc. Plus, offloading some coding to something done by community seems like a good idea. I don't look at it as slapping boxes together, but I understand the point.
Got it, makes sense. As for the control algorithms, inv. kinematics, etc., I was hoping to offload some of these tasks to the FPGA so they can run in parallel.
Где собака !!???
Felt asleep
Nice video with well depicted info!
Just an FYI; decimal values are read out in single numbers.. eg; 7.51 is second point five one, not seven point fifty-one.
You can also find hoverboard replacement motors that are around $40USD for 2... Link below is an Australian seller. I assume you can find similar deals locally.
www.ebay.com.au/itm/393256630352
For motor drivers, the stock mainboards for these things are cheap and have been 'hacked' so you can control them however you like. Much cheaper than the odrive system.
lbs, ok i am out.
I agree, metric > imperial.
add 4 data lines and an accelerometer. you can add 2 Rpk gps in the same mackine... would need a tail and nose.
Alright, someone else has discovered hoverboard motors, time for me to stock up before they become worth more than hoverboards ever where.