This is turning out to be truly amazing James. Hats off for all the hard work that's gone into this project. It's become one of my favorite series to follow.
Nice one James, This project is getting to the inevitable forks in the road ( with decisions for enhancement ) . This has served ( as intended ) as a great guide to anyone wanting to do similar things. Showing why things dont work so well is gold to any new comer to the trials of engineering / computing so well done for those explanations ( keep them coming! ). I look forward to the next installment.
This show is one of my favorite things in the world. Thank you for sharing all of the details of the process including the missteps. I think, man, what if I'd had this show as a kid? You're doing good, good work, my friend. Thank you.
maybe add an eye nut on the top and hook it up to a nylon rope to the ceiling so when it loses balance during testing, it doesn't fall hard on the floor (like boston dynamic etc. also do)
Amazing project! Your explanations of how things work between the code and the physical is excellent. Thank you for that. Understanding the relationship, and then seeing it in reality, makes following the progress even more fun.
The creaking is probably due to the rate of change being different for each joint. (The final position is probably calculated correctly but the joints arrive there at different angular velocities and accelerations of the joints.)
Really enjoyed this so far. I can see an overlap in thinking between the balance and posture issues with those of dancing. It's an intriguing overlap which can serve to provide further perspectives on the problem as well as a means to bring people involved in dance into robotics and vice versa to enjoy the benefits of both. As well to expand interest in science and technology and entertainment fitness, dismantle tired stereotypes. I shall be coming back again!
Great work and awesome problem solving. Each build you make would be considered a prototype in a corporate setting. And they go through hundreds of prototypes and millions of dollars before they have a product. This amazing beast is just opendog #1. I'm sure like the other projects you will continue to tinker with it to get it to a place you are happy with, and we will be here along the way watching each alteration/ iteration . Keep up the great work!
Max, it is an open source project, if you really want to cry, you could send James some optimized code, or put it on github so others can add to it and share as well.
Upgrade time then. Have you considered looking into using ROS (that's opensource too) running on a Raspberry Pi (or something beefier) to run the calculations?
@@thekraftyguy i dont think those are the right chips for something like this, he needs a much faster MCU and not a highly complex cpu, so something like an STM32 or an ESP32 would work quite well with the existing code and would be much faster
@@asderidelp I was going to say maybe an ESP32 ( you can leverage both cores ) and set the IDE to use big app / OTA no spiff for space. Perhaps an ESP32 ( or 2 ) would be enough to replace the 3 mega;s, on the backend I would still go with an ARM Cortex perhaps the mediatek helio or something similar. The esp32 has super fast Serial for control and the helio can drive everything else and be the Master Node. This would use ROS as already stated. Perhaps building it out in a model using the ROS / Gazebo combination would be the right way to go, that way you could do everything in parallel.
Two questions: have you ever tried STM32s as they are much faster? Have ever thought of trying it with AI so that it learns by itself how to stabilized walk like a baby does with try and error? I know for AI an arduino as controlling unit is maybe a tiny little bit too small ... but maybe a pi does the job?
Hey James, the ODrives must have a way to report motor current which can be used to sense the load on it. You could use that to estimate where is the center of gravity as the weight distribution on the feet changes.
I think u should use a current meter to detect contact as not only will u get a signal on contact, but u can keep going to reach some threshold of "work" carrying weight. A simple clamp on meter should suffice as it's ac and u can get both the upper and lower joints.
Another option for the leg control issues if you want to keep your current setup is to use optical recognition tags to assign "joints" to the robot that can be monitored by a camera. Using Vuforia or some other software, measure the tags relative to each other to determine positions of each leg. Have little rods that extend from the sides of the robot and have a camera mounted at the end facing towards the robot, which will allow it to monitor itself. Combined with independent IMU's in each leg, individual computing units in each leg with a central head unit that uses a banana pi, and load cells at the bottom of each foot to determine weight distribution, you have yourself a very powerful robot.
I would say you could simplify things by stripping the serial down to SPI, generally you can run short hops of SPI up to system clock / 2, and it means you can have multiple devices tied off 1 SPI transceiver, It also simplifies the communication network to a ping-pong, the CS pin on the slave can fire an interrupt to enter communication, and the slave generally has a Interrupt pin telling the master to poll it shortly, So instead of constantly checking you serial buffers, you have a few pin change interrupts, then either set a flag for later or rip in / out the data at stupidly high speeds, a 16MHz arduino has a surprising amount of power when you avoid floating point math, even changing to fixed point math with 4 byte longs is generally hundreds of times faster, equally when you get a 8 bit message being sent by one device to another at Sys clock / 2, you get 16 cycles to handle the last packet, be it an address to start reading from, a command, etc, getting this right makes things way faster. I regularly play with low power electronics, so waking up, doing things fast then powering down is what I'm familiar with.
As a person that goes long ways to avoid using a computer i am always fascinated by coding. It makes me think :"Why again don't i use an arduino in my projects? This would make life so much easier..." Then i say to this Side of me: "Because you suck at coding" That's the point were i go and beat up some steel. I really love that project. I hope you don't get frustrated to often when you work on it. I wish you a stress free /frustration free work.
What's the little box on that really long single cord going into the 'bot at around 17:58? USB extension adapter? I'm guessing it's from your laptop to your MCU inside the chassis, I'm just curious about the little box.
Regarding the pressure sensors: I know it's a huge change, but redesigning the leg drives to direct belt drive (see Kuka Robot arms) would increase speed, is plenty precise, is much lighter, more silent and with an encoder attached directly to the motor you'd still have perfect position control. Aaaaaalso: by measuring the motor current you could get rid of the sensors! Can easily be done with a shunt resistor, by the way. Oh, and I am super damn impressed by your project and the progress you've made. Especially the software part. I'm a mechanical engineer, so it's black magic for me. edit: I've written this comment while watching the video. About shock absorbers: when a leg expect to touch the ground, you can use the motors as shock absorbers ... as you said like a minute later. But yeah, it'd be quite a challenge :D
Great work, James. Glad to see you're looking at making some material upgrades. While you're doing that, it might be worthwhile to see where you can drill/route lightening holes in some of those metal pieces. When I see a near-solid plate of aluminum, I see unloaded or under-loaded material. As I'm sure you're aware, lightening can have a positive impact on dynamic stability, as it means less weight to support and less inertia to accelerate.
Something that has been lurking in my mind for a few episodes now is the code you introduced that maps 0 to .01 to avoid division by 0 errors. This may not be an issue, but I've wondered for a while if that could introduce a cumulative error into the model based on the frequency each leg encounters a 0 in its maths?
I'm not sure about this, but you could read the motor current / momentum from the Odrives instead of using force sensors in the feets. Also you could limit the current to achieve some spring like behavior I guess?
I'd recommend jumping over to a teensy 3.6 or 3.5 for the main and then u can upgrade the slave arduino to teensy 3.2 or teensy lc. Plenty of speed and code space, in fact I bet u could swap out 2 slave arduino for a single teensy 3.2
lol. Have you considered installing a heavy gyroscope. I believe it will help out a lot with its stability. Especially if you put it on XY axis where you will be able to move it around to different corners (may not be necessary).
Been thinking the movement sequence for walking forwards overall doesn’t seem natural. Saw this and thought of you. There is a CAD animation of the four legged robot that seems to look more natural in its gait. Thought it may help 😁
What about a ball joint foot, like what you'd find at the top of a tripod, it could stilt pitch and roll etc. while keeping the foot firmly on the ground, would work well with uneven terrain as well.
correct, I got early access to the video as a patron. So I cheated. I really enjoy feeling that my couple of bucks a month helps James along with his projects, and the perk of getting the videos a little early, and the monthly live stream (which I usually miss, but catch later) gives me more then what I'm paying too. I recommend signing up.
Maybe you could try to stabilize it first using only the IMUs gyro. Use changes in rotation as the input for the pid regulator, and try to keep it at 0. The gyro tend to be "faster", like the rate mode on quadcopters. I coded my own quadcopter code, and I was unable to stabilize it successfully by only using the IMUs calculated angle as input for the pid controller. It was just too slow to react.
The gyro and accelerometer are mixed together - about 98% gyro. The gyro doesn't know which way up is otherwise and only produces rate of movement date.
@@jamesbruton And this mixing is what created problems on my project. There is no need for the gyro to know which way is up. The microcontroller only needs to know what is zero rotation output for each axis on the gyro. And as far as I can see, you want zero rotation speed when the robot is standing on two legs. I made a stabilized mode for my quadcopter, as well as a rate (gyro) mode. The stabilized mode utilized 2 "daisy chained" pid controllers for both pitch and roll. For example, the pitch pid controller took the input from the radio controllers pitch joystick. Say you wanted 5 degrees pitch; the pid controller would take this as an input, compare it to what the IMU pitch angle was, then output a "wanted gyro rate" that is required to achieve the IMU pitch angle. This output angle went into the second pid controller, which compared the wanted gyro pitch rate to the actual gyro pitch rate, then gave an output to the thruster allocation on how much thrust was needed in the pitch direction to achieve the wanted gyro pitch rate. The thruster allocation then translated this into actual motor controller commands. Then exactly the same was done for the roll axis. The yaw only utilized the gyro ate stabilization as I never really got the compass to work in the IMU code. If I were writing the code for your robot beast, then I would attempt a gyro stabilization only. Tell the pid controller to attempt to keep the gyro rate at 0 deg\second for pitch and roll axis. It will drift a little, but my feeling is that it will be stable on gyro ate stabilization for long enough between each of the robots steps. It will most likely be more responsive. This method worked way better than stabilizing using the angle from the IMU only (which is calculated by various ways of combining gyro\accelerometer). Not sure how it will translate to your project but that was just my, uh, 250 cents.
This extends off of something I've had bouncing around in my skull for tuning 3D printers: What about putting 3-axis accelerometers in the paws to measure actual acceleration against the theoretical acceleration in software? Close the acceleration loop to cancel out the inertia associated with any particular leg movement. Or is that just adding to the real-time processing lag?
Right now you have a hierarchical tree like bus architecture. You should consider using a bus with multi-master support every unit is connected to. This way every unit can request data form every other unit or send data to every unit. This would give you more flexibility and faster data access.
I would maybe try using a cycloidal gear drive instead of the Pully system. It will be more compact and so will result in less creek as less parts are reliant on each they
Would be cool to see if a neural network could be used (or some other method of ML) to balance the robot. The problem is maybe that how do you gather the data needed to train the model. Maybe NEAT method and simulator?
ok i hate to make this more complicated but i was doing some reading on plantigrade vs. digitgrade, in short you gave the open dog ankles but no knees, digitigrade animals rely on the heel and knee working counter to each other to balance and move. when you mentioned robot-x had large feet, thats cause his whole foot is on the ground, open dog is standing on his toes.
You should add computer vision to it. You could have different protocols when it detects different objects. Could also make it have emotional parameters that changed based on visual input like if it sees a dog(especially barking) it would try to get away from it since a dog would probably try to mess with it. This would also allow you for it to only walk in safe environments, for example to not go on a street, and if you want it to walk on the street then only make it go through the zebra crossing. I would integrate computer vision/machine learning and also a maps API for redundancy at detecting things.
What did you do with the AUX port on the ODRIVE drivers? Did you attached the braking resistor or not? What are the results? Let me know. And Great job
I'd recommend a STM32F7 MCU as the main processor. I can guarantee that you will never have issues with flash size or processing power if you use of those beasts.
WHAT ARE THOSE!? Those shoes look nice on that fellow. Not it can start working those joints more than ever. Getting closer to taking confident steps on it's own.
Nice job. The mass is definitly an issue causing the lack of stability. You might want to watch a few videos on howvStar Wars Imperial Walker was stop animated. The mass apeats to bevmore in relation to an elephant than a dog so the coding could be expanded to bebmove one foot at a time including a check to a gyro.
Reinforcement learning is the Boston Dynamics route. That requires more powerful MPU's and some simulator training. It would make it a self-tuning PID controller. Sutton's "Reinforcement Learning" is a good start (not sure how familiar you are with AI design).EDIT: Maybe try a Ultra960 or HiKey Dragon, or some such board for the MPU.
Hi james, Quadrupeds have three feet on the ground at any one time when walking. It may be a good idea to watch a dog, cat, a horse and a elephant walking, trotting and running and then try to mimic one of them for each mode.
Are you sure you want to go with crappy sensors? Why not go for proper load cells? Even compression ones can be aquired pretty cheaply in china together with the hx711 easily integratable with arduino.
I love this project, but....You are doing things the hard way... Arghhh :-) This is what you need for perfect walking, running and control of Open Dog. 1. Each leg to have its own inertial measure unit (Cheap 3 axis Accelerator). 2. Each leg to measure feet to ground with optical sensor / Mouse camera or something (Ultrasonic, IR) to measure distance and NOT touch (By the time it touches it is to late.) Measuring the distance you can gently accelerate or decelerate the leg to touch the ground gently and not slam into it. 3. Each leg ideally needs its own small 'Leg' computer (something like arduino nano). (A leg should be able to control itself without input from other sources, just like in real life. If it goes to fall the leg needs to be able to move to compensate on it's own. The only commands you should give these legs should be for basic walk, run commands and so on.) 4. Open Dog needs a main 'Head' computer to communicate the main commands (like walk forward to the other 'Leg' computers. Simply put, this is just a clock cycle where the main computer sends commands, or requests info one leg at a time. So we have four legs at say 15 cycles per leg per second, for a total of only 60 cycles per second. Since we only need to send direct, maneuver commands to each leg, technically most of these cycles would be blank, but if you did want to monitor the whole dog, then we could still do this in only a couple hundred bytes a second. (I like simple and streamlined.) Personally I would have a head (This would be the main / Head computer) on the dog, and the Dogs head would have another inertial measure unit. If you do all this right then you can tilt the head forward and open dog will go forward, back for reverse, left and right and so on. No need to have to control all the legs; see, now we are using our head. LOL If done right (Lots of assembly language), Open dog could controlled with of a ZX81. You just need the right sensors and algorithms. As a clue, one easy way to measure pitch, Roll and yaw is to interpret the measurements like a Dartboard, except instead of 20 quadrants we may use 8 in a clockwise order. These 8 quadrants give direction (Yaw), the other evenly spaced sectors in that quadrant show pitch and roll. The larger the roll the higher the number. In essence imagine having a Dartboard lay down flat, then have a marble where bull is, when you change the pitch or roll you see where that marble is rolling to the measurement, and this also automatically calculates the Yaw / direction of the leg. Now from the Dartboard (Lets say we are always aiming for bull (level)) we can calculate the data we have in just 1 Byte of info (4 bits for Yaw (8 directions) and 4 bits for Pitch and Roll (levels of tilt.)) The small computer in each leg then interpretates this into “Oh shit I am falling, put my leg out” if need be, whilst calculating what it is meant to be doing. We could use one more byte of info for the optical measure sensor on the foot to help with our fall too. This time we know when to stop the foot before smashing into the ground. So using just 2 bytes per cycle (per main Leg and or Head,) we can tell roughly how each leg of the dog is doing and where it is. Each Leg computer has its clock which is kept in sync with the head computer, so if a leg stumbles, then it can get back on track to where it should be when it recovers (Just like the military with marches and cadence, the only thing any of the platoon worries about is that one person calling out the beat so they know when left and right is.) If a stumble is to big, then a leg can send the data to the head computer which may then slow the walk speed for all the other legs, and possibly give commands to direct other legs, but once again each leg having it's own Leg computer should solve these issues on their own and be able to get back on their own feet. So going forward, (:-) ) We tilt the open dog head forward. This uses the Dartboard and sends a Walk forward command to each leg (lets say the head was pitched straight forward to 2) at speed 2. Each leg will now work out the timing of the clock cycle and what it is meant to be doing for that cycle and adjust to that for walk forward speed 2, until you tell Open Dog to stop. I know there is a lot more into this for the control of the motors, but this should give you a huge boost for how t get a very stable, walking, running, dancing dog. Hopefully this makes sense as it is very late where I am and I am very tired, but it does work. If you have any questions, ask.
I'm sorry but this sounds very outlandish to me, and in fact much more complicated than what James is currently doing. IMUs on each leg? Optical sensors for ground proximity? Binary servoing? That spider robot Adam Savage showcased in one of his videos has NO sense data besides motor position to do what James is trying to accomplish, with 8 legs. If you have high repeatability and can assume a flat plane for the environment, you can skip most sensory feedback. Now, that robot also doesn't need to balance on two points of contact, but I bet that even the current hardware setup of OpenDog could accomplish a more than satisfying gait given the right software.
Having physically separate computers in each leg is completely pointless and you are assuming walking is a hell of a lot easier than it is. I assume you have little to no programming experience based on the way you speak about "each leg will work out the timing of the clock cycle and what is meant to do" All you are doing is making up your own convoluted way of thinking without knowing how any of this works. Plus,with the inverse kinematic model he already knows the position of all points in the legs relative to body to double precision
@@Marci124 The way Open dog is designed will ultimately keep causing problems. Adam Savages Robot is a couple of ounces compared to this beasts mass, so they are not even close to being equal (feather vs brick), nor is the design of how they work close to being equal.
@@parkerbradshaw4122 Wrong! My system has been tried and tested and does work thanks. Having a kinetic model of having everything work is great in a perfect situation, and that is the biggest downfall; a walking robot needs a kind of fussy logic of independent limb control. A computer in each leg (Arduino Nano or even smaller) to monitor a clock, distance sensor, tilt sensor, 3 optical encoders and motor speed is child's play. With this you do not need complex models as you describe. A walking motion one leg at a time is VERY simple. Thanks for trolling though with no subs, no videos, and well just trolling youtube.
since there is such a hype about this topic i would be quite interested in how certain machine learning techniques could be incorporated into this project. so may have some neuronal net figure out the best parameters and timing for all this balancing stuff. just leave it running over night or so (probably faster to run a simulation and upload the trained neural net)
have you thought about having an overhead gantry for the robots and have you thought about i2c communication between the arduinos or even learning how to use a FPGA that's what I am doing
T-nuts are fiddly, I'd recommend T-slot spring-nuts, You just roll them into the slot and they stay there because of a spring-loaded ball-bearing. As for upgrades, if it's speed you want, you could try STM32s, they're 32-bit and a fair bit quicker, plus they can be programmed with the Arduino IDE that you're familiar with. Or could even try a Beaglebone Black with its two 200MHz microcontrollers and 1GHz CPU in one tiny package with a ton of GPIO. The PRUs in the BBB were made with high-speed, timing-sensitive communication in mind.
Having done something similar but a lot more primitive many many years ago I can appreciate why you stopped here. You will end up chasing errors and compliance issues for a long time with small incremental improvements. At some point in time you have to say it is what it is. This is about what I am going to get.
I think you should do the plastic-to-metal upgrades first. Many "wobbly" issues may disappear without any code changes, due to the stiffer material (fewer vibrations/harmonics).
I kept thinking that if it falls it could crush a small child or Volkswagon. I was nervous when you were kneeling right next to it while testing the motion.
Pick up a nice used treadmill and build up a simple support structure that can hold the dog with a rope hanging it from. That way you can eliminate the issues of balance while you work on the mechanics of walking and running
I mean you're probably not there yet. But could you use motion capture or at least animal based data to control the motion of the Open Dog? It seems like designing the dog around the motion would make the most sense.
Hi James, looking good so far. It looks like the chasis is twisting a lot along the spine - could this be changing the geometry enough to make the calculations wrong for the ballance? Have you calculated the centre of mass, and set the legs to be in line with it? Or have you designed it to have neutral balance? Or is it purely based on the tilt feedback? What is the end goal for OpenDog? I'd love to see this thing running but I suspect just walking in more than one axis at once is a more realistic goal (e.g. walk forwards whilst turning).
Could you share Odrive library of arduino that you are using on your openDog project, please? I'm having some issue with latest OdriveArduino library. They are seem to not working properly for me. Example code is not working and when i send a message 's' through the Serial, it prints out "Executing test blah blah" and does nothing. Thanks.
A 200mhz chipkit wifire board would make an excellent upgrade to all those... Even a 40mhz pic32 is waaaay faster than an 8 bitter. Easier to program than arm also.
I wonder what machine learning could do for the robot. You will have to export and assemble the dog parts in a 3d physics engine so that you can train it, and then use that AI model to drive it irl.
The most difficult part would be BUILDING That model. What is your goal? What are you going to train it to do? In this video he talked about how the robot is rigid and uses mathematical models, and Machine Learning is just the progression of that. But it's still rigid. You need to be able to write a formula that calculates just how good the robot is walking, and that is NOT an easy task for such a complicated problem like walking.
exactly what i thought. look for the videos from "code bullet" this guy does make ai systems do learn all kinds of things. i would think it could adjust all the timings and angles to make itself walk better and smoother.. but without a accurate simulation its propably not practical.. like learning on the hardware might need the robot years to learn. (and also the whole robot is still so much in the basics... maybe its way to early to start such kind of fine-tuning... )
There are already AI simulations that have robots (in simulation) teaching themselves how to walk successfully. I don't know if any of them have been applied to real world robotics.
@@williamrutherford553 The reward function shouldn't be that hard for walking. And building the simulated dog would require the CAD models to be converted to standard 3d models. A physics system would handle the rest. Having the motors and other sensors properly mapped to a virtual environment would be a lot harder. And probably in the end some real life learning would be needed to refine the model. But one could get very robust and organic movements. Do note that boston dynamics do not use machine learning AI for movement.
@@mm-hl7gh I like code bullet too, but he doesn't really make AIs, he basically makes programs that brute force the result. His AIs do no learning, they just do a bunch of random movements/whatever and pick the best result using his objective function
I wonder how much it would cost to start molding and replacing a lot of those parts with carbon fiber? I think some of the major issues (though, they really aren't major in the grand scheme) you're having are due to weight vs rigidity.
Yeah, the lag along that data path is pretty massive. Also, 20 Hz is a bit slow for the IMU to keep a system like that balanced. I don't know if there are ones that can be polled faster, but starting with such a slow sample rate is just going to make any delay in data to movement even worse. You may want to add a bit of a shock absorber to the feet. In a real animal, the muscles and joints have some give and that pressure is sensed by the body to help with balance. I would also suggest using two pressure sensors on the feet so that the robot can tell if it is coming down on its toe, whole foot, or in between. This would make allow a simple adjustment algorithm to act on the kinematic model to give it better balance since it will know what angle it is contacting the ground at. Considering that quadrupeds have ankles, I would also add the ankles and give them the ablity to lock in place for if you want to try a running gait or a gallop. I think most of us would be happy with just walking and not bumping into things or being remote controlled. This is all bio-mimicry based, but why reinvent the dog when we can just copy it?
i've used for my projects the firefly rk3399, it is a 6 core arm proc with 2 gb ram and 16 gb usable disk space, it can run Ubuntu and android. the proc is pretty fast. perhaps its usable for this project.
Bruton dynamics :)
A large value of this s not the Open Dog but documentation of the development of Open Dog. Very rare to find an excellent, public, development report.
This is turning out to be truly amazing James. Hats off for all the hard work that's gone into this project. It's become one of my favorite series to follow.
Nice one James,
This project is getting to the inevitable forks in the road ( with decisions for enhancement ) . This has served ( as intended ) as a great guide to anyone wanting to do similar things. Showing why things dont work so well is gold to any new comer to the trials of engineering / computing so well done for those explanations ( keep them coming! ).
I look forward to the next installment.
thanks, that was the plan!
This show is one of my favorite things in the world. Thank you for sharing all of the details of the process including the missteps. I think, man, what if I'd had this show as a kid? You're doing good, good work, my friend. Thank you.
maybe add an eye nut on the top and hook it up to a nylon rope to the ceiling so when it loses balance during testing, it doesn't fall hard on the floor (like boston dynamic etc. also do)
It only fell when the leg broke, hopefully that won't happen again ;-)
This is such a fantastic project. I like that you are documenting each change and the effect of each change. Learning with each episode!
Amazing project! Your explanations of how things work between the code and the physical is excellent. Thank you for that. Understanding the relationship, and then seeing it in reality, makes following the progress even more fun.
The creaking is probably due to the rate of change being different for each joint. (The final position is probably calculated correctly but the joints arrive there at different angular velocities and accelerations of the joints.)
Really enjoyed this so far.
I can see an overlap in thinking between the balance and posture issues with those of dancing.
It's an intriguing overlap which can serve to provide further perspectives on the problem as well as a means to bring people involved in dance into robotics and vice versa to enjoy the benefits of both. As well to expand interest in science and technology and entertainment fitness, dismantle tired stereotypes.
I shall be coming back again!
Great work and awesome problem solving. Each build you make would be considered a prototype in a corporate setting. And they go through hundreds of prototypes and millions of dollars before they have a product. This amazing beast is just opendog #1. I'm sure like the other projects you will continue to tinker with it to get it to a place you are happy with, and we will be here along the way watching each alteration/ iteration . Keep up the great work!
I’m always in awe of what you’ve achieved with this project, but every time you show us the code I can’t help but cry...
Max, it is an open source project, if you really want to cry, you could send James some optimized code, or put it on github so others can add to it and share as well.
I plan to at some point
I really like you work and the fact that you share everything. I used you code for my project. :)
*Salut James, c'est vraiment une superbe création, bientôt un nouveau boston dynamics, a bientôt*
Do the motor drivers not have feedback on current draw? I figured that would be used to determine when a foot was on the ground.
Upgrade time then. Have you considered looking into using ROS (that's opensource too) running on a Raspberry Pi (or something beefier) to run the calculations?
David Taylor or maybe a intel nuc
@@thekraftyguy i dont think those are the right chips for something like this, he needs a much faster MCU and not a highly complex cpu, so something like an STM32 or an ESP32 would work quite well with the existing code and would be much faster
@@asderidelp I was going to say maybe an ESP32 ( you can leverage both cores ) and set the IDE to use big app / OTA no spiff for space.
Perhaps an ESP32 ( or 2 ) would be enough to replace the 3 mega;s, on the backend I would still go with an ARM Cortex perhaps the mediatek helio or something similar.
The esp32 has super fast Serial for control and the helio can drive everything else and be the Master Node. This would use ROS as already stated. Perhaps building it out in a model using the ROS / Gazebo combination would be the right way to go, that way you could do everything in parallel.
@@sethrd999 You can get a dev board from stmicro that has an FPU for less than £20. 32-bit and having the FPU would improve performance tremendously.
Wonder if a parallela board would be a reasonable processing unit for this purpose
The balancing diagonal slow part was pretty cool !
Two questions: have you ever tried STM32s as they are much faster? Have ever thought of trying it with AI so that it learns by itself how to stabilized walk like a baby does with try and error? I know for AI an arduino as controlling unit is maybe a tiny little bit too small ... but maybe a pi does the job?
How would you set it up to learn to walk? I assume some sort of neural network, but surely that would be far too complicated for this build.
Maybe by try and error, it could try several combinations of parameters and the ones that dont work take off the list.
Hey James, the ODrives must have a way to report motor current which can be used to sense the load on it. You could use that to estimate where is the center of gravity as the weight distribution on the feet changes.
I think u should use a current meter to detect contact as not only will u get a signal on contact, but u can keep going to reach some threshold of "work" carrying weight. A simple clamp on meter should suffice as it's ac and u can get both the upper and lower joints.
Another option for the leg control issues if you want to keep your current setup is to use optical recognition tags to assign "joints" to the robot that can be monitored by a camera. Using Vuforia or some other software, measure the tags relative to each other to determine positions of each leg. Have little rods that extend from the sides of the robot and have a camera mounted at the end facing towards the robot, which will allow it to monitor itself. Combined with independent IMU's in each leg, individual computing units in each leg with a central head unit that uses a banana pi, and load cells at the bottom of each foot to determine weight distribution, you have yourself a very powerful robot.
I would say you could simplify things by stripping the serial down to SPI, generally you can run short hops of SPI up to system clock / 2, and it means you can have multiple devices tied off 1 SPI transceiver,
It also simplifies the communication network to a ping-pong, the CS pin on the slave can fire an interrupt to enter communication, and the slave generally has a Interrupt pin telling the master to poll it shortly, So instead of constantly checking you serial buffers, you have a few pin change interrupts, then either set a flag for later or rip in / out the data at stupidly high speeds,
a 16MHz arduino has a surprising amount of power when you avoid floating point math, even changing to fixed point math with 4 byte longs is generally hundreds of times faster, equally when you get a 8 bit message being sent by one device to another at Sys clock / 2, you get 16 cycles to handle the last packet, be it an address to start reading from, a command, etc, getting this right makes things way faster.
I regularly play with low power electronics, so waking up, doing things fast then powering down is what I'm familiar with.
As a person that goes long ways to avoid using a computer i am always fascinated by coding. It makes me think :"Why again don't i use an arduino in my projects? This would make life so much easier..." Then i say to this Side of me: "Because you suck at coding" That's the point were i go and beat up some steel.
I really love that project. I hope you don't get frustrated to often when you work on it. I wish you a stress free /frustration free work.
Arduino is a pretty good place to start. Lots of documentation, and you can see it doing something which is pretty good to keep you motivated.
If you place the IMU at 45 degrees it would be able to determine the balance point on the feet more directly. As it would be inline with them.
What's the little box on that really long single cord going into the 'bot at around 17:58? USB extension adapter? I'm guessing it's from your laptop to your MCU inside the chassis, I'm just curious about the little box.
i like the sound he makes when moving. very smart project, keep moving!
Bolt the stands to a bit of plywood for more stability. Beautiful job.
Regarding the pressure sensors: I know it's a huge change, but redesigning the leg drives to direct belt drive (see Kuka Robot arms) would increase speed, is plenty precise, is much lighter, more silent and with an encoder attached directly to the motor you'd still have perfect position control. Aaaaaalso: by measuring the motor current you could get rid of the sensors! Can easily be done with a shunt resistor, by the way.
Oh, and I am super damn impressed by your project and the progress you've made. Especially the software part. I'm a mechanical engineer, so it's black magic for me.
edit: I've written this comment while watching the video. About shock absorbers: when a leg expect to touch the ground, you can use the motors as shock absorbers ... as you said like a minute later. But yeah, it'd be quite a challenge :D
There is one word that's going to make this more dynamic and that is Boston.
Great work, James. Glad to see you're looking at making some material upgrades. While you're doing that, it might be worthwhile to see where you can drill/route lightening holes in some of those metal pieces. When I see a near-solid plate of aluminum, I see unloaded or under-loaded material. As I'm sure you're aware, lightening can have a positive impact on dynamic stability, as it means less weight to support and less inertia to accelerate.
Yes, it's mainly all the ball screws and motors that have the most mass...
Something that has been lurking in my mind for a few episodes now is the code you introduced that maps 0 to .01 to avoid division by 0 errors. This may not be an issue, but I've wondered for a while if that could introduce a cumulative error into the model based on the frequency each leg encounters a 0 in its maths?
You could add this video to the opendog playlist too!
I'm not sure about this, but you could read the motor current / momentum from the Odrives instead of using force sensors in the feets. Also you could limit the current to achieve some spring like behavior I guess?
Have you thought of adding a Gyroscope and another axis in the center of the body? Should help the back end roll better against the front.
I'd recommend jumping over to a teensy 3.6 or 3.5 for the main and then u can upgrade the slave arduino to teensy 3.2 or teensy lc. Plenty of speed and code space, in fact I bet u could swap out 2 slave arduino for a single teensy 3.2
lol. Have you considered installing a heavy gyroscope. I believe it will help out a lot with its stability. Especially if you put it on XY axis where you will be able to move it around to different corners (may not be necessary).
place a weight or resistance transfer mechanism along the tummy area to allow for fine balance control from the center
Been thinking the movement sequence for walking forwards overall doesn’t seem natural. Saw this and thought of you. There is a CAD animation of the four legged robot that seems to look more natural in its gait. Thought it may help 😁
What about a ball joint foot, like what you'd find at the top of a tripod, it could stilt pitch and roll etc. while keeping the foot firmly on the ground, would work well with uneven terrain as well.
well, your moving along. not quite walking yet, but I saw him take a couple of steps. I hope to see you moving forward in the near future .
He has posted only 12 seconds ago and you have commented 6 days ago????
@@mrnk4850 unlisted video
correct, I got early access to the video as a patron. So I cheated. I really enjoy feeling that my couple of bucks a month helps James along with his projects, and the perk of getting the videos a little early, and the monthly live stream (which I usually miss, but catch later) gives me more then what I'm paying too. I recommend signing up.
I believe there will be a soon jumping dog video :)
My dude you deserve wayyyyyyyy more subscribers and views
I wonder if the shock absorbers goes with fuzzy logic as the exact location wont be needed if it is just near enough.
Please keep doing this project I love your robotic Engineering
I will be!
Maybe you could try to stabilize it first using only the IMUs gyro. Use changes in rotation as the input for the pid regulator, and try to keep it at 0. The gyro tend to be "faster", like the rate mode on quadcopters. I coded my own quadcopter code, and I was unable to stabilize it successfully by only using the IMUs calculated angle as input for the pid controller. It was just too slow to react.
The gyro and accelerometer are mixed together - about 98% gyro. The gyro doesn't know which way up is otherwise and only produces rate of movement date.
@@jamesbruton And this mixing is what created problems on my project. There is no need for the gyro to know which way is up. The microcontroller only needs to know what is zero rotation output for each axis on the gyro. And as far as I can see, you want zero rotation speed when the robot is standing on two legs.
I made a stabilized mode for my quadcopter, as well as a rate (gyro) mode. The stabilized mode utilized 2 "daisy chained" pid controllers for both pitch and roll. For example, the pitch pid controller took the input from the radio controllers pitch joystick. Say you wanted 5 degrees pitch; the pid controller would take this as an input, compare it to what the IMU pitch angle was, then output a "wanted gyro rate" that is required to achieve the IMU pitch angle. This output angle went into the second pid controller, which compared the wanted gyro pitch rate to the actual gyro pitch rate, then gave an output to the thruster allocation on how much thrust was needed in the pitch direction to achieve the wanted gyro pitch rate. The thruster allocation then translated this into actual motor controller commands.
Then exactly the same was done for the roll axis. The yaw only utilized the gyro
ate stabilization as I never really got the compass to work in the IMU code.
If I were writing the code for your robot beast, then I would attempt a gyro stabilization only. Tell the pid controller to attempt to keep the gyro rate at 0 deg\second for pitch and roll axis. It will drift a little, but my feeling is that it will be stable on gyro
ate stabilization for long enough between each of the robots steps.
It will most likely be more responsive.
This method worked way better than stabilizing using the angle from the IMU only (which is calculated by various ways of combining gyro\accelerometer). Not sure how it will translate to your project but that was just my, uh, 250 cents.
@@jamesbruton use quaternion math. Its much better method to handle both gyro and acc data.
Great job I really love all your builds
This extends off of something I've had bouncing around in my skull for tuning 3D printers: What about putting 3-axis accelerometers in the paws to measure actual acceleration against the theoretical acceleration in software? Close the acceleration loop to cancel out the inertia associated with any particular leg movement. Or is that just adding to the real-time processing lag?
Right now you have a hierarchical tree like bus architecture. You should consider using a bus with multi-master support every unit is connected to. This way every unit can request data form every other unit or send data to every unit. This would give you more flexibility and faster data access.
Please can you make a step by step tutorial on how you built the remote and receiver
I would maybe try using a cycloidal gear drive instead of the Pully system. It will be more compact and so will result in less creek as less parts are reliant on each they
Would be cool to see if a neural network could be used (or some other method of ML) to balance the robot. The problem is maybe that how do you gather the data needed to train the model. Maybe NEAT method and simulator?
What printer do you use for open dog
In the video that screakings sound really sounds like belts slipping
How fast can those legs move on those actuators? Fast enough to 'jog' (one day)?
ok i hate to make this more complicated but i was doing some reading on plantigrade vs. digitgrade, in short you gave the open dog ankles but no knees, digitigrade animals rely on the heel and knee working counter to each other to balance and move. when you mentioned robot-x had large feet, thats cause his whole foot is on the ground, open dog is standing on his toes.
You should add computer vision to it. You could have different protocols when it detects different objects. Could also make it have emotional parameters that changed based on visual input like if it sees a dog(especially barking) it would try to get away from it since a dog would probably try to mess with it. This would also allow you for it to only walk in safe environments, for example to not go on a street, and if you want it to walk on the street then only make it go through the zebra crossing. I would integrate computer vision/machine learning and also a maps API for redundancy at detecting things.
What did you do with the AUX port on the ODRIVE drivers? Did you attached the braking resistor or not? What are the results? Let me know. And Great job
Cool project! What do you think about IQ4516HV servo motors?
I'd recommend a STM32F7 MCU as the main processor. I can guarantee that you will never have issues with flash size or processing power if you use of those beasts.
WHAT ARE THOSE!?
Those shoes look nice on that fellow. Not it can start working those joints more than ever. Getting closer to taking confident steps on it's own.
Do you have it decelerate the leg drop when the feet are about to touch the ground?
James, I'm curious... have you kept up with the total parts and materials cost used in this project? If so, what is it at this point?
Not in detail, but about £ 2000
@@jamesbruton , interesting, I would have assumed almost twice that.
@@WisdomVendor1 I think he's keeping parts costs down using 3D printing and CNCing aluminum parts on his own.
I'm still amazed at how fast those linear actuators can move.
Nice job. The mass is definitly an issue causing the lack of stability. You might want to watch a few videos on howvStar Wars Imperial Walker was stop animated. The mass apeats to bevmore in relation to an elephant than a dog so the coding could be expanded to bebmove one foot at a time including a check to a gyro.
What about trying different walking/running models based off different animal's gaits?
Reinforcement learning is the Boston Dynamics route. That requires more powerful MPU's and some simulator training. It would make it a self-tuning PID controller. Sutton's "Reinforcement Learning" is a good start (not sure how familiar you are with AI design).EDIT: Maybe try a Ultra960 or HiKey Dragon, or some such board for the MPU.
Hi james, Quadrupeds have three feet on the ground at any one time when walking. It may be a good idea to watch a dog, cat, a horse and a elephant walking, trotting and running and then try to mimic one of them for each mode.
yep, so check out the discussion in the last video.
Are you sure you want to go with crappy sensors? Why not go for proper load cells? Even compression ones can be aquired pretty cheaply in china together with the hx711 easily integratable with arduino.
I love this project, but....You are doing things the hard way... Arghhh :-)
This is what you need for perfect walking, running and control of Open Dog.
1. Each leg to have its own inertial measure unit (Cheap 3 axis Accelerator).
2. Each leg to measure feet to ground with optical sensor / Mouse camera or something (Ultrasonic, IR) to measure distance and NOT touch (By the time it touches it is to late.) Measuring the distance you can gently accelerate or decelerate the leg to touch the ground gently and not slam into it.
3. Each leg ideally needs its own small 'Leg' computer (something like arduino nano). (A leg should be able to control itself without input from other sources, just like in real life. If it goes to fall the leg needs to be able to move to compensate on it's own. The only commands you should give these legs should be for basic walk, run commands and so on.)
4. Open Dog needs a main 'Head' computer to communicate the main commands (like walk forward to the other 'Leg' computers. Simply put, this is just a clock cycle where the main computer sends commands, or requests info one leg at a time. So we have four legs at say 15 cycles per leg per second, for a total of only 60 cycles per second. Since we only need to send direct, maneuver commands to each leg, technically most of these cycles would be blank, but if you did want to monitor the whole dog, then we could still do this in only a couple hundred bytes a second. (I like simple and streamlined.)
Personally I would have a head (This would be the main / Head computer) on the dog, and the Dogs head would have another inertial measure unit. If you do all this right then you can tilt the head forward and open dog will go forward, back for reverse, left and right and so on. No need to have to control all the legs; see, now we are using our head. LOL
If done right (Lots of assembly language), Open dog could controlled with of a ZX81. You just need the right sensors and algorithms. As a clue, one easy way to measure pitch, Roll and yaw is to interpret the measurements like a Dartboard, except instead of 20 quadrants we may use 8 in a clockwise order. These 8 quadrants give direction (Yaw), the other evenly spaced sectors in that quadrant show pitch and roll. The larger the roll the higher the number. In essence imagine having a Dartboard lay down flat, then have a marble where bull is, when you change the pitch or roll you see where that marble is rolling to the measurement, and this also automatically calculates the Yaw / direction of the leg.
Now from the Dartboard (Lets say we are always aiming for bull (level)) we can calculate the data we have in just 1 Byte of info (4 bits for Yaw (8 directions) and 4 bits for Pitch and Roll (levels of tilt.)) The small computer in each leg then interpretates this into “Oh shit I am falling, put my leg out” if need be, whilst calculating what it is meant to be doing. We could use one more byte of info for the optical measure sensor on the foot to help with our fall too. This time we know when to stop the foot before smashing into the ground. So using just 2 bytes per cycle (per main Leg and or Head,) we can tell roughly how each leg of the dog is doing and where it is. Each Leg computer has its clock which is kept in sync with the head computer, so if a leg stumbles, then it can get back on track to where it should be when it recovers (Just like the military with marches and cadence, the only thing any of the platoon worries about is that one person calling out the beat so they know when left and right is.) If a stumble is to big, then a leg can send the data to the head computer which may then slow the walk speed for all the other legs, and possibly give commands to direct other legs, but once again each leg having it's own Leg computer should solve these issues on their own and be able to get back on their own feet.
So going forward, (:-) ) We tilt the open dog head forward. This uses the Dartboard and sends a Walk forward command to each leg (lets say the head was pitched straight forward to 2) at speed 2. Each leg will now work out the timing of the clock cycle and what it is meant to be doing for that cycle and adjust to that for walk forward speed 2, until you tell Open Dog to stop.
I know there is a lot more into this for the control of the motors, but this should give you a huge boost for how t get a very stable, walking, running, dancing dog. Hopefully this makes sense as it is very late where I am and I am very tired, but it does work. If you have any questions, ask.
I'm sorry but this sounds very outlandish to me, and in fact much more complicated than what James is currently doing. IMUs on each leg? Optical sensors for ground proximity? Binary servoing?
That spider robot Adam Savage showcased in one of his videos has NO sense data besides motor position to do what James is trying to accomplish, with 8 legs. If you have high repeatability and can assume a flat plane for the environment, you can skip most sensory feedback. Now, that robot also doesn't need to balance on two points of contact, but I bet that even the current hardware setup of OpenDog could accomplish a more than satisfying gait given the right software.
Having physically separate computers in each leg is completely pointless and you are assuming walking is a hell of a lot easier than it is. I assume you have little to no programming experience based on the way you speak about "each leg will work out the timing of the clock cycle and what is meant to do"
All you are doing is making up your own convoluted way of thinking without knowing how any of this works.
Plus,with the inverse kinematic model he already knows the position of all points in the legs relative to body to double precision
@@Marci124 The way Open dog is designed will ultimately keep causing problems. Adam Savages Robot is a couple of ounces compared to this beasts mass, so they are not even close to being equal (feather vs brick), nor is the design of how they work close to being equal.
@@parkerbradshaw4122 Wrong! My system has been tried and tested and does work thanks. Having a kinetic model of having everything work is great in a perfect situation, and that is the biggest downfall; a walking robot needs a kind of fussy logic of independent limb control.
A computer in each leg (Arduino Nano or even smaller) to monitor a clock, distance sensor, tilt sensor, 3 optical encoders and motor speed is child's play. With this you do not need complex models as you describe. A walking motion one leg at a time is VERY simple.
Thanks for trolling though with no subs, no videos, and well just trolling youtube.
Guys stop arguing!
P.s. @@10p6 subs are not the measure of IQ
Man you are amazing!!
I am a Eletronics Technician and watch you it´s just amazing ;)
thanks!
This thing looks totally awesome
since there is such a hype about this topic i would be quite interested in how certain machine learning techniques could be incorporated into this project. so may have some neuronal net figure out the best parameters and timing for all this balancing stuff. just leave it running over night or so (probably faster to run a simulation and upload the trained neural net)
have you thought about having an overhead gantry for the robots and have you thought about i2c communication between the arduinos or even learning how to use a FPGA that's what I am doing
I wonder if a gyro of some kind would help the OpenDog stay passively stable. Worth a look, do you think?
T-nuts are fiddly, I'd recommend T-slot spring-nuts, You just roll them into the slot and they stay there because of a spring-loaded ball-bearing.
As for upgrades, if it's speed you want, you could try STM32s, they're 32-bit and a fair bit quicker, plus they can be programmed with the Arduino IDE that you're familiar with.
Or could even try a Beaglebone Black with its two 200MHz microcontrollers and 1GHz CPU in one tiny package with a ton of GPIO. The PRUs in the BBB were made with high-speed, timing-sensitive communication in mind.
Having done something similar but a lot more primitive many many years ago I can appreciate why you stopped here. You will end up chasing errors and compliance issues for a long time with small incremental improvements. At some point in time you have to say it is what it is. This is about what I am going to get.
I think you should do the plastic-to-metal upgrades first. Many "wobbly" issues may disappear without any code changes, due to the stiffer material (fewer vibrations/harmonics).
Try a teensy 3.5 micro controller. The only thing is that you may want to design and get a breakout board made, unless you find a pre made one.
Can't you use a support wire from the ceiling to the back bone so it doesn't fallover
Is it really dynamic stability? Looks like static, though actively-enforced stability
Maybe you need check electromagnetic bracks for bldc motor ... it will be fast stop motor and star move to different directions ...
Is it used PID controller? And whats sensor used? Thanks cool man
Would it be possible to adjust the settings of the Pitcontrolers with machinelearning? I mean, that's kind of the way dogs learn to walk too.
yes, but writing the machine learning software, and the physics simulation would be harder
well done James
I kept thinking that if it falls it could crush a small child or Volkswagon. I was nervous when you were kneeling right next to it while testing the motion.
Pick up a nice used treadmill and build up a simple support structure that can hold the dog with a rope hanging it from. That way you can eliminate the issues of balance while you work on the mechanics of walking and running
could you do a shock absorber like effect so the motors contract when touching the ground .
I mean you're probably not there yet. But could you use motion capture or at least animal based data to control the motion of the Open Dog? It seems like designing the dog around the motion would make the most sense.
Hi James, looking good so far.
It looks like the chasis is twisting a lot along the spine - could this be changing the geometry enough to make the calculations wrong for the ballance?
Have you calculated the centre of mass, and set the legs to be in line with it? Or have you designed it to have neutral balance? Or is it purely based on the tilt feedback?
What is the end goal for OpenDog? I'd love to see this thing running but I suspect just walking in more than one axis at once is a more realistic goal (e.g. walk forwards whilst turning).
Could you share Odrive library of arduino that you are using on your openDog project, please? I'm having some issue with latest OdriveArduino library. They are seem to not working properly for me. Example code is not working and when i send a message 's' through the Serial, it prints out "Executing test blah blah" and does nothing. Thanks.
A 200mhz chipkit wifire board would make an excellent upgrade to all those... Even a 40mhz pic32 is waaaay faster than an 8 bitter. Easier to program than arm also.
So cool.i appreciate it. can u make open Rhex?
I wonder what machine learning could do for the robot. You will have to export and assemble the dog parts in a 3d physics engine so that you can train it, and then use that AI model to drive it irl.
The most difficult part would be BUILDING That model. What is your goal? What are you going to train it to do? In this video he talked about how the robot is rigid and uses mathematical models, and Machine Learning is just the progression of that. But it's still rigid. You need to be able to write a formula that calculates just how good the robot is walking, and that is NOT an easy task for such a complicated problem like walking.
exactly what i thought. look for the videos from "code bullet" this guy does make ai systems do learn all kinds of things. i would think it could adjust all the timings and angles to make itself walk better and smoother.. but without a accurate simulation its propably not practical.. like learning on the hardware might need the robot years to learn.
(and also the whole robot is still so much in the basics... maybe its way to early to start such kind of fine-tuning... )
There are already AI simulations that have robots (in simulation) teaching themselves how to walk successfully. I don't know if any of them have been applied to real world robotics.
@@williamrutherford553 The reward function shouldn't be that hard for walking. And building the simulated dog would require the CAD models to be converted to standard 3d models. A physics system would handle the rest. Having the motors and other sensors properly mapped to a virtual environment would be a lot harder. And probably in the end some real life learning would be needed to refine the model. But one could get very robust and organic movements. Do note that boston dynamics do not use machine learning AI for movement.
@@mm-hl7gh I like code bullet too, but he doesn't really make AIs, he basically makes programs that brute force the result. His AIs do no learning, they just do a bunch of random movements/whatever and pick the best result using his objective function
Can you compare your awesome openDog Robot by weight and overall size to which real dogs? (comparison pictures in your next video update #14)
I wonder how much it would cost to start molding and replacing a lot of those parts with carbon fiber? I think some of the major issues (though, they really aren't major in the grand scheme) you're having are due to weight vs rigidity.
Yeah, the lag along that data path is pretty massive. Also, 20 Hz is a bit slow for the IMU to keep a system like that balanced. I don't know if there are ones that can be polled faster, but starting with such a slow sample rate is just going to make any delay in data to movement even worse.
You may want to add a bit of a shock absorber to the feet. In a real animal, the muscles and joints have some give and that pressure is sensed by the body to help with balance. I would also suggest using two pressure sensors on the feet so that the robot can tell if it is coming down on its toe, whole foot, or in between. This would make allow a simple adjustment algorithm to act on the kinematic model to give it better balance since it will know what angle it is contacting the ground at. Considering that quadrupeds have ankles, I would also add the ankles and give them the ablity to lock in place for if you want to try a running gait or a gallop. I think most of us would be happy with just walking and not bumping into things or being remote controlled. This is all bio-mimicry based, but why reinvent the dog when we can just copy it?
try the parallax propeller my dude, a bit of a learning curve but it has 8 simultaneous 80mhz cores with 32 digital io pins.
You should make the shoulders rotate, forwards and backwards, to get a wider range of motion
i've used for my projects the firefly rk3399, it is a 6 core arm proc with 2 gb ram and 16 gb usable disk space, it can run Ubuntu and android. the proc is pretty fast. perhaps its usable for this project.
Is there any chance that you'd give it a head/arm? Maybe even mapping it's surroundings (With a Kinect are something similiar)?
It's a bit early for that.