RoboDog Part 3 | Using Hoverboard Motors for RoboDog

hoverboard motors that's right i'm making this thing out of hoverboard motors in case you don't know what i'm talking about i'm making a robotic quadruped or in short a robodog i gave an outline of features of what i wanted for the robodog in intro 1 video so make sure to check that out if you haven't already so these motors come from hoverboards you know those things that you try to balance on basically if you shift your weight forward you go forward and if you shift your weight backwards you go backwards i plan on using these brushless dc motors for robodog so why these motors specifically there are three main reasons torque price and direct drive let's start with torque naturally these things have a lot of torque if they're able to balance a person just how much torque do they have various online resources have stated that the hoverboard motors provide around 13 newton meters of torque to develop a sense of intuition of how much that is imagine a weight at the end of a 1 meter rod attached to the center of the wheel if the weight was 13 newtons the motor would have to apply 13 newton meters of torque to support it in imperial units this would be equivalent to 9.59 foot-pounds of torque where the rod is one foot in length with a 9.59 pound weight at the end this is worst case scenario with the weight at the farthest horizontal point from the wheel if the motor starts rotating with this one foot rod it won't need as much torque to support the weight next let's look at price the price of a single hoverboard motor comes in at about 40 us dollars here are the torques and prices of other common brushless dc motors on the market right now any guesses on what motors outlier here what if i show you price to torque graph how about now yep the hoverboard motors these motors are no joke they have an amazing price to torque ratio but how is this possible how can these motors be so much cheaper than the others well one of the main reasons is because they're mass manufactured hundreds of thousands of hoverboard motors have been manufactured and things can get pretty cheap when they're manufactured at that scale by the way additional motor characteristics for all the motors i just showed can be found from the documentation provided by odrive robotics but more on them later for now let's talk about direct drive direct drive is exactly what it sounds like it's the ability for a motor to drive your system directly the hoverboards definitely fall into this category along with a lot of other things like washing machines or pumps okay so direct drive sounds pretty simple right a motor that controls something directly but what does the system look like when the motor doesn't drive something directly it can sort of look something like this here are two types of mechanisms widely used throughout industry the top is a gearbox and the bottom is a belt drive because motors can't always drive your system directly especially when there's a lot of torque that's needed they need something to help them apply mechanical advantage which helps increase your torque at the sacrifice of speed systems with mechanical advantage are less efficient they make your system more complicated there are more moving parts which can break down over time and one of the scariest things of all for robotics they can have backlash backlash can be thought of as the amount of play or slop in your system take a look at this robotic arm i made a while ago i water jetted these gears and uh yeah let's just say that i've learned a lot since then backlash can exist in gearboxes as well although it may not look like it for professionally made gears there can still be tiny gaps between the teeth that add up over all the gears looking a little closer at this gearbox you saw earlier i can turn the output shaft by this much and the motor is not even turning at all that's how much free space and flex is in between the gears this can be really bad for robotics because it makes the angular position of your motor less predictable and trying to accommodate for something like this can be really difficult here is a real example of backlash in action this is old footage back when i competed in the robosub competition like in 2015. i was trying to get the robotic arm to react to objects with image processing you can see the backlash is not only coming from the test fixture that's holding up the robotic arm but in the arm itself because of how much backlash there was it made it very difficult to grab things accurately with this setup there are some videos i made on this channel of the robotic arm where i try to refine this design if you're curious about it i'll put a link down below so now that we covered what type of motors i plan on using let's look at this electrical diagram okay this looks kind of scary but it's actually not that bad we'll look at each component one at a time so that you can get a sense of what everything is doing and then we'll go over the wiring so starting off we have the zybo board this board will be the brain of robodog it'll be responsible for reading in various sensors and controlling the motors this board was built around the xilinx zinc 7000 family which contains both an arctic 7 fpga and an arm cortex a9 processor on a single chip xylinks calls this chip their all programmable system on chip the exact cybo board i plan on using is called the zybo z7-20 i'll leave a link in the description of where you can buy this board as well as the other products i'll be mentioning in this video here are some of the specs of the zybo board from the vendor's website you can find a lot more specs about the board there before i move on i will say that i'll probably be outgrowing this board pretty fast there most likely will not be enough resources i'll need from the zybo board or the zinc 7020 chip as i add more motors and sensors to the design so i plan on moving from the zinc 7020 to the zinc mp song the zinc mp sock is a much more capable processor with a lot more bells and whistles to do stuff with but the chip in its development board is also more expensive however i'm sticking with the zybo board for now since i think it'll be a nice beginner board for those of you that want to follow along or just explore what it's like to develop on systems that have both a processor and an fpga i feel like i can get relatively far with the design using just the zinc and because i plan on upgrading to another zync device a lot of the code if not all of it should be portable basically we'll push the zybo board to its limits until we need to upgrade next up the motor drivers although the zybo board will be controlling the motors it cannot generate the massive voltages and currents that the motors need to move that's where the motor drivers come in the motor driver is called odrive their brushless dc motor drivers capable of driving two motors up to 56 volts with a peak current of 120 amps per motor here are some of the specs on the board from the odrive website though drive boards have multiple modes in how to drive the motors for example though drive board can be set in position mode where a controller the zybo board in our case can send an angular position and it'll go there or o drive can be set in rc mode where you send it a pwm signal from the zybo board to tell it what angular position to go to the drive board is capable of a lot of other things as well the firmware is also open source so you can make changes to it if needed it seems odrive will make a great contribution for robodog being a diverse testing platform for trying out many different controlled designs and ideas odrive is also backed by a great community they have an online form and a discord server where you can ask questions you have about odrive i highly suggest them for future robotic projects and no i'm not sponsored by them or anything i just really like their products so back to the diagram you can see in the corners that i have four o drive boards each o drive will be driving two motors so that is eight hoverboard motors in total what i would actually like to do is drive 12 motors in total so looking at a rough 3d model i'd like two of these motors at the base of each leg right around here those two motors in this area would allow the whole leg to rotate in two ways one way would be outwards from the body like this here's a top view to give you a better perspective and the second way would be forwards and backwards like this the other four motors that aren't in the system diagram will be for the knee joints located here the movement this will give me is something like this so in total this would make the robodog have 12 degrees of freedom so you might be wondering why i'm not including the last four motors well this is where the zybo board starts running out of resources as you can see in this diagram it's already pretty busy and if i add more motors i'll start running out of inputs and outputs on the zybo board for all the motor control stuff but there's still a lot here we can develop and test before we need to start worrying about electronics and software support for these four additional motors moving on the next thing in the diagram is the hall effect sensors that come with the hoverboard motor these hall effect sensors serve as an encoder for the motor an encoder is just a sensor device that gives you information about the motor's position as it spins knowing the position of the motor is important for robotics because you often need to know what the motor position is to accurately control the robot's arms and legs encoders like the hall effect sensors can be plugged into the o drive board so that odrive can set the position directly the controller just needs to send what position to go to we'll talk more about position control here in a second first we need to figure out what the resolution is for these built-in hoverboard motor encoders the resolution of an encoder is the minimum amount of degrees the motor can turn before we can tell the difference with the encoder and unfortunately these hoverboard motors didn't come with a spec sheet that shows us the encoder resolution so let's open it up and try to figure it out ourselves inside of the hoverboard motor you can kind of see the blue wires coming out of the hall effect sensors located here here and here the only thing the hall effect sensors do is read the magnetic field of the magnets each magnet has either north pole of the magnet facing the sensor colored in red or the south pole facing the sensor colored in blue i also placed three white lines extending out from the hall effect sensor so you can see which magnet they're pointing at so for this test let's assume getting a one from a hall effect sensor means it's over the north pole and zero if it's over the south as i turn the motor let's see how many unique states i can get out of the hall effect sensors reading left to right we have 1 0 1 0 0 1 0 1 1 0 1 0 1 1 0 one zero zero and now we start repeating with one zero one so we'll ignore that repeating state so with that it looks like we have six unique states for these unique states each hall effect sensor was measured across a total of two magnets with motor spinning across two magnets giving us six unique states that means for all 30 magnets in the motor there are 90 states that we can get out of the encoder for one full revolution okay great we now know that for 360 degrees of rotation we have 90 states within those 360 degrees that we can sense with the hall effect sensors that equals 4 degrees per state change or pulse of the encoder wait a second 4 degrees per pulse that's awful normally you'd expect 10 24 or even 40 96 pulses per revolution for robotics applications which is about 0.35 and 0.08 degrees per state change of the encoder so what can we do about this well let's add a higher resolution encoder this is an as5048a here are some brief specs for the encoder you can find more info from the vendor's website it has a 14-bit resolution which means there's 2 to the 14 or 16 384 pulses per revolution that's roughly 0.02 degrees per pulse now that's more like it coincidentally these encoders work by sensing the magnetic fields like the hall effect sensors in the hoverboard motor but unlike the hall effect sensors that just detect if a north or south pole of a magnet is present these encoders measure the direction of a magnetic field essentially it works by hovering a magnet over the encoder as the magnet turns the encoder senses that movement the encoder can't work which is any magnet though it must be a diametrically magnetized magnet this means that the north and south poles must be split down the middle through its diameter like it's shown in the picture another noteworthy thing here is that this is an absolute encoder and not an incremental encoder like the hall effect sensors remember when i said the hall effect sensors could give me six unique states per two magnets before it started repeating this makes it impossible to tell at what angle the motor is at when i just boot up the system for example let's say i just booted up the system and it read a101 from the hall effect sensors how would i know if it's this one zero one or this one zero one it's impossible to tell so if you only have an incremental encoder what you have to do is have some sort of homing indication like a limit switch to tell your program that a specific state like one zero one is zero degrees and that it's this one zero one that you wanna start counting from as the wheel starts to spin you can now keep track of the count so with the absolute encoder we will be using there are 16 384 unique states that the sensor can give us that spans across one full revolution and that's the beauty of absolute encoders right when you turn on the system you'll know exactly what angle the wheel is in another reason i'm choosing these absolute encoders is that they are mostly compatible with odrive i say mostly because from what i read it seems like you need to flash different firmware on odrive to support it it's not natively supported because absolute encoders are a bit harder to communicate with since different absolute encoders use different hardware and software protocols to communicate with them regardless there seems to be some support for this encoder within the odrive community which is nice because this means that we have options however i don't plan on initially using these encoders for odrive i actually want to feed the absolute encoder values into the zybo board my hope is that i can get more fine-grained control over the motors with the fpga on the zybo board where the roll of the o-drives would become more of a status and management system for the motors as well as providing the proper voltages and currents to them to facilitate driving the proper phased signals from the fpga to the hoverboard motors through the odred boards i may have to modify the firmware or even the pcb itself but regardless it's nice to have an advanced motor controller like odrive already implemented in the system because it will make the development testing a lot easier and who knows maybe i might end up moving more of the motor control from the zybo board to the o drives than i'm originally thinking we'll see how it goes when i get further along in testing so let's focus on the wiring of this diagram a little closer you can see that there is one absolute encoder for each motor the communication these encoders use is the spy protocol which stands for serial peripheral interface i won't go into the gory details of how spy works because there's hundreds of online tutorials for that but at a surface level it's a bus type protocol which means i can connect various signals from the encoders together and just tie that signal to the zybo board let me show you what i mean here's a serial clock signal notice how they are all tied together this is great because this means i don't need to spare eight separate clock outputs from the zybo board same goes for the controller output peripheral in and controller in peripheral output data lines where the controller is a zybo board and the peripheral is the encoder now time to make it a little bit more messy the last signal for the spy protocol is the chip select line so for this signal we actually do need a signal per encoder this is because for the spy protocol the controller needs to pull the specific chip select line to ground depending on which encoder the controller wants to talk to having most of these signals on the same bus is nice because they reduce the amount of wires you need but depending on your application it can come at a price though when the zybo board queries the position values from the encoders all the data from the controllers will be going out through the copie line and all the position data from the encoders will be coming in through the keyboard line this could result in some lag in the controller getting the data but this shouldn't be an issue for us though the fpga clock speed is upwards of 100 megahertz and the maximum sampling rate from the encoders is only 12.4 kilohertz also it's not like i'll be moving the legs of the robot dog at rocket speed so i don't need to query the position values as fast as the encoder can give me so we should be fine here so next up the pwm signals pwm is pulsed with modulation and it's a type of signal that can be sent from the zybo board to the o-drive board to control the motors under normal circumstances you would usually use usb to communicate to the o drive boards and i can certainly do this in fact i'll use usb and a usb hub initially to verify the motors are working by sending position values from the processor side of the zybo board but sending signals like pwm can be facilitated easier on the fpga rather than sending usb from the fpga so i think pwm is what i'll try to strive for like i mentioned before i want to have finer grain control over the motors i'm not sure if this will be in the form of me sending a pwm signal from the fpga to o drive so that the o drive can control the phase signals directly or if i could generate the phase signals directly from the fpga region to send to o drive's amplification circuitry both cases seem to be somewhat outside of normal use cases and would probably require me to rewrite some of the open source o-drive firmware at a minimum to tailor-fit what i would need next up in the diagram is the hall effect sensors connected to the o-drive boards although we discovered these encoders were pretty low resolution coming in at about 4 degrees per pulse they still could be useful for debugging and development although i want to have the absolute encoder values go to the zybo board i will probably initially wire up the absolute encoders to the o drive boards just to see how smoothly the motors can be controlled and also to give me a baseline for what to strive for when implementing more of the motor control into the fpga the last thing i have left is the power required to drive the entire system now i don't have the power completely defined yet but generally i plan on going with 18 650 lithium ion cells along with a battery management system that can load balance all the cells i also wanted to get a power management unit that allows me to turn on and off the power remotely as well as distribute the proper voltages and currents to the rest of the system the voltage rails that i would need to produce for all the electronics that you see in this diagram would just be a 5 volt rail for the zybo board encoders and the o-drive boards microcontrollers as well as a 36-volt rail to control the motors through the o-drive boards and of course let's not forget ground as i said my power system is still not fully defined yet so i'm not sure what power management unit i should get or how many lithium ion cells to get it would also be nice to have a power umbilical cord that can feed into the power management unit instead of the batteries so that during testing i can have a constant power source instead of needing to recharge the batteries all the time but i'll research that stuff a little bit more later and put in another video so this is it this is the system diagram so far now that i know what my system will generally look like i can start doing some rough 3d modeling for how these pieces are going to fit together some final thoughts and concerns i have before in this video as i mentioned before the system diagram only shows eight of the 12 motors i plan on eventually having still though if i can get the majority of the system working with only eight motors adding four additional motors shouldn't be too bad i'm also a little bit concerned about the brushless motors themselves being able to make small changes in position even though i plan on using a higher resolution encoder and will be trying to control the motors at as low of a level as possible with the fpga i still may not be able to move it in the small increments i want because of how wide the magnets in the motor are spaced out from one another this is where i think it may be useful to have that low level motor control where i can control the phase signals directly from the fpga to drive the motor though drive is more or less a black box and having control over the face signals directly will give me the ability to make the motion a bit smoother i'm hoping when spinning the motor slowly lastly i'm concerned with how i'm going to mount the diametrically magnetized magnet for the absolute encoder if the magnet becomes off-center from the encoder due to the warping or flex of the leg my position values for the motor may skew over time so i'll have to be careful about that also need to make sure that the encoder isn't in a place where the brushless motors can induce a magnetic field on the encoder and bias the sensor's readings anyways that's all i have for this video if you like the content so far and want to see more of this type of stuff or you think there's something i can do better please let me know in the comments below 96 of people who watch this content are not subscribed so if you enjoy what you're seeing please subscribe it really helps me out and allows the channel to grow thank you all for staying till the end and i'll see you all in the next one

Channel: AustinTronics

Views: 76,244

Keywords: robot dog, robot, artificial intelligence, Robotics, Quadruped, boston dynamics, Hoverboard, direct drive, FPGA, Zynq, APSoC

Id: _VUtfK4bCl8

Length: 20min 21sec (1221 seconds)

Published: Thu Jan 21 2021