Intro

I get bored easily. I constantly require something to think about, to keep my mind busy, to keep it.. occupied. This is intended to be an occasionally updated info dump of whatever projects I'm working on.

Will this become a business? Perhaps, but I doubt I'll sell hardware - software is more likely. We will see. For now, I intend for my custom hardware designs to be open source, if posted.

Hexapod Controller

For whatever reason, I have never found a board for controlling RC servos that I really liked. I don't know why, but the things I think of as important, battery and power usage monitoring, high current and adjustable servo power, MANY servos, compact design, reasonable servo connector layout, are never quite in the right combination in off-the-shelf solutions I've been able to find. Of the three or so reasons you can justify doing anything "custom", the main one here is, it doesn't exist elsewhere. Compromises necessary in off-the-shelf alternatives exceed the value of those solutions.

The Freenove Big Hexapod Kit is a lot of bits and pieces for not a lot of money. It's not quite perfect, and could use... an upgrade. As I sometimes do, I get a thing, I don't like something about it, and so I change it. This kit needs a little improvement!

Power swap to RC LiPo Battery and per-cell monitoring, for starters. As stock, it uses 4 x 18650 batteries on dual 2 cell holders, with each pair separately supplying the hosted Pi board and the servos. There are 4 DC to DC converters at 5v and 3 amps each, 1 for the Pi, 3 for the servos, on the stock board. The servos could use more than 9A, so my board includes a 20A DC to DC converter for the servos. As Raspberry Pi requirements seem to be on the rise, and I intend to run 2 on this bot, the Pi-powering DC to DC converter is good to 12A.

The included ADS7830 ADC uses clock stretching mid-transmission, which is ultimately NOT compatible with the SMBus-focused I2C implementation for the Pi on Raspbian. For starters, communication fails 1% to 10% for samples requested from the ADC, and worse, sometimes results are entirely bogus. It's only an 8 bit ADC, so it's not quite what I'd call precise. Further, of the 8 ADC channels it provides, 2 tie to each of the 2 battery pairs, 3 are tied to DC to DC outputs, and the other 3 aren't even broken out. My solution is to use an ADS1115, which does NOT use any clock stretching. This is a 16 bit ADC, and I intend to monitor per-cell LiPo voltage. While it only has 4 inputs, and 2 are to be used for per-cell voltage monitoring, the other two are at least brought out to pins.

Pi Eyes

Adafruit offers free software and some not free hardware options for "Uncanny Eyes" / "Pi Eyes", which is an implementation of graphic eyeballs on one or two display panels. I like the effect, and I see a use case: Eyeballs on a Hexapod. The motion possible on 6 legs can be expressive, a set of eyes will most certainly be more so.

My take on the hardware is to use a Pi 3A (space savings) with a custom board (two "EYESPI" connectors) for a tight fitting yet decently fast implementation. Getting a newer-gen Pi 3A working on Raspbian Bullseye was not without trouble. The PMC chip was upgraded on the board, meaning "firmware" on the Pi needed to come from a newer version of Raspbian. All of this worked out, and I was able to get things going.

The custom board is designed and on order, and presents: an Ultrasonic interface, good for trig / echo OR rx / tx ultrasonic boards commonly found on the 'net; a "host" I2C connection (for add-ons), and a "client" I2C connection (to be used to control the eyes and peripherals from the "main" Pi board).

IoT Stuff - General Info

I'm not a fan of IoT, as it exists today. Too many proprietary systems gathering too much info, using crappy apps that may not persist, using "cloud" backends that can vanish when a biz fails, or simply being at the mercy of some corporation that answers to someone other than customers. The state of "IoT" today is, in my opinion, an absolute WRECK. The idea that a site can get hacked and my oven can be made to burn my house down, or that someone else can control or take over ANYTHING thusly connected, is... well, that needs to be nigh impossible. Cloud solutions today don't guarantee / prevent ANY bad things from happening, though may cause bad things to happen, or at least NOT cause GOOD things to happen, without any recourse.

A better solution, the only one I really consider viable, is "disconnected" systems. Holes and compromises will happen in online systems. If these weaknesses exist in "offline" systems, in disconnected systems, where is the threat? What data will be compromised? See my point?

What I intend to do "differently" from existing home automation solutions is more in line with industrial automation - a tag-based interface within a landscape of clearly defined systems. Don't get me wrong, industrial automation leaves a LOT to be desired, but as a model to consider as an example from which to build a new system, it's better positioned than anything I've seen for home automation!! I'm hoping, in my efforts, to hit on a thing that suits both problem domains, since they're effectively no different.

I find it striking that IoT "things" aren't the least bit compatible, specifically with "things" needing their own separate "app", with many devices often requiring direct internet access. My short answer for how to solve this is, don't buy such systems, let them die on the vine. The "right" answer simply doesn't exist... yet.