Strategy Update

Since the beginning of this year untill now I have had exceptional progress on the OctoMY™ project, in large part thanks to the few bold goals set in the beginning of the year.

I have managed to deliver on this plan, and I consider this strategy change was a success. By maintaining motivation for development and also digging the project out of some really bad places, it is now in a much better shape. So where is the MVP?

During the process many bad things have come to light both from architecture but also from a code perspective, which is good. And most of them have been mitigated somehow, either by refactoring, removing or rewriting, which is awesome! But one big issue remains which has proven hard to fix; the asynchronous stores.

At some point in the distant past I decided that I needed a generic component that would allow me to access data asynchronously. The problem that prompted this was keystore. Generating a key takes several seconds, and large parts of the application are useless unless there is a key present. However, having the UI pause for several seconds at start up was rightfully deemed unacceptable, so I created a way to generate the key in a background thread and wrapped all access to the key in a layer of futures with stored list of callbacks. So if you wanted the key, instead of doing


myKey=keystore.getKey();

you would do the following:

keystore.getKey().onFinished([](myKey){ /*do whatever with the key*/})


While this system seemed simple enough, it soon became clear that the implementation would be non-trivial. How could I ensure that the callback was executed from the same thread that booked it?

In Qt this is very important. Also I decided that I should use this fancy new asyncronous API for other parts of the program, not just keystore. Before I knew it it had bloated up and become difficult to manage. The API had diverged into several simplification layers on top and it was getting really messy.

Also, one of the main ideas of OctoMY™ was the concept of a "plan", which basically is a small language that would describe a configuration of many nodes completely, and allow them to collaborate on pretty elaborate tasks from the rules of their common "plan". While some effort was made to allow for easily editing and parsing plan files, it never really took the center stage of storing data about nodes. Currently data is spread out among the following stores:

• keystore - keypair for local and pubkeys for friends
• addressbook - friends data such as name gender and type (except key, which is in keystore)
• localidentity - local data such as name gender and type (except key, which is in keystore)
• agentconfig - agent spesific configuration such as controller card config and similar
• settings - all non-essential settings such as window placements and last selected items.

Many of these "stores" are customers of the aforementioned asynchronous API and all of them show bugs, preventing us from getting to an MVP.

So now it's time for a new update to the strategy, to attack this last problem standing in the way of our glorious MVP! This time around we will focus on the following:

• plan spec - Spec up a decent first version of the plan. Take whatever we learned form the asynchronous store into consideration and ensure the spec is clean and nice.
• plan implementation - Implement the plan spec to have a first working version.
• plan test - Implement a full test suite for the plan implementation to gain full confidence in it.
• plan integration - Integrate the plan by replacing each store one by one.

Once this plan business is out of the way then:

• MVP - Continue work towards MVP.

While this approach in many ways constitutes "one step back, two steps forward", I think it is the better way. By doing this we address the real problems in front of us in a good way and can move forward with our pride intact. The alternative is soldiering on with debugging the asynchronous API, but I think that is not a fruitful use of time at this point.

Work on the plan spec has already begun, and I will try to keep this blog with some updates along the way. Stay tuned!

OctoMY™ update

I have been busy recently with OctoMY™.

This project has turned out to become all-consuming for my limited spare time for the following reasons:

• It's winter here and that means pitch dark and sub-zero, so I tend to stay indoors rather than in the dark cold workshop.
• I am long-term flat broke so I can't afford the constant stream of cool gadgets to keep me engaged.
• The project really has taken a turn for the serious. It implements the architectural plans I have for devol robot project and more, so working on it doesn't "steal" time from this project. Au contraire.
• Even for a project with the irrational level of ambition that OctoMY™ undoubtedly has, I am actually getting somewhere! Fueled by constant "success" the project progress has an astonishing velocity. Let's just hope it lasts.

OK, so with that out of the way, what really is status of OctoMY™ as of today?

1. Main project structure is set up with separate apps for agent, hub and remote.
2. Some basic profile work like colors, font etc. have been prepared together with some basic logos and icons for the UI. 
3. Compiling to both desktop and Android targets is working flawlessly. It really was a breeze to get going with Android, in fact much easier than I had first anticipated. Way to go Qt5!
4. Serial communication with servotor32 to control servos of the hexy robot is working flawlesly using simple API.
5. Initial version of network communication over UDP using the novelty QoS/on-demand api created specially for OctoMY is working as MVP+. This is in fact the code that started it all in the first place.
6. Gathering and real-time transmission of telemetry/odometry data from available device sources including gyro, accellerometer, compass, light sensor, temperature sensor, pressure sensor and gps is working.
7. Incorporation of realistic aviation widgets working.
8. Automatic platform ID generation and matching logo-based identicon generation working.
9. Incorporation of basic tile based map view is working.
10. Initial display of "pose" in 3D using OpenGL started, however this has been put on hold while waiting for better support for Qt3D 2.0 scheduled for inclusion in Qt5.6 due soon. (which will basically make this part 12x simpler).
11. Incorporation of GEAR dynamics/kinematics into project build, although it is not being used for anything yet.
12. Incorporation of flex/qlalr into qmake build for use when developing the "mandate description language" which is the core of "top-level" layer in the OctoMY™ project. This took days of frustration and added 2 wrinkles to my forehead that were instantly revoked the moment I was rewarded with the knowlege that I am in fact the only entity in this universe capable of setting up flex+qlalr+qmake to make a successful build of a parser that takes input from a QString.

What remains before there is an MVP available for OctoMY™?

1. Gait stuff (look at adapting something from phoenix code, or even better adapt GEAR to do it from scratch).
2. An actual functioning paradigm of remote control (touch simulation of joystick to move forward and turn etc).
3. MVP for the "mandate description" parser so that at least a basic "remote->hub->agent" configuration can be set up.

This sounds simple but I know for a fact that it's when integrating the parts the complexity goes up. Having this astounding list of features cooperate without throwing all kinds of bugs will be a challenge.

Devol plan for 2015

Plan for Devol robot project in 2015 is the following:

• Port my existing C++ code to use Qt instead.
• Ditch native Android for Qt deployed on Android
• Discontinue the purely CNC related projects. Rationale: they take too much time and focus away from core project without actually solving any big problems. Focus on quickly getting one CNC up and running and sell off the rest.
• Continue and complete the work with the ECU.
• Continue the prototyping of one leg.
• Make a portable "vision unit" that can be dragged around to "learn" and test, for example in my car.