I have been building a full size biped walking robot. You can see it in action on my YouTube channel here
I would love it if you guys can help me out if you see something I should be doing differently let me know.
One of the problems is the mess of USB cables and USB splinters that I need to communicate with all the Odrives. Let me know what you think the best low latency, high band solution would be to solve this issue thanks
Enjoy the video I will make more in the future
Yes CAN is able to handle 12 motors. Regarding the transmission speed: You can configure CAN to run at up to 1 mbps. This should be enough for you. You will also need to think about how to connect the CAN bus to your PC. I did this by using an Arduino and rosserial.
Thanks for the Info. Can I get example code for the Arduino using CAN bus for communicating with the ODrive? To be honest I’m jest being lazy and it would be faster to learn from some already working code.
Great project! I look forward to the next video. I also recommend CAN, however you may wish to consider having two CAN bus’s (see below on NODE ID restrictions). One per leg probably makes sense.
Take a look at MIT’s mini cheetah communication architecture, it may be useful for your application.
Any idea for the CG state estimation for your future balance algorithm?
I’m going to take a different approach in how I’m going to tackle the problem of balancing and walking by using Motion Matching and feeding the error back into the Motion Matching system. I don’t know if it would work but it should be interesting. I’ll make another video about it when I’m done.
Very honest with why things don’t work with the design and showing how it operates at this point. This will be a good video to come back to once you have it all working .
Thanks, I think most people had way to high expectations and underestimate how long it will take. But as long as people are patient with me and I can get all the problems with the Odrives fixed, I will keep working on it. Right now 2 of the Odrives stopped working for some reason ERROR_DRV_FAULT. It’s frustrating.
ERROR_DRV_FAULT is a low-level (electronics) fault and should be a pretty unusual error… It means the DRV8301 gate driver chip has gone into lockout. Do you have v3.6, or do you have an earlier version of the board?
IIRC this can be caused by a bad ground or power supply noise on the DRV8301 chip itself. Did you try lowering current_control_bandwidth as suggested in the Hoverboard guide?
Do you have anything else connected to the battery that could be causing a ground loop?
You could perhaps try bonding the -ve side of the battery to your chassis (oh no wait you’re the guy using a plexiglass chassis-) You may want to ground your motors with ground wires or shielded cable instead. You could use twisted or ideally shielded motor wires, with the shield connected to the -ve battery as well as the iron stator of the motors.
What voltage are you running on? It could be an undervoltage condition, potentially.
BTW, Are you using digital protractors for position feedback??
Oh, I just had a read through a few previous posts and they seem to suggest PSU problems or the Brake resistor not connected, where the MOSFET has a latched protection nFAULT which can go away by quickly grounding the EN_GATE pin, although I wouldn’t try anything like this without first writing a support post to one of the guru’s.
Has your brake resistor become detached or gone open circuit. I was a little worried about the screw terminals for these high current devices, especially on moving platforms, hence why I have now soldered them directly to the board.
Here’s a bit on the EN_GATE: -
When the EN_GATE pin goes low to high, it will go through a power-up sequence, and enable gate driver, current amplifiers, charge pump, internal regulator, and so forth and reset all latched faults related to gate driver block. The EN_GATE will also reset status registers in the SPI table. All latched faults can be reset when EN_GATE is toggled after an error event unless the fault is still present.
Hope that helps.
I just spotted that you said 2 ODrives, probably PSU as towen mentioned above.
How’s your ground wiring between the two ODrives and the battery? (I assume you’re using a battery, not an external power supply?)
How about any external communications? If there are any wires to the outside world, you should also include a heavy ground connection between -ve battery and mains earth. Otherwise you will get current flowing through the USB or CAN ground wire, which you don’t want.
Thanks for the help. I have a common ground with all of the Odrives by connecting the ground pin on all the boards together. (I haven’t connected anything with the (-) of the battery, I’ll try that)
I’m using the 56v 3.6 at the time I was running it on 24v when I’m testing
The break resistor is soldered and the connection is tested.
I will also lower current_control_bandwidth.
It sounds like it was a bonding issue, I will definitely check everything and do a better job at that but first I need to reset the error.
How do I “grounding the EN_GATE pin” to reset the error. I can’t find the EN_GATE pin, or am I blind?
I am using a CUI AMT102 capacitive encoder. 8196 CPR resolution for position feedback on all the motors.
it’s pin 16 on the DRV8301, although I would exhaust all other avenues first, then if still required put in a support request with advice from @Wetmelon or @madcowswe . I should imagine this pin is connected to other ODrive components and may cause other issues if not done correctly, it may even be a command to the ODrive, although I am stabbing in the dark with this one as I have only just looked into it.
I think there are a couple of things you can do to get further wth your project
you are using the wrong software - you need a robot simulator - have a look at webots that will allow you to program directly in python rather than all the messing about with blender and sockets… I have developed a walking quadruped in this way… as im a new poster I can only send 2 links with my post - search sujitvasanth on youtube and my quadruped and webots simulator demo will come up.
use belt pullies as opposed to ball-screws see the development of JamesBrutons Xrobots series he tried ball screws and found they were too heavy and rigid and also its silly to rotate the motors which are heavy (!) see these 2 videos
Thanks for the advice.
I agree that ball screws have their problems but I thought it would be easier for my first robot to learn from. My second design will be a lot better.
I’m building the controller in unity because it gives me easy access to IK, motion matching, blending animations, vitalize state machine and the use of VR positional trackers.
The big thing that I want to try out is Motion matching and positional trackers and I don’t believe I can do that with Webots or ROS. I could be wrong about using Unity but I think it’s worth a try.
.
.