ArmyrHex

It took a while, and the construction is rather fragile, but the Lego table finally got its internal lighting working. The idea is to make it easier to see the pieces even without pulling the drawers all of the way out.

The result was highly appreciated by the users. 😀

So as we will be moving to Bangalore for a year, and I cannot bring an entire electro-mechanics lab with me, I had a pretty hard deadline to wrap up the hex project one way or another.

So I set myself the goal that I wanted to capture a film of the thing walking. That meant that all of the components had to actually be in place and working together. It took one full day of work, but here it is!

So yeah, it looks like a drunk dog trying to get home after having been hit by a car….. So not that impressive. But I am still super-happy because I have learned so very much, and I am still super-pleased with the visual design of the robot.

Lessons

First some super-specific things I learned:

• CNC-milling in aluminium is HARD! Especially without a tool changer and on an old machine with only a weak mister for chip evacuation.
• FDM 3d-printing with PLA combined with threaded inserts is awesomely simple and practical.
• Wire wrapping is also totally practical for prototype boards.
• Test driven development is the only way to fly in software. Especially on an embedded platform without a debugger.
• Cogging Torque was a thing I had never heard of, but it is the thing stopping this robot from not looking like it has nerve damage. So always check that when buying a motor.

But seriously

To take a slightly more serious spin, here is a summary of the project in terms of what it cost me and what I gained.

• I have spent at least 4 hours per week for three years on this project, and probably more. So at least 750 hours in total.
• I have spent at least 20 000kr just for parts.

I have had to make use of the following skills:

• Dynamics simulation in Matlab
• CAD-design in Fusion 360
• Stress analysis and torque stability simulations
• CNC milling
• CNC machine service including replacing the drive screws and motors.
• Planning order of operations in assembly
• FDM 3d-printing
• Laser cutting
• Plywood and nail gun rapid construction
• Wire wrapping and soldering
• Electronic signal analysis
• Low-level programming
• Test-Driven Development
• I2C communications

What would I change next time?

Not much in terms of process. Of course I know more now and would avoid a lot of dead ends, but I have no regrets. But there are some parts of the robot that should be changed if I ever pick up this project again and have lots of money.

• New large-diameter motors with minimal cogging torque so I can move precisely at slow speeds.
• Better power connectors as these jammed a lot.
• Connecting the driver boards with USB so they can all be reprogrammed in a CI/CD workflow.

Farewell

So with that, it is time to say goodbye to the Hex for now. We had a good run, you and I. I will miss you. 🥰 😢

I am running out of shirts again. So I bought some new ones and I felt I had to add some quotes to them. Dare to be different. Dare to be brave.

I also learned an important lesson about sharp tools (again). The first cutouts of the text refused to properly detatch. So I sat for over an hour with a scalpel trying to detatch the letters one by one. Finally, I gave up and replaced the knife. Fifteen minutes later I was done with both cutouts. Lesson: Keep your tools in good condition.

At the end, I had about an hour to recut my controller board to the right size and move some of the components to actually fit. Fortunately, with a professional heat blaste, desolder and solder iron, I was quick work. I really need to get a more powerful solder iron for my next project.

The robot is build with four independent circuit boards. Three of them are driver boards that power and control one leg pair each. Each driver board contains a dual motor driver and one Arduino. The Arduino is programmed with the low-level logic to drive the legs, including a PID, homing encoder support, etc..

However, the way this robot should walk is that the two opposite tripods walk together. So something needs to sync the three driver boards. This is where the controller board comes in. Right now, it only has a single Arduino on it, but I have space for a Raspberry Pi Zero are well for future expansion.

The idea is that this controller board should send step commands to the driver boards via i2c. The first time I tried to get an Arduino to speak i2c, I got wierd results that I did not understand.

So off to the Makerspace to hook up an oscilloscope and see what was actually going on. It turns out that the pull-up resistors really were necessary to get decent signals, and apparently an i2c master should not send data unless the correct slave acknowledges that it is listening.

Below we see the little Arduino calling out all properly to its slave device, but getting no answer so it falls silent….

Some soldering and wiring later, the controller board was ready and I could hook it up to one of the driver boards. Some coding later, and the two boards can now send data between each other. I believe that the oscillosope display says “Hello World!” 😛

Yeah, so it happened.

First I made an improvised fire-proof charging station. I wonder if the people who cast this pot literally almost 100 years ago could have even fantasized about the kind of battery power we have access to today….

So attaching two legs and the battery, I finally managed to get the thing to walk across the floor…… 😀

… Yeah, I might not exactly have paid the royalties for the music in the background….

I spent most of February and early March rewriting all of the code to have clean structure and complete unit test coverage. Unfortunately, there are only so many screenshots of code that you can show before it gets boring…. But a small contribution map from GitHub will have to suffice.

Now the code is clean and I have a gait commander that can control each leg individually. Unfortunately, I noticed that one leg was not behaving at all. And then my Makerspace lab access expired and it took a few weeks to get it back.

Finally, I could use the oscilloscope to diagnose the problem. It turns out that the detector pins for one leg were connected in the opposite order as compared to what I had assumed. So the encoder homed on every click of the encoder. Not great. But at least, all of the motors and all of the driver boards are now thoroughly tested and there is no electronic noise or any vague digital signals anywhere in the system.

So from now on, I just have to worry about software and mechanics, which is nice.

Having reconfigured the pins and reassembled all of the pieces, I decided to let the robot try to crawl forward for the very first time. It bravely started taking a first step. And then all of the microcontrollers reset. My assumption is that the power source simply cannot power the motors under any form of load. The power source I use delivers a maximum power of about 12W. But each motor has a stall power of 60W, so I would not be surprised if there is a voltage dip when two motors push off from the ground that causes the controllers to reboot.

Clearly, I cannot continue development if the robot cannot even take a single step with only 2 motors. So I ordered two 7.5V 1Ah LiPo batteries and a charger. Connecting them together gives me around 15V, which is plenty to power the motors. With a max discharge rate of 25C, I will have access to a peak power of around 375W which should be plenty.

Since the system is now powered by more than 12V, I have to do some limitations in the software to not overheat the motors. But they should survive bursts of more than 12V, which is all that we will see as the legs will not spin at max speed continuously.

My weak soldering iron wasn’t too happy about the massive power leads from these batteries, but with some patience I finally had a serial coupling and could connect the power connector that I use.

I haven’t had the opportunity to test this more than to see that the system boots up when powered by this battery, but I have high hopes.

So I had an idea that maybe my ugly welds were due to poor electrical contact or some chemical reaction to surface impurities. So I redid the exercise from before where I cut a pipe and then try to weld it back together and make it waterproof.

The difference is that this time I took the angle grinder and really polished all surfaces to a glimmering shiny new-steel surface. That gave a clear improvement! But I also realized that if my current setting was too low, that also caused sputtering and ugly welds. So I turned the current up a step as well, and then I really got things going.

The lower welds came out really nice. The upper ones started off ugly, but then I ground the ugly welds down, and turned up the current. Still not so pretty, but here we clearly have two water-tight welds!

First some background. One of the great gifts my parents gave me was sorted Lego. Not just Lego, but Lego that was sorted into a logical system so I could easily find the piece I needed, when I needed it. Of course, the big investment from them was to help me keep it sorted and in order until I was old enough to do it myself, which took quite a few years…

I have chosen to pass that gift on to my kids, but there is one problem. Lego these days is more complex than it was, and also relatively cheaper, so my kids have more Lego than I ever had. I had 3 sorting boxes. They have about 10. The limit here is how many boxes can fit on a table that fits in a room. For the sorting system to make sense, all pieces have to be “within reach”

But then they got a few more semi-large sets, and now there is no hope at all to have it all within reasonable reach on a table. So it was time to go to the next level. And this is that level.

The requirements were:

• Space for at least 15 sorting boxes, preferably more.
• The contents of all boxes has to be visible and reachable for a 6-year old, without having to open and close lots of drawers

And this was the resulting design. The idea is to build two of these and place them back-to-back.

With this design, I can fit a full set of 18 sorting boxes. The spacing between the shelves means that a short person hopefully can look down and see what is in which box. Each shelf can then be pulled out to find the specific part if it isn’t immediately visible.

So here are some work- in progress images:

The resulting frames were to big to fit in our car, so I had to get a rental to get everything home.

Now I just need top it it all, something I have realized will take way longer than the cutting and the assembly. More on that later.

Before I can assemble the shelves, I also need to get the sliding extenders that I have ordered. They should be here within a week, I think.

So I decided to give welding one more go. Not because I have a project in mind, but simply because I was not in the mood for thinking about anything difficult.

Yeah, I can also procrastinate. Writing embedded code with full test coverage isn’t a walk in the park… or, it is. But programming the functionality I need isn’t.

So I took a square pipe, cut off three “rings” and then welded them back together with a plate as a bottom. How hard can it be?

Well, getting them to stick together isn’t much of a challenge, but making the resulting container water proof… now that is a whole different story.

What I can say is that the picture above is the second pass I did. First I welded all of the pieces. Then I used an angle grinder to smoothen out the welds and to be able ti see if I had missed anything.

I was quite confident filling it with water. And then all of the water simply dropped out. More than a dozen leaks. So I went over all welds a second time creating broad and solid welds. I fortunately that just made a small difference.

This thing still leaks a lot. And not just in the welds they look a bit iffy. It leaks from the ones they look solid too.

So yeah, I still suck at welding. 😀