Greeting's sire

This is mostly a code refactor update, however there are some new thoughts/directions I'll mention.

Initially I was driven to refactor the code in hopes that I could easily mirror the existing gaits to have full 2D control eg. the missing move backwards/turn right. However... this did not go as planned. The mirroring of the default stance >= to =< made the robot also move forward... so I think ultimately I'll have to figure out how to turn without doing that mirroring, or improve that mirroring so it doesn't move forward. Similarly I wanted to improve the gaits where they're not hardcoded (did not happen) by simply specifying the degree coverage to move and direction... with regard to refactoring, what I ended up doing was changing the direct Servo bindings to a bunch of struct instances (legs) so that I could add additional info to each servo like the max/min position based on geometry. Then I added a safeServoWrite function to guard any incoming servo write commands. Largely though the code refactoring was just moving code around/organizing the files.

As part of the min/max positions I added a manual web-based command to target specific servos and move them... this is not really hard, just sending/parsing a string using the existing websocket connection. What sucks is the single-threaded aspect of Arduino so I have to rethink how to structure my code so that I can do the main/general processing but also listen to incoming web commands... because right now the web commands are blocked during the navigation/motion part of the main loop. I could also do a scheduler, where the messages are not removed/in pending state until the robot receives it/responds.

Continuing on... while I was letting it roam around, it flipped over (not the first time) and this gave me the idea to implement a "help I'm stuck" feature that would ping the web. Similarly if it dies from too much current draw (like running into something) it will notify the web interface that this is happening. Continuing with that thought, the progress/motion measured by the IMU will also be factored into this. It's hard because the robot shifts back and forward so trying to get a "forward distance covered" value from that, which is positive/reliable is tricky. Although it does work, I did some sample work with that at some point. Generally I want to make the code make more sense/better structure. In the long video below I'll discuss that.

I'm also working on the actual web interface, not just random bits. I don't really have a solid design in mind yet. I am thinking tabbed interfaces and then I want an event stream (from the socket bridge).

Mostly this robot is problematic because I can't trust it to be on its own. Since the sensing ability is crude and it will damage itself by running into things/burning out a servo. That's the overarching goal/design/purpose of this thing is to self-navigate and then stream its state to the web.

In the long run this robot is flawed because of manual programming of the servos... every time the servos are adjusted the change propagates into several places (motion and pan/tilt gaits). I have to trace it to make sure the servos do not jump/skip positions for smooth operation.

Long video below

Closing

I'm trying to get the "pump" (interest) to keep working on this project. I'm also learning other technology too on my spare time but I'd like to "close" this out. Though I don't think I will until I design/build a better one. There is still so much work to do/more things to dive into and improve.