iMacwear W1 Unboxing

I recently purchased the iMacwear W1 Full Android smart watch for testing with OctoMY™ software. I will put it as a recommended device in the shop page as soon asi get the OctoMY™ agent to run without problems. But before that, le't do the unboxing!

Neat gift box with magnetic lock

Tidily arranged contents

Top compartment contains user manual

Watch is strapped to black velvet cushion

Polishing cloth under the watch

All the box content side by side

Accessories box open in the short end

Contains pogo USB data/charging cable in plastic bag

Pogo cable removed from bag

Closeup of pogo USB connector showing gold plated pogo pins and magnets

Back side of watch showing wrist band

Protective film for screen (I removed once already)

Backside of watch

Closeup of backside showing pogo pad and sim slot.

pogo cable connected

After 3 hours of charging, showing main watch screen.

After removing protective film

 

Main menu

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.

OctoMY™ on github

I decided to wrap my current code into a project and put it on github. I also made a project page on google sites and bought a domain name for it. The logo I sketched out real quick in inkscape looks like this:

Logo for eight legged madness!

Logo in SVG format can be downloaded here

Currently I have just posted my work-in-progress code that compiles without errors on Ubuntu, but that does not really do anything useful. I will keep this updated as I progress in making the code more useful!

Choice of interconnect

I have been looking at different ways of connecting the different tiers of the robot that facilitates the following characteristics:

• Real-time
• Fault tolerant
• Embedded
• Low-power
• Broadcast friendly
• Master-less (survives
• Adaptive (survives topology changes)
• Bus architecture (many nodes)
• "Fast"

So far the most likely candidate seems to be CANbus.



I will investigate further.

Protobuf for embedded

I have recently had the opportunity to research potential binary protocols at work. The thought just occurred to me that Google's protocol buffers (a.k.a. protobuf) might be a good candidate for the serial communication that occurs between different components such as controllers and servos.

You might think that it has too high overhead, and that may very well be the case. On the other hand protobuf has a few advantages that may not be obvious before you start using it.

For one, it makes thinking about your protocol much easier. The .proto text file format is just brilliant for recording your latest and greatest ideas for a protocol.

Second, you can actually use the code that is compiled by the protobuf compiler, not only for transfer of data, but also as your internal representation of the data. This will save memory, and that is good.

Third, it makes changing and even managing versions of your protocol effortless. For an embedded hardware project you might think that is unnecessary, but at least in my project with 36 servos with custom firmware and probably a whole bunch of other little controllers responsible for other stuff, with protobuf you could just change the .proto files, rebuild the firmware binary, upload it to the right controllers and be done.

I will investigate what impact protobuf has on the performance of tiny controllers, and on the bandwidth and latency of the serial communications, and report my findings here.

Sourcing radio modem

I have combed alibaba again. That site is really full of interesting prospects!

This time I went looking for radio modems. The robot will have conventional WIFI and GPRS/3G/LTE access, but I thought that as a more general purpose, fail-safe and cheaper alternative (3G is expensive), It would be neat to have a FM radio on board. Just look at all the goodies!

Radio modem with 20km range from alibaba.com

I made sure to hide my VISA card someplace safe first.