Thank you Chad, I appreciate the kind words!

I'm 3D printing some prototype parts for the next video as I type this comment.

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

Thank you man, I appreciate that!

Good idea, thank you!

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.

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.

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.

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.)

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

Thank you for the insight! And yes, I am looking into CAN bus currently, there seems to be a lot of benefits to it.

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.

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

I have! Super long time ago though.

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.

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.

Sure, I don't see why not.

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

You got it! Next video should be out soon!

We just sad BTTF didn't happen

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

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.

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: kzfaq.info/get/bejne/jchhmtZ7mbGYoIE.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: kzfaq.info/get/bejne/iNF-mrWWnb6YmY0.html

Newtons are a measure of weight, you may be confusing mass and weight.

@@execration_texts Oh. Thanks, didnt know that

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.

I agree, metric > imperial.