Close
0%
0%

Fluffbug

Cheap four-legged insect robot

Similar projects worth following

This is a continuation of the journey started with #Tote to create an affordable walking desktop robot.

What is this?

It's a four-legged walking robot that fits on your desk, can be programmed with an USB cable without installing any special software on your computer, can be built on a budget of less than $30, and that can be easily expanded or modified, to try out new ideas. Those are the basic requirements I have set myself for this. But why?

Why am I doing this?

Because I think that the details about how such robots are able to walk, without crawling or dragging on the floor, are very interesting, and that making a physical robot work is the best possible way of learning about it—fun and rewarding. There is a big hurdle in getting into this—most of the robots you could get are either super-expensive or simple toys with hard-wired gaits. There are now some reasonable kits out there, such as those robots made by Petoi, but I think I can still do better than that in terms of both affordability and removing other barriers.

Why is this hard?

Building a walking quadruped is surprisingly easy—once you know how. You literally just need any microcontroller development board, battery, a bunch of servos, ice cream sticks and hot glue. A few hours of work, and a few weeks of banging your head against a wall while trying to get it all to work, and you are done. That's the easy part.

The challenging part is designing and documenting it all so that it can be repeated or modified and expanded, without wasting time, and with as little frustration as possible, and on a budget. This means I don't only need to get it to work, I need to think about the best ways of getting it to work, and then about the best ways of explaining them.

When will it be finished?

Probably never. That doesn't mean it won't be usable. I hope to get it to a point where it can be built by others as soon as possible. But it's one of those projects that are never completely finished, because the context in which they work keeps changing. New parts become available, such as new microcontrollers, sensors or even servos and batteries. Others become obsolete or otherwise hard to obtain. New fabrication techniques, such as laser-cutting or 3D-printing become feasible for an average hobbyist. There might even be new materials on the horizon! And the fastest changes are in the software tools available—a few years ago the only ways you could program a microcontroller was assembly, or maybe, if you were lucky, some limited version of C. Today we have Python code running on them in real time, with a lot of ready libraries, and new capabilities appear every month. I probably won't be able to incorporate it all in the design, but I fully intend to update it as new possibilities emerge.

  • Selecting Pins

    deʃhipu09/23/2021 at 11:44 0 comments

    Before I finish the new PCB I need to make some decisions. In particular, I need to decide which pins of the microcontroller are going to be used for what. At the minimum I will need eight pins for controlling the servos, so let's start with that and see which ones are suitable for that.

    I connected a servo to he development board, and created a PWM object on one of the pins, with 50Hz signal and duty cycle of about 4000 — that is close to the center of the servo position. It worked at first try. Some more tests let me conclude that I an use any of the pins for the servos, but I can only create eight PWM objects at a time, which is just enough, but which means I won't be able to use PWM for the speaker or for any LED fading or things like that, which is a bit of a shame. I might reconsider adding the speaker.

    But there is one more constraint that I need to consider: I would really want to have a camera shield for this robot, with the OV2640 camera. And it would be bad if any of the pins I picked for the servos were required for the camera. So I need to figure out which pins are needed for the camera. For this I have turned to Adafruit's Learn Guide on the subject. And again, it looks like I can use pretty much any pins there, as long as there are enough of them available.  Unfortunately, it needs a lot of them — from 14 to 16, depending on whether I want to have control over the reset and shutdown pins. The S2 Mini exposes 26 pins, 27 counting the LED. Let's see, I will need 8 pins for the servos, 4 for the leg switches, 14 for the camera, that's 26 exactly already. Ouch.

    It seems that it is just doable. We will see.

    In the process of this research I also collected the documentation for the OV2640 camera sensor and what is required for building a camera shield for the S2 Mini — but that is going to be a separate project.

  • Special Legs

    deʃhipu09/21/2021 at 20:13 0 comments

    In the previous versions of this robot I experimented with the mechanical leg segments made out of PCB, simply included in the design, with mouse-bite holes so that you can break them off easily. That made sense before there was easy and cheap access to laser-cutting: after all, the PCBs are being cut with a CNC router anyways, why not take advantage of it. Unfortunately today it makes less sense, as PCB fabs usually want you to pay extra for multiple projects in one design, and such a leg segment will count as a separate project for them. Laser cutting parts make more sense and look better. And the material can be less toxic.

    On the other hand, the PCB legs had one big advantage: you could put components on them. In particular, you could put switches at the ends of the legs, to give the robot a primitive sense of touch. Then you can program it to stop and turn around when it reaches the edge of your desk. Of course you need switches with very light springs in them, and relatively short travel — turns out that the switches that are normally used to detect if an SD card is inserted are perfect for this.

    So I designed an alternate leg segment, made of PCB, with a switch footprint at the end, and some traces going up to the knee. It won't be included in the main body PCB of the robot, I will simply order it as a separate order. It looks like this:

    Of course this is completely optional, but I think it's a nice option to have.

  • Rough Placement for the PCB

    deʃhipu09/20/2021 at 23:49 0 comments

    How do you deal with insomnia? I design PCBs when I can't sleep. Tonight is such a night, so I decided to finally take a first stab at a new version of a PCB for Fluffbug.

    There are quite some changes required. The SAMD21 microcontroller and all the supporting passives, together with the Feather headers go away. They are replaced with headers for plugging in a Wemos S2 Mini development board. The servo sockets get replaced with sockets for the ribbon cable plugs — they have the same footprint, but physically they are much larger and will require more clearance. The power switch, battery charging, battery protection and piezo speaker stay. I decided to remove the IR sensor, since we will have WiFi (or ESP-now) for communication.

    Next, there is the problem of placing all the components in a physically possible arrangement. The placement of the S2 Mini is the greatest problem. On one hand we want it to be central, so that any shields plugged into it can act as the robot's "face". On the other hand, we want the USB socket to be accessible, the antenna to be as far away from the servo motors as possible, and the reset and boot buttons not completely covered. It's a lot of constraints, and I came up with something like this:

    On the back of the PCB is the battery holder, and the two sockets for the ribbon cables for the servos. Since the battery is round, there should be enough clearance for the cables there. On the front we have the S2 Mini in the middle, with the USB socket to the side, and the antenna on the other side. Obviously a vertical arrangement would have been more convenient, but then the antenna practically touches the motors. The rest is just the power and the speaker. Since I have the room (the PCB has to be wide enough to fit the ribbon cable sockets anyways), I decided to place them all outside of the outline of the S2 Mini — this way I might be able to make the front of the robot pretty thin, and have more room for shields.

    The reset button is a bit hard to reach, but I should be able to press it with a screwdriver or something like that. The boot button (which I can re-use in the code as a user button) is easily accessible at the top of the robot.

    I might add an additional socket just above the servos, for connecting any sensors from the legs — we will see about that.

  • Inverse Kinematics

    deʃhipu09/13/2021 at 21:43 0 comments

    While I'm working on re-doing the PCB to incorporate all the recent changes, we can talk about the hard part: programming. Obviously, without a program the robot is useless, and if you want the robot to do anything, most of the work is going to be writing the program for it. This is why I'm trying to make this part as hassle-free as possible, switching to a high-level language like Python, and using a variant of it, CircuitPython, that makes it especially easy to modify any code, by exposing it as an USB drive. Another thing I can do so simplify things is to provide libraries that handle the low-level details, and expose a higher-level interface to the user's code.

    One of the details I can handle is Inverse Kinematics — that is, translating between the desired positions of the robot's legs, to actual angles the servos need to move to. This is a little bit simpler with the eight servo configuration than it was with the twelve servos of Tote, but it's still a little bit of tricky trigonometry.

    Let's look at a side view of the robot:

    We can see that each leg forms several triangles: a right-angle triangle formed by the coordinates of the tip of the leg, that lets us calculate a part of the angle of the first servo and the distance of he tip of the leg from the first servo, and the triangle ABC, which we then know all the dimensions of, and which gives us the remaining angles.

    So basically we need the Pythagorean Theorem, and then the Law of Cosines. In code, it looks like this:

            leg_length2 = x * x + y * y
            leg_length = math.sqrt(leg_length2)
    
            hip_leg_angle = math.acos(
                (FEMUR2 + leg_length2 - TIBIA2) /
                (2 * FEMUR * leg_length)
            )
            knee_angle = PI2 - math.acos(
                (FEMUR2 + TIBIA2 - leg_length2) /
                (2 * FEMUR * TIBIA)
            )
            hip_base_angle = math.atan2(y, x)
            self.angles(hip_base_angle - hip_leg_angle, knee_angle)

    We can add some error checking for out-of-reach points, some convenience code that lets us move by increments and flips the y coordinate, and we have a working leg. 

  • Brain Replacement Again

    deʃhipu09/02/2021 at 22:46 2 comments

    Since I am working on a new revision of the PCB, to incorporate the improvements suggested during the mentoring session, and some of the ideas I had since, I'm also wondering whether the choice of the microcontroller for this robot is still optimal.

    I have chosen the SAMD21 for several reasons: it runs CircuitPython, which is important for me, because I want this robot to be easy to program; it's a relatively cheap chip, and requires very few extra components; it has just enough peripherals to drive all the hardware that is needed; and, last but not least, I have become familiar with it through all the other projects I used it in.

    However, several years have passed, and situation has changed considerably. We are in the middle of a chip shortage, which not only changed the prices of the chips, but also their availability — meaning that even with the higher prices there is no guarantee of getting the chip I need. Development of CircuitPython has progressed greatly, and it's now available for many more platforms. New chips were released, alongside development boards for them. Perhaps it's time to re-evaluate my options.

    There are in particular two new chips that are supported by CircuitPython, relatively cheap, and available despite the global shortage: the ESP32S2 and the RP2040.

    There is one more change that is affecting hobby electronics worldwide — the European Union has started to crack down on the tax and certification regulations, which, while mostly unchanged, suddenly started to be enforced. Suddenly you can't just sell your hobby projects, claiming it's up to the buyer to ensure they fit whatever regulations apply — individual hobbyists are suddenly required to perform CE certification, register for VAT and WEEE, and conform to RoHS. All this taken together means that I will probably not be able to bring this project to users by simply producing a few dozen PCBs and selling them on Tindie. I will probably need to limit myself to just publishing the design files, and let the users order and assemble everything themselves. And this means that suddenly ready development boards look much more appealing than a bare chip in QFN form factor — not that it's so hard to solder QFN by hand, but people tend to be scared of it. So I feel like I should be looking at development boards, and not bare chips here.

    Raspberry Pi Pico is of course one of the boards that I am considering. Produced by the Raspberry Pi Foundation in bulk, it's actually cheaper than what I could make with a bare chip and required components. And unlike the Feathers, it has enough pins to drive all the servos and have a lot to spare for any additional hardware and expansions. Unfortunately, also unlike Feathers, it comes without a battery charging circuit, or even a power switching circuit, so the PCB for the robot would need to include both, in addition to the battery protection chip I already have there. The buck/boost converter is a nice touch, but it doesn't help me in this case, where I need to power the servos directly from the LiPO battery anyways. Another downside is a lack of shields for this form factor — they basically came up with their own thing. So I would either need to make my own shields for anything extra I wanted to put on the robot, or put additional headers for shields on the PCB, effectively making an adapter board. Both options don't sound so bad, but there is some extra consideration here.

    Another option to consider is the WEMOS S2 Mini. I really loved the D1 Mini form factor, and I have made many shields for it. This board is compatible with that, but it adds another row of pins on both sides. I could make the robot make use of the inner pins internally, and leave the outer ones to be used by shields. It also comes with wireless capability, which could make it much easier to control the robot, and even send telemetry back. To make things even more interesting, there is a new adafruit_ov2640 module in CircuitPython, allowing taking pictures,...

    Read more »

  • Cable Management

    deʃhipu07/31/2021 at 14:43 0 comments

    Cable management is a big problem when you have a moving construction with eight servos. It doesn't help that by default the servos come with relatively long cables, and this three-pin plug on the end, that is hard to replace without special tools:

    Of course it would be best if you could just take that plug and plug it into the PCB, but then you need to do something with good 20cm of extra cable.

    We brainstormed about this problem, among other things, during the hackaday prize mentoring session with Kliment Yanev, and he came up with an ingenious solution that just might work. Yes, you need to get rid of the default plug, and the spurious cable, but then you are left with the problem of either soldering the remaining cable directly to the PCB, or attaching a different plug. Turns out there are plugs out there that are very simple to attach, and quite popular and easy to get. Kliment suggested I can use the plug that is commonly used for the ribbon cables:

    They have those blades in them, that bite into the cable when you press the tab on top, and make a secure contact. Furthermore, we are not increasing the price a lot, because you can use a single plug for multiple servos. Sure, this makes them harder to replace, which is a downside, but I think I can live with that.

    Unfortunately, this also means we will need a PCB redesign — the way this plug connects with the cables, we will need a completely different pattern of pins for it. Oh, and we can't put the sockets for those plugs in the same place on opposite sides of the pcb, not easily, anyways, so I will need to think about where to best place them. But I like the idea and I'm going to give it a try.

  • Yellow

    deʃhipu06/11/2021 at 22:07 0 comments

    The version 3 PCB has arrived, and populating it wasn't too bad. I didn't even use the hot air gun to solder the QFN chip — just drag-soldering it on all sides did the trick.

    Along with the new PCB I also received the parts for the new design of the legs. They are pretty much the same as the old, but use a little bit less space. And I got them made in yellow acrylic, to match the PCB. I also managed to find some orange servos, and I dug out some yellow pin headers:

    I'm wondering if I should remove those white servo horns and spray-paint them black, to complete the look.

    Tomorrow I'm going to cut the servo cables and connect them to the board.

  • Version 3

    deʃhipu05/26/2021 at 19:11 0 comments

    The previous two versions of this projects were kinda done on the side of #Kubik M0 to see if this approach even makes any sense. I finally decided to go for it, so here is a version three, with a new PCB:

    and an improved design of the legs (to make them use less acrylic, so you can fit more of them on a sheet):

    The PCB now includes, apart from the previous microcontroller, battery protection, battery charging and battery holder, also a tiny buzzer and a place to install an IR sensor — this way I can report the status of the robot with beeps, and control it with a TV remote.

    Any further sensors and other hardware can be added as FeatherWing shields to the front of the robot.

  • Configuration

    deʃhipu05/26/2021 at 18:55 0 comments

    While the #Tote robot was close to what I wanted to achieve back then, it had two major problems. First, the servos, even though relatively cheap individually, contribute to the total cost of the project considerably, because you need at least a dozen of them. Second, Arduino, while popular, is not the best coding environment for experimenting.

    I have long worked on making a version of Tote that could be programmed with Python — starting with #Tote HaD, that had an additional ESP8266 on board, through #Tote Zero that had a whole single-board computer, to the most recent #Kubik M0, running CircuitPython. Unfortunately, with the last I ran into a problem with not enough PWM outputs available on the chip I choose.

    I have also experimented with robots that require fewer servos, but can still walk properly, without relying on the surface of the floor having the right friction. It started with #Katka, a mammalian robot#µKatka and #Pony Bot, and more recently some experiments with the #Kubik M0. Turns out that it is possible to make a robot with only eight servos that still has an insect-like configuration of the legs. It can walk properly, keeping its feet firm on the ground, as long as it doesn't have to turn — because it can't move its legs sideways. But even for turning is not impossible, with some cheating.

    So this is how I came up with Fluffbug — a bug-like robot with Feather-compatible (or #Fluff M0-compatible) shields. The tiny SAMD21 microcontroller has just enough PWM outputs to control the eight servos, and the small PCB works nicely as the body of the robot, with enough room for a 16340 battery, and s FeatherWing on the front.

    The initial tests are promising, and I already have the basic code with inverse kinematics written in CircuitPython. The next prototype is going to have a little bit more useful components on the PCB, and an improved designs for the laser-cut legs.

View all 9 project logs

Enjoy this project?

Share

Discussions

James Newton wrote 09/28/2021 at 22:56 point

Where is the source code, PCB files, laser cut, etc...?

  Are you sure? yes | no

deʃhipu wrote 09/29/2021 at 09:58 point

Everything that I made so far I described in the project logs. I'm still working on a version that will be easy to build and properly documented. But for your convenience, I created a repository with the work so far here: https://github.com/deshipu/fluffbug

  Are you sure? yes | no

Nopcode00 wrote 09/13/2021 at 20:12 point

Nice job. Do you have any videos of it in motion?

  Are you sure? yes | no

deʃhipu wrote 09/13/2021 at 21:17 point

Thank you. Sadly, I still need to program a gait for it, for now I only have the inverse kinematics. There is, however, a video of its predecessor, Tote: https://www.youtube.com/watch?v=XXotn-8DPQo

  Are you sure? yes | no

Nopcode00 wrote 09/13/2021 at 21:44 point

I’ll check it out - thanks. 

  Are you sure? yes | no

Makerfabs wrote 09/06/2021 at 07:35 point

hi @deʃhipu ...lucky day~

  Are you sure? yes | no

deʃhipu wrote 09/06/2021 at 09:06 point

What do you mean? Did I miss something?

  Are you sure? yes | no

Dejan Ristic wrote 07/31/2021 at 20:57 point

Nice! I'm all on board with the affordable desktop robot concept.
Color scheme makes me think of the camel spider. But this one seems much less terrifying luckily.

  Are you sure? yes | no

deʃhipu wrote 07/31/2021 at 21:39 point

Thank you. To be honest, I haven't thought about the looks too much yet — most of the design is dictated by the mechanical requirements right now. There is some room for expression here — shape of the legs, shape of the PCB, etc. I imagine that it could also be made quite terrifying depending on how it moves — if you can reproduce the movement profile of spiders, for example, I bet people would get goosebumps just looking at it walk. The color scheme is probably not final — I had some choice here, so I went with yellow/orange, but the final version will probably be blue, because blue servos are the cheapest.

  Are you sure? yes | no

Dejan Ristic wrote 07/31/2021 at 22:16 point

Well as long as it doesn't bite :D
I also like the minimalism with 4 servos making up the thorax of the spider.
And the forward facing pcb. I'm guessing you can put on a shield with a distance sensor then?

  Are you sure? yes | no

deʃhipu wrote 07/31/2021 at 22:39 point

Yes, the initial plan was to put one of those time-of-flight sensors on it, but of course you could also use that huge ultrasonic sensor if you want your robot to look more steampunk. In fact, I'm even considering an adapter-shield for an #OpenMV 

  Are you sure? yes | no

danjovic wrote 06/12/2021 at 13:56 point

Awesome, specially in yellow!

Have you considered to make the legs out of PCBs?

  Are you sure? yes | no

deʃhipu wrote 06/12/2021 at 14:08 point

Thank you. I have, and in fact the previous versions all had the legs made out of PCBs, however, since the fabs nowaday charge extra for multiple projects in one order, and the leg parts look like multiple projects, this is no longer economically feasible. On the other hand, cheap laser-cutting services mean that you can get enough legs for three robots for less than the PCB, and it gets even cheaper in bulk.

  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