Inexpensive 3D Printed Full Size Humanoid Robot

I'm designing a super cheap humanoid robot platform. It is going to be the same size as an adult person.

Similar projects worth following
An ambitious project to design and build a full scale humanoid robot - but within the cost range of the average person. Most full size humanoids are far beyond affordable. I aim to design a robot that can be bought for under £800. I am doing this by designing from the ground up with the cheapest components.
I am using Arduino mega 2560 clones for the main motor controllers. Each joint uses cheap plastic hobby gearboxes rather than servos or steppers. I have spent under £100 on the components for the legs so far.
I have programmed a basic P*I type control on the arduino. Arduino receives commands from a basic GUI that I programmed in Processing. I have the legs, waist and part of an arm built. I still need to design the upper body but I have a good idea of how it will work. I would love to work on this full time, but can't.

As with all of my work, I am designing this to be made from the cheapest components possible. The idea is that I would be able to create a full size humanoid platform that can be purchased for under £800.  

Updated with extra video:

     All of the joints are made using cheap plastic gearboxes and position feedback is from potentiometers. I am only at the point of making the legs and programming the arduino to control them in a usable manner. I managed to get it to stand on one leg yesterday, but much more work is needed to get it balancing using any kind of responsive intelligence. It doesn't have any upper body weight so counterbalancing is quite difficult at the moment. I haven't actually designed the upper body yet, but I have a good idea of how I want it to work.

      I am planning to add gyro stabilisation and pressure sensors to the feet, although programming the responses to that data is going to be a real challenge and will probably take weeks.   

     All of the plastic parts are 3D printed and designed on sketchup. I am using L298 breakout boards you can get on ebay for the drivers, quite simply because of the time saving and cost factor. Each leg has 6 degrees of freedom and it can move in any way a human could conceivably move.

      I took some time to learn a bit of Processing which is helping with control of the legs. I wasted days and days learning how to send data between the arduino and PC using the serial bus. It was extremely painful! I had to break down 3 digit integers into individual characters to send in a String and then vice versa on the other end. I cracked that eventually.    

      I have programmed a simple GUI using Processing, which is designed to allow me to save positions down to a position array that can be played back when you click on the buttons. I just need to program a timed position sequencer and I will have the rudimentary basics of system that can control the legs into a basic walking movement.     Even when I have that, it still won't have any semblance of intelligent control. That could take months to program. I have some great ideas around programming control, but it seems that my programming skills may take some time to catch up with my ideas.   The only way I was able to make this progress is by taking time off work, but unfortunately I will be back at work on Monday, so progress will slow right down again.I would really love to be able to do this full time, I'm just not really sure how to get started.

  I am aiming to program everything through Processing on my laptop and then purchase a powerful 'on board' PC solution so that the processor can be located on the robot. I can then transfer the Processing files on to that.

   You can see some big gaps in the shins, this space is where I will house the batteries. I will use the high capacity hobby battery packs that are usually used for RC cars etc.

I am going to spend the next few days getting saved movements sequenced so that they play back in a way that will make the legs walk . I also going to install the giro and pressure sensors on the feet.

Please get in contact with me if you are a company interested in supporting this work. I have everything I need to carry on and make these units, but I just need time. For that I need to have some level of support.

Updates to follow.

JPEG Image - 3.92 MB - 08/08/2017 at 07:12


JPEG Image - 4.09 MB - 08/08/2017 at 07:12


Portable Network Graphics (PNG) - 31.59 kB - 07/26/2017 at 22:37


Portable Network Graphics (PNG) - 78.87 kB - 07/26/2017 at 22:37


JPEG Image - 6.31 MB - 07/26/2017 at 22:37


  • 12 × L298 Interface and IO ICs / Peripheral Drivers and Actuators
  • 1 × Mega 2560 Cloned Processor
  • 48 × Cheap 200:1 gearboxes

  • Really need a hand...... Pt1

    Dan DWRobotics08/26/2017 at 13:59 0 comments

    Well, thought I would share the progress with the hand. Hadn't really predicted quiet how complex a task it is to design a hand from scratch. It is still in its early stages of conception, but the design is starting to look pretty badass, so I thought I would share. What you can't see from the snapshot is that there are a ton of internal tunnels which allow the cabling to be run for transmission of motion from the motors in the forearm. These tunnels and the points at which the cables have to change angle or need to bend needs to be very carefully thought out, otherwise when you move the wrist the fingers would change position for instance. Nothing new there, although there are two cables for each finger, so that instead of a spring action pulling the fingers back to extension the action will be actively driven. Lots of hand designs I've seen use a spring mechanism to open the fingers but I want the fingers to be stable in both directions in case an action requires it.

    I'm close to printing now, but I know that there will be lots and lots of design revisions until the final version is realised. The angles and mechanisms are all estimated, I actually have no idea if they will work out. But from the first print I can test and make decisions based on what works and what needs changing.

  • Goofy Drawings and failed parts...

    Dan DWRobotics08/22/2017 at 21:20 6 comments

       I guess it is worth at least once showing the very basics of designing a completely new device. Often you can do this in your head. I do this, usually when I am supposed to be asleep but just can't get a particular problem out of my head. Or many times you can do this directly in your CAD program of choice. But sometimes, and in fact many times, the very starting point is

    ........................... the rubbish drawings.

          I have hundreds of these. Some I come back to again and again, to inform the later design process. Many times, there is no quicker way to decide which cables, cogs and axles are going where, than by just trying to draw it out on paper. So to break the monotony of actually designing the hand in sketchup, I thought I would take a break to share to the utterly ridiculous 'concept' drawings that eventually lead to solid printed items and the many rejected parts I have printed over the last couple of months.

  • Arm is starting to take shape

    Dan DWRobotics08/20/2017 at 20:04 0 comments

    So I have been working a huge amount on designing the arms.  I needed to make sure I get all of the articulation required but retaining some semblance of the human form factor. I decided I was not going to be able to have a five fingers but will have to go with two fingers and a thumb. My local print shop ran out of 3mm White PLA so I had to continue printing in 'natural' which I don't like as much, but never mind. Let me know if you can't see the video below, I forgot I had music on for this one so it is copywrited.

           The arm has a Yaw in both the upper arm and the lower arm. I had to design a new planetary gear for the lower arm yaw. I like it so much I will  probably redesign the upper arm to use this same yaw mechanism. I spent a lot of time debating whether I need a wrist 'pitch' and I have ultimately decided that I do need it as it is key to being able to pick things up and do other tasks in a human-like manner. So I now have a decent idea of how the hand will work and look but just need to design it. The hand is going to be designed to be strong enough to handle every day objects. I think if it can't crush a beer can, then it is not strong enough. Ultimately I want it to be able to pick up things like a drill or a shopping bag etc. It does look quite simplistic in design, but an incredible amount of thought has gone into the design to make this work.

    The fingers and wrist pitch will be 'cable pulled' like many other designs out there and I am planning to have one motor in the hand to pull the thumb inwards to the centre of the hand for grabbing. So the thumb will have two actuators to enable it to do what the human thumb does by either opposing  the fingers to pinch or keeping the thumb flat and making a kind of fist shape.

  • Humerus - Humourless more like.....

    Dan DWRobotics08/07/2017 at 21:58 4 comments

    So, no updates for a while. For a very good reason.

           I have been fighting with the design process. Really slogging away, forcing myself to endure days of staring at a screen making measurements and generally trying to animate the mechanics in my head. I had to create a whole new method of driving the joints, using cables instead of large cogs. This gives me the ability to make high ratio differences whilst maintaining the ability to make the parts printable. ( There is a minimum practical size to 3D printed gear teeth.)   

        This is specifically required for the upper arm Yaw mechanism which needs to be small form factor but high power and relatively low speed. I have gone through about 50 iterations of this mechanism, each time having to wait hours whilst my parts print.

       Each time I change the design I also need to redesign how I am going to get position feedback, which is actually quite difficult to design in pre-emptively.

       The first three large iterations of this joint required angles of the motors that made the upper arm far too large and heavy when using printed cogs, which is why I begrudgingly turn to cables.    

         I'm going to post here the final result. The skeleton. No drive motors as yet, or cables, but all the mechanisms are proven after painstaking testing. The test yaw I have here is surprisingly strong and uses heavy duty fishing line to transmit movement. The best part is that it almost looks like it could sit inside a persons arm. It also moves within a very similar set of angles, stopping very close to where our own arm yaw would stop in each direction. I can't wait to get the motors hooked up!!!

    I am going to now post a picture of what the first iteration of the upper arm yaw looked like next to the current version. You can't really see it from the angle but the first iteration at the bottom of the picture is 12cm wide and weighs a whole lot  more than the current version.

    I guess a final note, I should point out that each one of these joints is designed to hold a significant amount of weight. No-where near as strong as a person, or robot arm driven by dynamixels. But for the cost of each joint, these arms should hold an impressive amount of weight. Hopefully allowing them to interact with the world, carrying bottles, bags etc. If I get the fingers right ( I am thinking of having two sturdy fingers and a thumb) then I can easily see it holding an object of around 2 kilograms. The benefit of having a whole body is that many more motors can be brought into lifting movements, if enough control can be programmed in. I'm still struggling with IK of the legs, so I can certainly see these kinds of complex movements being an issue for me to program.

         Why design the arms before the abdomen? Because it is crucial to know how they will work before I design the bit that they sit in. My designs evolve rather than me sitting there and having exact measurements and angles drawn down. I have a rough idea, but nothing exact until I have been through a few iterations.

  • Disaster.......

    Dan DWRobotics08/01/2017 at 22:51 0 comments

    Really frustrating update!

       I've spent the last two night trying to make a strong yaw mechanism for the upper arm of the full size humanoid. I've refined the design and fought with sketchup to export an .stl that doesn't have any non manifold or self intersecting surfaces. I finally managed to refine the design to something that works and now the printer itself has decided it doesn't want to play ball.

       I just spent 6 hours on two prints that both failed half way into the print. As you can see they both skipped on a Y axis on both prints, but on different layers. This is suggesting a mechanical fault with the printer so I am going to get my WD-40 out and lubricate all of the guides. I'll clear any dust or particles out of the mechanism and make sure there is nothing messing with the cables of that sensor.

       I should have a pretty bad-ass upper arm to show by now but I am still at the printing stage after three days. Very frustrating!!! I will update this log when I have more success.

  • Bevel-ly Crusher

    Dan DWRobotics07/29/2017 at 21:38 3 comments

    Well, I spent an entire day designing a pseudo bevel gear - and it works.

            Quite a boring update, but the implications of what I can do with it are quite great. I've been toying with the idea for a while but since my main design tool is sketchup, there are no inbuilt tools for designing gears and so when I do it, I do it by manually designing and drawing out the teeth in sketchup and then rotating and copying them to make a full gear. There is a certain amount of intuition involved and it is by far not the best way to create mechanisms, but this one is working really well. What it does is gives me a really nice way to have a 'Yaw' inbetween the shoulder and elbow of my humanoid robot, but keeping the form factor within humanoid proportions.

         I have been putting this off for quite some time because I knew how long it would take me to get a working design.

                What this also does, is gives me a really nice mechanism to use on a gripper, for a different project I have been working on in my head. A super cheap, but highly functional table top robot arm. The gear above is not really a 'bevel' since the gears are not angled and so don't truly mesh in the way a bevel does, but it does give me a really nice smooth motion between my cheap hobby motors and any Yaw joint that I want to make.

  • Kinematic Videos - Need Sensor Feedback and Big Feet

    Dan DWRobotics07/26/2017 at 23:20 6 comments

    So I did some further work towards controlling the legs. I added a set of sliders to the GUI that control the legs individually or together. The one for the left leg 'contracts' the leg so it raises up in a straight line. This is achieved by programming the slider to add values to multiple joints at the same time. Specifically, for every 1 degree that the hips and ankles move, the knee will move by 2 degrees. This is using very basic trigonometry and is the basis of inverse kinematics. I

      Here is a poor quality vid of messy room and shakey legs. The slider controls the legs up and down movement. I should be able to use these movements at a later date to begin the basics of walking.

    These next vids are demonstrating the use of one slider to teleoperate the legs. That one slider changes values on six joints at the same time. Previous movements have been generated by merging between two previously save positions, but those I need to teach it. The slider controlling all six joints is creating a new range off movements according to all possible configurations of an equalateral triangle made by the legs:

     This video also demonstrates the PID program I have been working on to control the legs. I think the jerky motion is caused by the maths behind the PID I wrote. As I move the slider up, the difference is only small and so the leg power output is not high, but after a period of time, the error multiiplying over time causes the power to increase which makes the legs move upwards but they jerk upwards because they are catching up to the desired position. This would mean that I should slightly increase the effect of the Integral factor, so that the power increases slightly quicker. The danger however is that by increasing the speed that the integral affects the power output, the legs will become even jerkier . The legs will eventually have large LiPo batteries in the shins, this will prevent some of the wobble and jerk for two reasons. The batteries have enough current to drive the legs without cutting out ( the current power supply cuts out past 4 amps). Also having slightly heavier legs will lend overall stability to the structure. At the moment they are all motors and plastic, but not much weight which causes them to jerk and wobble. Having the extra weight will dampen the jerky motions a little.

       The main change that is require however, is to completely redesign the feet. This will take a long time indeed. The feet need to be bigger ( not massive). They also need to have four rubber points to absorb shock but more importantly will house the force sensitive resistors to give feedback on weigh dispersion. I can then write a basic bit of code that modifies the foot position to always have the maximum weight dispersion. This will be the main ingredient that is going to stabilise these legs.

  • Pythagorus, Kinematics, Broken Hips, Angry Neighbours

    Dan DWRobotics07/25/2017 at 23:41 0 comments

    Small update. The last couple of nights I have been working on some new GUI sliders for the legs. The idea was to create a slider that would make one of the legs raise up at the hip and knee. I created three sliders one for each leg and one which controls both legs at the same time.

       I got reacquainted with Pythagoras and worked out that if trying to keep the hips and ankles level with each other they should contract by an equal amount( of degrees) whilst the knee needs to contract by double the amount(of degrees).

    In theory I should be able to keep the legs upright whilst cycling up and down a crouch manually with the slider rather than merging between saved moves.

    In it's most basic form, this is the essence of kinematics. Although there is much more work to be done on making and accurate mathematical model of the legs.

        This gives me a very basic ability to control the total 'crouch' by moving one slider up and down. By alternating crouch on each leg I can begin to build the rudiments of a walking gait. Although the hips need much more strengthening before they will rigid enough to do this properly.

         The below video shows me using the slider to control all 6 joints at the same time:

    I thought it would be fun to throw some extra difficulty into the mix by putting it on carpet to see how it would fare.

      When the legs cut out completely this is due to the power supply I am using. It only provides max 4 amps at 12 volts so the legs sometimes try to draw much more, usually at an extreme crouch.

    I am designing bigger, more rigid feet for it, that will also feature quad pressure sensing to enable autonomous balancing to stabilise the legs.

  • PID woes Solved and New designing phase

    Dan DWRobotics07/22/2017 at 12:33 0 comments

    Small update 22/07/17:

    I realised something that had been working against me massively. The legs seemed to be much less controlled than I expected, always shakey and the power wasn't as high as I had thought it should be.It all came down to the PID calculations I had programmed. I was racking my brains to trying to work out how to calculate the Derivative value and then I noticed something. I had been adding my P and I values together because the sum fitted nicely into a usuable value for PWM. But with PID you are supposed to multiply the P and the I and this gives you the proportional output required. However when multiplying my P and I , I was getting crazy values, far too high to use with PWM. The solution was really simple - divide the result by 10!

     The I have values I can use in PWM and I can also tune that number to vary my overall speed and strength. The legs seem to move a lot more smoothly now.

       I am currently trying to design the upper arms. It is surprisingly difficult to work out because I need to add a 'swivel' to the section between the shoulder and the elbow, which allows the arm to move in a similar manner to humans. I have some designs for turntable type swivel motion but they are not rigid and they are also enormous which is not going to translate very well to a human type form.

       I have also printed a 'bicep' joint which I am fairly happy with, but it impossible to know how it will look until I design the upper arm . This part is always really difficult because I know how I want to achieve something and have a rough idea of how to do it, but it takes a huge amount of time to work the 'best' way to do something. It means sketching on paper or even just staring at pieces that I have laying around and trying to reconfigure them in my mind to get a working piece. Very long and quite frustrating. 

    As you can see. My designs are nothing more than massive cogs. No where near as advanced as the harmonic drives and brushless motors of ASIMO or those massive robotis servos. But to get a similarly sized robot servo I would be looking at a huge cost, whereas I can make each joint for around £5 so if it means I can make a whole robot I am going to go with the simple and cheaper option. The way I see it, human muscles are very much analog. The thing that makes ballet dancers so graceful is a combination of the sensors and processor. If you have a good processor and lots of sensor data, you can achieve a decent amount. I was always planning to put a powerful onboard PC solution on the machine, so that should be able to crunch the numbers. The arduino is essentially just a big servo controller.

  • Motor Control and Rigidity Frustation

    Dan DWRobotics07/21/2017 at 18:26 0 comments

    So I wasn't able to get it stand on one leg reliably enough to do it in a sequence without me holding it up. I don't want to ever rely on harnesses and having people nervously standing behind it.

        There are a number of factors that need to be overcome. The problem is, they are all boring. So I designed the biceps instead.

        Problem 1:

        I keep getting oscillating of the limbs around the set point. This is because I wrote a PI control of the motors on the arduino myself and I'm no engineer/mathematician. I got it to move and couldn't be bothered to continue programming preferring instead to make it do funny moves.

         What I really need is the D (ok stop sniggering, I didn't mean that).

     I have a variable for the distance between where the joint is and where I want it to be, this is in very basic terms the Proportional. Then I have a variable for the amount of time that the distance is far(so the error over time, which accumulates) and that is the Integral part.

      I worked out today how I am going to do the Derivative part but it is difficult to keep the concept in my mind. I need a variable which tracks the rate at which the error increases or decreases.  It needs to know when to expect the error will be zero again so it can lower the power before that happens. So to get the rate at which the error increases or decreases.....(even now I am struggling to visualise how to do this in an ardunio loop) .

        The difference between the set point and the current position is called diff[x] in my loop and it is calculated for all joints. If it is a negative number I convert it to a positive (I reverse the number again when applying the power). So if you were to look at a list of the differences over a number of 10 millisecond cycles it might look like this:

    millis()                                  diff[30]

    millis()+10                            diff[15]

    millis()+10                            diff[7]

    millis()+10                            diff[1]

    So the above would represent a joint position accelerating to the correct set point. So I need to track the rate of acceleration or deceleration ( not of speed but of rate at which the error changes). Then my code would need to increase or decrease the power depending on rate. I also need the code to know if it is accelerating or decelerating. Well I am going to have a think about this now (maybe a tiny crying session). Then come back and try to solve this. All I know is that it will involve maths which I am rubbish at.

    I was going to write about all the problems but that will get boring so I will just summarise the next one:

    Problem 2:

      The waist/hips rotators are mounted inside their 'bearings' too losely so the whole frame is unstable, which is not good for standing on one leg. I tried to be too clever with the design and should have stuck to directly mounting on skateboard bearing like I do with everything else. I won't have time now to redesign the whole hips/waist so I am going to print a load of add on pieces that will stabilise these joints enough.

View all 11 project logs

  • 1
    Difficult to add full instructions but.........

    Whilst it's going to be very difficult for me to write a step by  step guide as to how I built the legs, I am going to start adding some very basic insructions on what I did to start the process of trial and error that governs how I am proceeding. I guess the very first thing I needed was to design and print some parts. I started with a 'Velleman' K8200. Mainly because it is cheap and was stocked in my local Maplins.

       This printer took 2 whole days to construct, so my first advice would be, maybe go with something else!!!!

       My next printer will be the Creality CR-10. It looks to have an amazing quality when printing and is almost as cheap. However the main benefits to this printer would be that it can print 30 x 30 x 40 , which is pretty big for that price range.

       I then had to learn some form of CAD. I chose Sketchup. Quite simply because at the time it was completely free and seemed like a very quick to learn design tool. If I could liken it to anything I would say it's like having MS Paint but with 3D!!

View all instructions

Enjoy this project?



samern wrote 08/10/2017 at 12:06 point

Hi there.  I saw this and thought....hmmm...I printed all the parts for my Inmoov from the waist up, and you have a design from the waist down.  I wonder, could the two mechanical platforms be mated together and have a complete humanoid?

  Are you sure? yes | no

Dan DWRobotics wrote 08/10/2017 at 21:53 point

Hi Samern, thanks for looking. It would certainly be an interesting project to combine the two! I'm currently working on the torso and arms of my humanoid. It is going to take me an awful long time I think. I will need to have some form of torso and arms added to these legs before I can have any chance of it being able to walk. I also need to do a lot of redesigning of the foot before I can make it walk. The project and designs will evolve enormously over the next few months, so I certainly wouldn't be at a stage yet to be able to publish all of the files to work on a collaboration but it is my goal to make this a collaborative effort once it is at a stage where I am happy that it is functional. Inmoov is an awesome feat of design, but is still essentially a very complex mannequin. My goal with this project however is to make a humanoid that can perform tasks and stand upright without supports etc, so my design efforts are very much based around hands, arms, mechanisms that can pick things up and interact with objects. I'm currently designing hands and arms that look much different to inmoov, in that my hands will have two fingers and a thumb in order to make practical application possible. The other challenge is that my joints are made with cheap DC motors and potentiometers, with a control system that is designed to make that possible. If you put an inmoov torso on it, they would effectively be two separate systems working independently whereas my goal is to make one system from the same parts that act as a whole.

  I guess my main point is that I want to make the whole platform from the same cheap hobby motors rather than the more expensive hobby servos that inmoov uses, in order to make an entire humanoid from parts that cost less than £800. I deliberately avoid using servos because I want to demonstrate that not all robotics needs to start with the same hobby servos and libraries, despite their ubiquity and ease of use.

  Are you sure? yes | no

samern wrote 08/11/2017 at 02:02 point

Hi Dan.  I xan certainly understand.  Even the process of printing so many parts is in of itself expensive.  I plan to watch this project closely because I would love something like this puttering around the house.  If I could get it to freak out the kids on Halloween so much the better.  Have you considered controlling it uaing something like LeapMotion?

  Are you sure? yes | no

Mike Volckmann wrote 08/01/2017 at 01:40 point

Hi Dan. I must say this idea holds it's weight in gold if someone were to polish it up and make it into a product to sell. I think, however, that as a personal project it's one of those things where I have no clue what's going on, but I see the potential of what it can do. The potential of it becoming something more. Like other projects this one just screams science fiction made into reality with regards to it being something that seems quite plausible. Great job.

  Are you sure? yes | no

Dan DWRobotics wrote 08/01/2017 at 20:49 point

Hi Mike, thanks very much for having a look! I'm really optimistic that this project will evolve into something pretty cool! I imagine that I might be able to start working on the first domestic robots. Ones that can cook and clean. Seems like a long shot, but the beginning is to have lots of people working towards that goal and refining the programming. But that can't happen until lots of people can afford a full size humanoid. They all seem to be way out of the price range of a tinkerer. The UXA-90 retails around £20000 from what I have heard. It doesn't even have hands!! Who could afford that? It's essentially a £20000 gangnam machine.

  Are you sure? yes | no

Dan DWRobotics wrote 07/28/2017 at 20:22 point

Hi Morning Star, thanks for taking a look. I need to re-write the description to give a bit more detail, but you raise an interesting point. I am aware of arduino/serial slowness. In fact, the arduino program is very simple. It starts with a preset set of positions and compares the current positions to an array of the 'move to' positions. So the arduino itself does not rely on any input from an external processor to compare current position to desired position. The arduino will repeat the comparisons thousands of times a second. The PID is on the arduino, but when there I need to merge between two preset sets of movements the calculations are made by my laptop. The laptop will send a new set of positions hundreds of times a second but the PID does not depend on feed back going to the laptop before it sends it's new set of positions, so there is no bottleneck through the serial. The arduino itself just acts like a centralised servo controller trying to get the joints to match the 'move to' set of positions that the laptop sends it. This leaves the arduino free to simply loop and compare the current positions to the 'move to' positions. The laptop , using Processing does the calculations on when to send new positions.

     When I need to send a choreographed movement where all joints move in unison merging between two preset set of positions, this is done from Processing on the laptop. The processing program divides the differences between each 12 degrees of freedom by 100 then feeds the arduino a sequence of different intermediate positions over a length of time to make sure that when there is a load on a joint, it gets to the expected position at the same time as the joints without the load.

   Quite a difficult system to explain, especially since I have now had a couple of beers, but I really appreciate the feedback. The great thing is, you reminded me of the term 'hysteresis' which I have been trying to remember for some time, because it really applies to what I am doing!!!

    I should add, the Processing program is not completely in the dark about the 'current' positions feedback. It does constantly receive the position feedback from the arduino, but the PID does not rely on the Processing program to speed up or slow down the motor, this is done by the simple arduino program I created. The feedback to the Processing program is currently used by Processing to 'save' a set of positions into a position array. Then processing can send a set of nicely timed intermediate updates to the arduino to get it to move in a seemingly controlled fashion.
   Where your observations will really come into effect, is when I start feeding back pressure sensor and accelerometer data to the processing program. That level of processing can't be done by the arduino. That data really is time sensitive to make the responses matter, so I am considering writing a system that will feed pressure sensor data to the laptop ahead of any position feed back. I will program the arduino to break the pressure sensor data ( between four pressure sensors on each foot) into a smaller number, such a three coordinates. I could even create a grid 0-255 whereby the centre of gravity for each foot is given.  Imagine a grid 15 x15. The centre of gravity would be calculate by the arduino and expressed as a dot on the grid of 15x15 so could be transmitted by the arduino extremely quickly for each foot as a value between 0-225. Just two bytes, hundreds of times a second may come close to what i need for the laptop to give an appropriate response.

  Are you sure? yes | no

Morning.Star wrote 07/27/2017 at 07:34 point

Thats a pretty impressive design feat already, and it looks like you know where you are going with it. This isnt a criticism, but you are probably going to have to reconsider your processor though. While a Pi is probably powerful enough, and the Mega has enough digital and analog ports both have serious communications issues; Every motor update and sensor response bottlenecks in the serial transport and throws synchronisation out of the window. The lag between reading sensors and addressing servos is large enough to cause hysteresis; averaging to avoid this will slow the system to a crawl.

I havent entirely solved this issue myself but I have ironed out a lot of the synchronisation issues by distributing processors into the limbs, making them responsible for themselves instead of a central processor doing it. We have a highly parallel communications bridge between our brain and muscles, and I threw a Mega1284 at the 12 servos and 4 pressure sensors at the quadruped I built without realising it didnt have enough compute capacity available to do the job, even by adding a Pi, and the motion was jerky. I'm redesigning the servo sequencer I made to run on multiple processors for this reason and that may be enough to get my (much smaller and servo powered) robot to balance. #DECAL 

I also had to redesign my feet to be nearly 3 times the area they were to allow me to take longer steps without risking balance; its all about fine-tuning with hundreds of tiny fast adjustments, or using a large stable base. I also went to a triangular pattern of force sensors so it didnt have to stand on a hard and completely flat surface. (Carpet kills sensor feedback, its like trying to walk on a mattress - all balance is done using upper body...)

@Radomir Dopieralski  manages smooth motion by using a much faster MCU with a lot more memory and placing his motion routines inside that, so they can address his servos in parallel... ;-)

  Are you sure? yes | no

Radomir Dopieralski wrote 07/27/2017 at 12:02 point

To be honest, I actually didn't achieve smooth motion in my robots yet.

  Are you sure? yes | no

Morning.Star wrote 07/27/2017 at 17:00 point

Heh, well the clips I've seen dont look like a case of the DT's and you're running quite a few at once. Lets say smoother then :-)

I think I was trying to point out there's other ways than mine to go about it, and yours is walking... I think I need to say though, MicroPython isnt the best use of processor cycles when it comes to precise timing. The processor may run 10x faster than an Atmega, but its doing a lot more ultimately to switch those ports on and off at the right moment, and thats what counts.

  Are you sure? yes | no

Radomir Dopieralski wrote 07/27/2017 at 17:57 point

It seems to be a good use of the programmer's time, though.

But them again, more than half of my robots are actually programmed in C++ on Arduino.

  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