Close
0%
0%

Tote Robot Leg

Use smarter legs for your robot.

Similar projects worth following

We are well into the twenty fist century, and we still don't have those small robots scuttling around and taking care of all the small maintenance tasks. We do have some robots, like the vacuum cleaners and lawnmowers, but they are very simple and limited — the main limitation being wheels. At the same time, four-legged locomotion seems to be a sweet spot for a small robot — it requires few enough part to be cheap, while at the same time is robust and repeatable, at least with the statically stable gaits. We just need to research it more, to find all the engineering tricks that make the robots reliable and cheap. To speed up the process, we need to crowd-source it — make more people experiment with small walking robots, so that the chance of discovering improvements is higher. And to do that, we need to make building those robots easier and cheaper. That's where I come in.

Inverse kinematics is the bane of walking robot builders. That fiddly trigonometry is hard to get right, and then you also have to take care of the correct movement profile and generating the servo signals over time to execute the motion. Why not use legs that have a tiny little microcontroller built into them, which takes care of all that stuff for you?

Just attach them to your robot, connect them over I2C, and send commands telling them to what position they should move. The leg will take care of it, without you having to worry about it.

But there is more. Hardwired movement is not good enough for your robot. Give it the sense of proprioception! By attaching additional wires inside the servo, you can turn it into an encoder and a force sensor. This way your robot will always know what positions its legs are in, and what forces are acting on them. Why is this useful? Well, you can make it respond to pushes and shoves, you can detect when it's about to walk off a table, you can can make it stand up after being flipped over, etc.

  • Researching STM8

    ꝺeshipu06/02/2018 at 21:34 0 comments

    As I mentioned previously, generating 3 PWM signals for the servos with the Attiny44 is certainly possible, but requires some coding gymnastics, which I am currently not in a mood for. So I decided to finally explore the STM8 chips that have been lying in my drawer for some years. Specifically, I have the cheap STM8S003F3. It only requires one capacitor as an external component, so I got it to work pretty easily:

    As you can see, I got the blink going, using the excellent examples from https://github.com/vdudouyt/sdcc-examples-stm8 (I just had to switch the pin from PB5 to PD5, probably because I have the wrong header file for my chip).

    Next steps is getting I2C to work and getting the PWM to work (there is an application note about getting 3 PWM signals with one timer at http://www.st.com/resource/en/application_note/cd00296680.pdf).

  • Servo PWM Dilema

    ꝺeshipu06/01/2018 at 08:41 0 comments

    The second big part of the firmware, apart from the I2C communication, is the generation of PWM signal for the servos. With three servos I don't have enough timers to just use straight PWM (and they don't have enough resolution), so instead I'm going to use a single timer with an interrupt that toggles the pins in software. But that introduces a problem. Since the AVR chips can only handle one interrupt at a time, if there is some other interrupt happening just when my servo interrupt is supposed to happen, it will get delayed and I will get some jitter. How can this be avoided? In my #Servo Controller I worker around that by not having any other interrupts — but here the USI code uses interrupts to handle I2C.

    I'm now facing two options: either rewrite the USI code to use a busy loop and poll the flags, instead of using interrupts (which should be doable, but will require rewriting the whole I2C-handling part), or, if that fails, switch to some other cheap chip. I'm kinda tempted for the latter, since I still have a bunch of STM8 chips lying in my drawer, but I think the project would actually be better off using AVRs, since they are so popular and well known.

  • First code: I2C Slave

    ꝺeshipu05/19/2018 at 13:09 0 comments

    It's high time to start writing code for this. I decided to start with the I2C slave implementation, because that will let me debug all the rest. The limited resources mean that I can't use the Arduino libraries, and instead have to write it all in C. Fortunately, there is an example code for using the USI peripherial for I2C communication published by Atmel that I can use directly. It goes something like this for now:

    #include <stdbool.h>
    #include <stdint.h>
    
    #include "USI_TWI_Slave/USI_TWI_Slave.h"
    
    
    #define I2C_ADDRESS 0x20
    volatile uint8_t command = 0;
    
    
    void on_i2c_transmit() {
        switch (command) {
            default:
                USI_TWI_Transmit_Byte(command);
        }
    }
    
    void on_i2c_receive(int count) {
        if (count) {
            command = USI_TWI_Receive_Byte();
        }
    }
    
    void main() {
        USI_TWI_Slave_Initialise(I2C_ADDRESS);
        USI_TWI_On_Slave_Transmit = on_i2c_transmit;
        USI_TWI_On_Slave_Receive = on_i2c_receive;
    }

    Simple, isn't it? Of course I still need to implement all the commands. Bad news is that this code already uses 800 bytes of the 2048 bytes I have available on the ATtiny24, which means that I will probably need to switch to ATtiny44 very soon. Fortunately I have some in my drawer, so that's not a problem. 

  • Why?

    ꝺeshipu04/22/2018 at 21:21 0 comments

    It's hard to hide the fact that it's 2018 and we *still* don't have many *actually* useful robots in our homes. You know, the kind that skitter around and do maintenance work. Sure, we have robotic vacuum cleaners now, but those are right now extremely simple and limited in where they can get. To really advance this area of technology, we need reliable and cheap walking locomotion.

    Bipeds are of course useless. Humans are bipedal because we needed a fast and energy-efficient means of locomotion to be able to chase our prey to death, but this is really sub-optimal for the kind of work that tiny maintenance robots do. Hexapods and more are common in nature at those sizes, but wasteful — you have to remember that every servo motor is extra cost, weight and failure point. Quadrupeds are the optimal choice. Four legs with at least three degrees of freedom in each let you have precise, statically-stable true walking on any surface, with a stable vehicle platform for any tooling needed. Speed and energy efficiency are secondary concerns indoors with a charging station nearby. So it seems we should be investing in research in quadrupeds. But how?

    You get the best progress when a lot of different people are trying a lot of very different approaches, iterating fast. This would be prohibitively expensive with human-sized or even dog-sized robots, but guinea pig-sized robots, which is what we ultimately want for maintenance tasks, seem to be doable. But how to get a lot of people to experiment with them? By lowering the barrier to entry — both in terms of cost, as well as in terms of skill and time required to get the first prototype to work. That was the reasoning between the #Tote project, and its later iterations. However, that project failed in one important way.

    People don't want to re-build a project someone designed for them. People generally want to to build their own robots, with their own unique designs, their own ideas, and their own execution. There were a number of projects inspired by Tote, but I don't know of any instance where it was actually built as a platform for further experimentation. It simply doesn't work that way, it seems.

    So now this is an attempt to tackle the problem from a slightly different angle. Instead of providing people with a ready design to build and extend, I plan to provide them with some building blocks that solve some of the main difficulties in getting a quadruped walking. I'm starting with a leg controller, because this lets me handle the problem of inverse kinematics in a transparent way, at the same time providing some base for further experimentation with proprioception.

    Of course for this to all work two conditions have to be met: the project has to be open, with everything available for modification if necessary, and it has to actually get used. For the latter condition, Hackaday Prize is a good opportunity to get the word out there, especially if it somehow manages to advance to the second round. Of course there is also a third condition, that the project has to work, but that's a requirement for any project, so it doesn't require mentioning.

    Now, how do I do that? At some point, while experimenting with Tote, I came up with a way to use the extra old PCB as parts of the legs by cutting them into strips to which the servo horns can be attached. Then it occurred to me that I could put some components on those boards to reduce the number of wires. In particular, I could have a chip in there that generates the PWM signal for the servos, so that all the servo wires can be short and connected directly to the leg, while the leg itself only needs a few wires for signal and power. And if I used a bus, such as I²C, I could have all those wires shared between all the legs. That is the basic idea behind this project. All the rest is extra, but of course I hope I can do it.

  • First Assembly

    ꝺeshipu04/16/2018 at 13:13 0 comments

    The PCBs arrived a while ago, but I've been busy with other projects. Today I finally took the time to assemble it:

    There isn't really much there. The Attiny24, a few pin headers, a grove connector, and the servo horns. I will probably move the grove connector on this side of the PCB, next to the servo pins — but mounted flat, soldered to SMD pads instead of holes. This way the back side of the PCB will be flat and the pins won't interfere with the servo horn. Here's an assembled leg:

    So I think that mechanically I have it pretty much where I want to have it, the next step is software — first, PWM and I²C, and then the more advanced features, if they fit (I might need to switch to Attiny44 at some point).

  • First Stab at the PCB

    ꝺeshipu03/16/2018 at 14:14 1 comment

    Last night I couldn't sleep, so I did what I usually do in such a situation — designed a PCB.

    From this quick and dirty attempt I already see that either I will need to make it bigger, give up on the standard servo sockets, or get really creative with edge mounting them.

    Or perhaps forget about the idea of making the PCB a mechanical part of the leg, and design it on a normal PCB that just get attached to the leg with some mounting holes.

  • Mechanics

    ꝺeshipu03/15/2018 at 23:34 0 comments

    I already tested the idea of using a PCB for the femur of a robot leg:

    This solves a number of problems at once:

    • The leg is more rigid than with just the servo horns.
    • The leg has predefined size and shape.
    • Cable management becomes much simpler — you only need 4 wires for all legs  instead of 15 per leg.
    • Debugging is easier, as you can test each leg separately.

    However, there are still some problems I need to find a solution for:

    • Each leg needs a different I²C address, but I have no free pins to do address selection. For now the addresses will be hardcoded in the firmware, and to change them you will need to reflash the chip.
    • I am not sure I can fit all the servo sockets on such a small PCB.
    • Even if I do fit them, the default servo cables are way too long — it might be easier to just cut them and solder the wires directly to the PCB?
    • No free pins mean there is no debug output from the chip — maybe I can have a debug mode when the analog pins are not used?

    Further research is required.

  • Pins

    ꝺeshipu03/15/2018 at 01:16 0 comments

    I'm going to use an attiny for this, but the usual tiny*5 doesn't have enough pins to do 3 servos, I²C and possibly also all the sensing, so I think I'm going to go with tiny*4. Here's a pinout of one of those:

    We can use 11 pins. Pins PA4 and PA6 are going to be used by I²C. The remaining 6 analog pins are needed for the sensing of the three servos, one for the pot (position) and one for the motor (force), for each. That leaves PB0, PB1 and PB2 for the servo output. PB3 is not usable without the high-voltage programmer, so I will leave it for reset.

    But wait, the PB0 and PB1 pins don't have any timers associated with them! That means I will need to generate the servo signal in software. Fortunately at 50Hz that should be doable. There is going to be some trickery to make sure it's not disturbed by the I²C communication, though.

  • Prior Art

    ꝺeshipu03/12/2018 at 17:19 0 comments

    This is going to be based on my work on the spider-like robots such as #Tote and #D1 Mini Tote. I will also probably re-use the code I wrote for #Mechatronic Ears' servos and for #Micro:Boy's buttons. The proprioception stuff will hopefully let me realize the goals of #Ensmarten Your Servos.

    I plan to use an ATtiny24 microcontroller, and a long thin PCB with servo mounting holes, that can double as a physical part of the leg's construction. Communication over I²C, probably with Seeedstudio's "grove" connectors.

View all 9 project logs

Enjoy this project?

Share

Discussions

Bharbour wrote 03/16/2018 at 03:10 point

There is a lot of appeal to keeping it to a single chip if possible.

I got that trick from digging around inside a few RC receivers, and it worked well with what I was trying to do with my project.

  Are you sure? yes | no

Bharbour wrote 03/16/2018 at 00:19 point

If you are willing to add another IC, the 4017 is a 1 of 10 counter that you can use for servo driving with only 2 signals, a clock and a reset. After Reset, output 0 is high and the other nine outputs are low. Each time you pulse the clock, the next output goes high and the current one goes low, up to 9 times or until you hit the reset signal. I did a servo controller for 9 servos driven from the PRU in a Beaglebone, and it worked well.

  Are you sure? yes | no

ꝺeshipu wrote 03/16/2018 at 01:09 point

Nice trick, but I think I will try to keep it as simple as possible for now, with a minimal parts count. I can also always switch to a bigger chip, like attiny23...

  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