Close
0%
0%

TipTap

A 3d-printed bipedal robot.
A desktop option for semi-direct drive walking research.

Public Chat
Similar projects worth following
A sub $500 open source walking robot that can be used to test out control algorithms and simulation fidelity using semi-direct drive torque control.

BLDC motor controller (DizzyServo from dizzy.ai) manufacturing details: https://github.com/DarrenLevine/DirectServo

The platform is built upon a custom modular 3d-printed actuator, with a 8:1 planetary gearbox. The dimensions are 47mm x 47mm x 47mm, and the cost is about $74 per actuator. The BLDC controller board it uses is the DrizzyServo from dizzy.ai.

I also built a 2D Port-Hamiltonian and then later a 3D Featherstone simulation frameworks in MATLAB, in order to teach myself the low-level math/physics. Here are a couple simple heuristic based balancing controllers:

My design goals:

EndeffectorTorqueHoming.gif

Example of 0-gravity end-effector torque control

Graphics Interchange Format - 2.79 MB - 01/05/2019 at 16:46

Preview
Download

Towards More Agile and Inexpensive Robotics 1_28_2018.pptx

A presentation about why I think this is an interesting project.

presentation - 28.63 MB - 01/05/2019 at 16:45

Download

  • 1 × BeagleBone Blue
  • 4 × DirectServo https://www.dizzy.ai/documentation/motor-driver/
  • 2 × uxcell 304 Stainless Steel Dowel Pin 3mmx40mm
  • 2 × uxcell 304 Stainless Steel Dowel Pin 3mmx30mm
  • 2 × uxcell 304 Stainless Steel Dowel Pin 3mmx18mm

View all 13 components

  • Writing Code

    Darren V Levine10/06/2019 at 20:00 0 comments

    Hi Everyone,

    This is what the robot looks like now!

    In the last couple months I had to redesign TipTap's beaglebone blue backpack, due to the integrated RS485 to uart converter chips continuously burning out, and in general being unreliable. I tried several other converter chips but had trouble finding another reliable and cheap option. In the end I had to move to a larger form factor by integrating a "JBtek USB to RS485 Converter Adapter ch340T" (the large black usb stick now on the back of the robot), which works very reliably, and as an additional plus lets me plug in the converter to any computer to test the motors very easily since it's just a usb stick.

    After that resign, I ran into software and networking difficulties using the beaglebone's integrated solutions. Eventually I moved to a setup where I SSH into the board via VSCode over wifi, which works like a charm and has really sped up my software development workflow.

    The power mangament also let to some difficulties, the servo rail is only connected to the lipo battery input terminal on the beaglebone, so I needed to "fake" a lipo input instead of being able to use the standard power connector on the beaglebone. To do this I take the 24v power supply and pass it through a buck converter down to 8v which powers the servo rail and beaglebone, unfortunately, the lipo terminal has a battery management circuit integrated into it which will interpret the slow ramp-on of the buck converter as a bad battery and prevent further current draw (preventing the beaglebone from turning on). As a workaround I'm plugging the power in, waiting for the buck converter to stabilize, and then plugging in the buck converter into the beaglebone. I'll do this until I can come up with a compact power-on-delay circuit that does this automatically (as long as it doesn't impact my < $500 robot goal).

    Most recently I've been dealing with a latency issue with reading the IMU's DMP fused quaternion data. So, for the moment I've resorted to using just the accelerometer data, which has negligible latency. Which finally let me test out some simple control routines while tethered.

    The code that created the behavior in the above video isn't very complicated, it's just a PID loop position to torque controller tuned to make the legs really springy and compliant. I'm using weighted averaging as a low pass filter on the accelerometer data, and fed all that data in as simple heristic proportional gains, all manually tuned at the moment (I'm just using this to test the hardware / compute performance, later on I'll move to more advanced control schemes). Here's the python script:

    from tiptap import *
    
    CustomCal = [-223.67956054016938, -493.2387273975738, 93.62142366674297, 778.4646372167543]
    Controller = PIDloop(InCalibration=CustomCal,TorqueLimit=0.4)
    
    avg_zaccel = 0.
    avg_xaccel = 0.
    avgz_ratio = 0.4
    avgz_inv_ratio = 1 - avgz_ratio
    avgx_ratio = 0.8
    avgx_inv_ratio = 1 - avgx_ratio
    while True:
        accl = mpu9250.read_accel_data()
        avg_zaccel = avg_zaccel*avgz_ratio + accl[2]*avgz_inv_ratio
        avg_xaccel = avg_xaccel*avgx_ratio + accl[0]*avgx_inv_ratio
        Roll = -avg_xaccel*7
        Rtheta1,Rtheta2,Ltheta1,Ltheta2 = gla.GetLegAngles(-avg_zaccel*0.15 + 3*np.pi/180 + np.pi/2, np.mod(int(time.time()/0.3),2)*2-1)
        RightLegServoDeg(-2 + (Roll>0)*Roll)
        LeftLegServoDeg(-2 - (Roll<0)*Roll)
        Controller.Apply([Rtheta1*180/np.pi, (-Rtheta1-Rtheta2)*180/np.pi, -Ltheta1*180/np.pi, (Ltheta1+Ltheta2)*180/np.pi])
    
    ExitProgram() # shuts down motors and cleans up signal handlers

  • Finalizing the Motor Driver and Hardware

    Darren V Levine08/18/2019 at 22:35 0 comments

    Before I get started, I wanted to give a shout out to Misha at dizzy.ai, most of the progress in this post is due to finally narrowing down to a torque controller that fit this application's needs. Specifically, I used four of his absolutely fantastic DirectServo designs. I tried a few different ESCs that could do torque control, however most were either too expensive, or too large to reasonably integrate into TipTap. ODriive was my favorite as far as software goes, and I learned a lot from playing with their firmware, but in the end it was too expensive and large for this application. The DirectServo ended up being the perfect combination of easy to use and high performance that I needed for this application.

    Once I decided to go with the DirectServo ,  I redesigned both the gearbox and motor enclosure to make it modular and to solve some persistent mechanical issues. Mainly that the load path through the gearbox could only withstand loads that didn't apply off-axis torques (leading to exploding gearboxes :( ), and that getting smooth predictable movement with the imprecise 3d printing of gear teeth was a continuous challenge.  Moving to a Herringbone gear pattern solved the printing smoothness/yield problem, it turns out the pattern is much more forgiving with printing defects than the typical spur gear pattern. For the load path issue, I finally broke down and added 6705 Thin Section Ball Bearings (25x32x4) under the hood of each gearbox to redirect the load. The bearings are more expensive than I'd like at $15, but the final gearbox is incredibly robust as a result. Another benefit of adding the bearing was that I no longer needed an extra supporting enclosure on the outside of the gearbox. Here is a picture of the cross section of the new design:

    The final cost for one of these 3d printed torque controlled gimbal motors is about $74 . That's $15 for the bearing + $38 for the DirectServo + $18 for the gimbal motor + $1 for the encoder magnet + ~$2 in fasteners and  filament.

    The dimensions are 47mm x 47mm x 47mm.

    I also redesigned the legs, so that they were supported on both sides of the pulley all the way to the feet, which got rid of the last bit of backlash/flexure I was experiencing.

    For the torso, the previous design had a large moment arm on the servos which created too large of a torque for the servos, and so in an effort to make the hip's side-to-side pivot point closer to the front-back rotation point (reducing the forces on the hip), I redesigned that as well.

    First by trying a double pivoting linkage design, as seen here:

    However, as you can see, that resulted in a lot of backlash and therefore vibration. The linkages also added complexity, and because the servos were located between the legs, it forced the legs to move apart, which is not ideal for a walking gate. So I removed them in favor of a more rigid direct servo mount design on the back of the robot:

    As well as reinforced the centerpiece and beaglebone mounting plate, essentially combining them and making the center more tube-like to reduce the torsional flexure I was seeing. You can see the final design here:

    All in all, I've very happy with how rigid and durable everything turned out, and especially with how quickly the legs can move as well as their torque when given 24 volts.

    My work going forward will be in setting up a testing apparatus and working on software to make it walk/jump/move. Eventually I would also like to print some clear and thin plastic protective shells to cover the moving parts and protect against falls.

    That's it for now. Thanks for looking!

  • Initial Work and Reducing lashing in leg/hip

    Darren V Levine02/09/2019 at 23:59 0 comments

    Initial Work:

    Log update: 01/05/2019


    As a first step I built a Port-Hamiltonian simulation framework in MATLAB, in order to teach myself the low-level math/physics. It turned out to be extremely slow, and so I could only use it for 2D sims. Here is my first attempt at a low-cost heuristic based stabilization controller (very Monty-Python-esc I know).

    More recently I've moved to an articulated body Featherstone simulation framework in MATLAB. Here is another even simpler heuristic based control scheme:

    Eventually I'll work on efficiency and stability, but for now this does have the advantage of being naively extensible to arbitrary N-Jointed x N-Limbs without a training period. My next steps are to progress more on the hardware end in order to test any controllers on actual hardware.

    On the hardware end, I made many many early mistakes, including under-sizing motors and components. I created a small 3d-Printable 9:1 planetary gearbox that overlays each motor which fixed that issue:

    Here is a video of an early prototype leg:

    The cable design turned out to be very difficult to work with and produced unnecessary strain on the motor housing, so I moved to a belt/gear design even though it adds weight. The 9:1 planetary 3d-printed gears also needed a redesign to produce better printer yields. The next iteration included more robust components, though it was far from a final design. Producing such small parts in order to try and conserve weight and size means I'm always finding new bottlenecks that need to be fixed.


    Reducing lashing in leg/hip:

    Log update: 02/09/2019


    I updated the leg design with slightly thicker limbs and added a supportive bar on the external femur. The extra bar allows the belt to be tightened down significantly more, reducing play to a much more acceptable level. Here's a picture of the new leg all assembled and instrumented:

    Other progress:

    I'm did some more work to improve yield issues with the very small planetary gears on each motor (the teeth are the width of my printer's nozzle), in particular upgrading my 3D printer's firmware last weekend helped a bit. Although it is time consuming, a few more iterative tweaks are probably in order. Not having to resort to metal gears will be a huge cost/time saver in the final product.

    I'm using 333 degree potentiometers on each joint instead of encoders to significantly reduce cost and size. They produce a single analog signal that needs ADC sampling and kalman filtering (due to reduced performance in vibration). At the moment, I'm doing that in software on the beaglebone (located on the back of the robot), which works decently well. So, I'm hopeful this cut-corner will work out. However, I'll now need to either convert that signal to one compatible with the Odrive's discrete encoder inputs, or modify the Odrive's firmware to do the job. Still more tinkering to do on that front.

    As for the idea of building my own motor controller, after looking at the various resources and designs available such as Ben Katz's: http://dspace.mit.edu/handle/1721.1/118671#files-area, I'm both more excited about making a custom board, and more aware of how large of an endeavor it would be ( VESC (Best Open Source ESC) || DIY or Buy). So, I'll likely do it as a separate project once I'm happy with TipTap's base model platform.

    That's it for now. Thanks for looking!

View all 3 project logs

Enjoy this project?

Share

Discussions

ParadoxRobotics wrote 10/06/2019 at 20:03 point

Hi,

I am currently working on a RHEX-like quadruped robot using quasi-direct drive BLDC actuator, and I am really impressed by your work !

Is it possible to know the gear configuration of your planetary gearbox ? (mine is a 8:1 planetary gearbox; sun = 12T, planet = 42T and ring = 96T with Module = 0.8 and pressure angle = 20°) or is it possible to have access to the STL or CAD files of your actuator ?

  Are you sure? yes | no

Andrey V wrote 08/30/2019 at 12:31 point

Impressive design. Only thing I can recommend - to use Trinamic products for BLDC motor control. I used both, stm32 with their BLDC library and Trinamic products in my projects. Trinamic is the best imo.

  Are you sure? yes | no

Darren V Levine wrote 08/31/2019 at 15:35 point

Unfortunately they're a bit out of my price range for a <$500 robot goal, but thanks for the recommendation. The DizzyServo ended up being only $38 a piece even paying for an assembly house instead of making them myself, so I ended up going with that, and it works well so far for torque controlled applications.

  Are you sure? yes | no

Andrey V wrote 09/03/2019 at 04:20 point

I understand) But get ready to do a lot of work to tune all parameters in FOC SDK. Hopefully, STMicroelectronics engineers made some videos, which may help you. https://youtu.be/As6cLKZzHyA

And good luck! Because it's very complicated project from the initial design to the control algorithms. 

  Are you sure? yes | no

de∫hipu wrote 08/18/2019 at 22:43 point

Hmm, the brochure says "4-DOF legs", but you only have three degrees of freedom? Two motors and one servo? Or am I missing something?

  Are you sure? yes | no

Darren V Levine wrote 08/18/2019 at 22:53 point

Yup, 2 + 1 is correct. That's just poor wording on my part. There are 4 gimbal motors for torque control + 2 servos on the hips, so 6 DOF total.

  Are you sure? yes | no

de∫hipu wrote 08/18/2019 at 23:04 point

Makes sense, thanks!

  Are you sure? yes | no

David Gedney wrote 08/10/2019 at 02:50 point

Wow! Best of luck getting it to walk!

  Are you sure? yes | no

katayoun.hatefi wrote 08/08/2019 at 19:37 point

hi  is it possible to upload the code for jumping robot ? thanks in advance 

  Are you sure? yes | no

Chris wrote 02/13/2019 at 04:40 point

Those gears are very nice! What material are you printing in / what size nozzle?

  Are you sure? yes | no

Darren V Levine wrote 02/15/2019 at 07:51 point

Thanks! They're PLA. I'm using a lulzbot mini with a 0.5mm nozzle, I've been able to get about half of that at the tips on the gear teeth fairly reliably after adding some belt tighteners to the printer. Smaller than that and I end up needing to take too much time filing down the defects to get smoothly working gears, which is too bad because smaller teeth would allow me to fit more teeth on the smaller sun gear, and that would help a few operational aspects.

  Are you sure? yes | no

Asher Gomez wrote 01/09/2019 at 18:08 point

Nice project!

  Are you sure? yes | no

TTN wrote 01/09/2019 at 10:45 point

Any chance you'll post the files for this bad boy? You've done an incredible job of the CAD work. Looks fantastic but also very functional. I'm tempted to print one because it looks so awesome. I better not get sucked into trying to code it up to walk or balance! ;-)

  Are you sure? yes | no

Darren V Levine wrote 01/11/2019 at 17:52 point

Thanks! I will be posting files. But after I've done more design iterations/testing. The current printed prototype has a few flaws that I'd like to fix before releasing it to the public. Namely I need to design in more pre-loading into rolling direction of the legs, because right now flexure in the leg assembly lets the foot's end-effector travel an unacceptable 3/4 of an inch in the roll direction, though I am quite happy with the deflection in the pitch direction. I also need to finalize the motor driver design and account for that volume in the torso design, which isn't done at the moment.

  Are you sure? yes | no

Jarrett wrote 01/07/2019 at 17:28 point

Also, what BLDC motors are you using?

I've got some teeny tiny ones I'd like to using along with a cycloidal gearbox, but I don't have a good intuitive feel for torque numbers and how they "feel" in the real world.

  Are you sure? yes | no

Darren V Levine wrote 01/11/2019 at 17:44 point

Neither do I unfortunately. I ended up doing some lever arm calculations according to the size of my robot's limbs and an estimated final weight (with a factor of safety of only 1.5 because it's difficult to go higher). I then did some searching for BLDC motors that met those specs, unfortunately suppliers don't seem to always list torques, and there are plenty of high end options that would blow my budget (usually when an encoder is packaged into the motor), so I eventually settled on a "IPOWER MOTOR GBM3506-130T". Since while their 1.5KG/cm torque isn't good enough for crazy stuff like backflips, it is good enough for walking and at only $18 a pop, helps keeps the entire assembly under my price target. I'll of course be testing their torque claim with my ODrive, and potentially selecting another motor if the results don't live up to their spec'd torque.

  Are you sure? yes | no

Jarrett wrote 01/07/2019 at 17:21 point

Watching this one closely, something similar has been on my "to-do" list for years!

  Are you sure? yes | no

Darren V Levine wrote 01/07/2019 at 00:57 point

Thanks! I hadn't seen any of those! Though the reference material Gabriel Levine just posted on his walker's ( https://hackaday.io/project/160882-blackbird-bipedal-robot ) project page has the under-actuated stuff in lecture-form it looks like. All this new material will keep me busy for a while!

I especially like the drake work. That's one of the things I'm really excited about, for this project. If I can make the hardware fairly reliable, and really cheap/accessible, then it should be fairly easy for the Drake team or anyone else to implement their work on my hardware. I would like to eventually get a few different controls schemes loaded onto the same robot to do comparison videos even.

Also, best of luck with your company! If you do eventually decide to work on developing a small version of the Odrive, do let me know, I would be an eager customer of something small with torque control and torque sensing. I agree about Odrive being overkill for a lot of smaller applications (even though I'm a huge fan of what they've accomplished).

https://hackaday.io/project/157586-powerful-brushless-dc-motor-drivercontroller is a wonderful project that takes a step in the right direction I think of giving out generic design diagrams, but the hurdle of using these pdf designs to customize -> source-parts -> layout-pcb -> manufacture a prototype board, means it just won’t reach as many people as something so accessible like ODrive. Sorry to hear your last attempts at humanoids didn't work out. I'm attempting to make all my mistakes on the small/cheap end of things, though now I'm discovering miniaturization has its own set of challenges :/

  Are you sure? yes | no

Gabrael Levine wrote 01/07/2019 at 04:09 point

Ben Katz did a great job designing a miniature brushless servo controller: http://dspace.mit.edu/handle/1721.1/118671#files-area

He published the design files, so I'd recommend starting there if you want to make a small driver board. They're using it in the in the Mini Cheetah and the Little Hermes biped (http://web.mit.edu/jlramos/www/LilHERMES_Robot.html), which is about the same size as your robot. 

  Are you sure? yes | no

anton.fosselius wrote 01/05/2019 at 07:16 point

Are you planning to share your files? Would love to contribute/help where possible.

Take a look at https://studywolf.wordpress.com

For control material ;)

Also look at :

http://gazebosim.org

For simulation.

Odrive supports 2 motors, so i guess you would need 2x odrives, what CPU/control boards are you looking at?

  Are you sure? yes | no

Darren V Levine wrote 01/05/2019 at 16:55 point

Thanks for the resources! I actually found this nice paper on different simulation tools when I started: https://arxiv.org/pdf/1402.7050.pdf , I ended up trying gazebo, but didn't like how little insight as to the mathematics it gave me, so I figured that by coding up my own, it would help me learn. Plus now I can re-code any portion of my matlab code into c easily for the final control software to make it lighter weight and run faster on my embedded system. Unfortunately as a side effect, my software is much slower, and has fewer features than something like Gazebo, but I think I've personally gained in that trade-off in mathematical intuition. Studywolf does mostly non-floating body, so I've found some of his work hard to translate, but I love how great he is at explaining things, and I hadn't read that particular post thanks! I did build upon his posts to develop my end-effector torque controller: (see the "EndeffectorTorqueHoming.gif" project file for an example).

I've been meaning to get into training schemes eventually, Berkeley's robotics lab has some absolutely fantastic papers that I've been reading: http://rail.eecs.berkeley.edu/code.html in regard to that sort of thing. I made a presentation about the need for robust learning schemes, heavily based on Sergey Levine's work awhile back (see the "Towards More Agile and Inexpensive Robotics 1_28_2018.pptx"  project file).

Yup, 2 Odrives will be needed if I go that route, though I'm hoping to find a smaller/cheaper alternative, since that would be the difference between a $300  robot and a $500 robot and quite a bit of bulk. Unfortunately my weakest area is circuit design, and so designing my own purpose built board for that may not be feasible in the near future, even though I would like to learn how.

The current control board enclosed on the robot in the pictures is a "beaglebone blue", fairly cheap, and has all the sensors/IOs/processing-speed I need for control and state estimation.

As for collaboration, I'd love to! Though all my work is in a very unfinished/non-production state at the moment (and I don't always have that much free time to work on this), so I was planning on releasing files once they would be more useful to a larger audience. If you have any ideas for collaborations just let me know :)

  Are you sure? yes | no

anton.fosselius wrote 01/06/2019 at 08:55 point

have you seen https://projectchrono.org

I just recently got notified about it. saw that it was not included in the paper.

I just quit my job on an IoT/GPS tracking company and are starting on a RnD electronics company, will work with electronics, ASIC/FPGA and firmware development. developing a motor control board for small bipeds are quite high on my todo list. I find Odrive/VESC to be overkill for smaller robots, have been looking on some Quadrocopter control boards but not yet found something that fits my needs.

My longtime goal have been to develop a full size humanoid for less then 1000$ initial inspiration was CHARLI and then Cassie. But have so far only produced 3 biological bipeds that turns out to be a real timesink, and way out of budget  ;)

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates