• Inverse Kinematics

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

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, and possibly sending them over WiFi or even processing them on the chip. It can also be used with the Pico, but then what will I do with the image, without connectivity?

I'm currently leaning towards the S2 Mini, even though I haven't yet figured out how to place the board on the PCB so that the antenna is not next to the servo motors. I'm still waiting for the boards I ordered to arrive, though.

• Cable Management

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

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

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

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.