Showing posts with label Android. Show all posts
Showing posts with label Android. Show all posts

2017-08-06

3D Printed case for iMacwear W1 (DM98)

I made a protective case for the W1 Android watch.

iMacwear W1 in protective 3D printed case with servo mount.


The idea was to make a case for it that would protect it while also providing better mounting options. The current version of the case sports a native RC servo horn mount, but I am also looking at different mounting options including a gimbal mount and a simple "screw me on" mount.

I submitted the whole thing on thingiverse here if you want to check out the details. It includes source CAD file, lots of pictures and details etc.

2016-12-16

iMacwear W1 First impressions

Good news: I managed to build, deploy and run OctoMY™ Agent without any changes to the source code! It crashed a few times, and I have a bad feeling that these crashes are due to out-of-memory. I really have not been able to debug that fully yet. Will continue in this trail soon. But it got past the delivery and having the Agent eyes looking back at me from the small screen is a delight!

OctoMY™ Agent running on iMacwear W1 Android Smart Watch


After my last post about the iMacwear W1 unboxing, I have now had some time to form a first impression.

At first I was not sure the devivce was actually running Android as it claimed, but I soon figured out that this is because it runs a custom version of Android called "FunOS". I have not managed to find any information about this OS online. But in practice it means that many stock Android applications have been replaced with less resource intensive and more compact ones.

The main UI and navigation makes sense once you get used to it, and getting used to it takes about 15 minutes. I find it lacking a bit in the aesthetics department, the icons are not well executed. But the UX is ok, and as we all know, form follows function!

I had some problems with getting the device to register with Ubuntu. The device reports the USB vendor of HTC with a device ID of 2008,  (0bb4:2008), so if you need a line for your Android udev.rules, it will look like this:

# iMacwear W1
SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="2008", MODE="0666", OWNER="<username>"

I found that enabling developer options in the settings on device and installing mtpfs package helped a little, but it was still unstable.

sudo apt-get install mtpfs

In the end, just retrying a lot makes it work. Once it works it will work for some time. I also found you have to keep the pogo connector completely still the whole time, because just unsetting it a little will break the USB handshakje and the connection/debug session/whatever.


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

2016-03-02

OctoMY™ update

I have been busy recently with OctoMY™.

3 Friends - Agent + Hub + Remote. OctoMY™ tiers.


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.


2016-01-07

OctoMY Update: Some sensors working in remote app on Android device

New in this commit:


  • Made it compile and run on Android
  • Added some sensors to remote application
  • Many small fixes all over


2016-01-04

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!





2013-07-24

Android on HP tx1000 update

My effort to install Android on a HP tx1000 convertible tablet was a success. Essentially i duplicated the example configuration files that were made for a later HP laptop model to suit the more humble specs of my device, and after a few rounds of trial and error it booted android and everything was swell.

However, just as it was starting to get fun, the device died on me. I have put my plans for x86 Android device on hold while working on other much more important and pressing software components like IK.

2012-10-31

Android x86

One realization i got while working with the software stack for the robot was that the software will have to be distributed over a pretty heterogeneous mix of hardware. Each hardware will run a piece of the software that each perform a part of the processing needed for the robot.

Some of the hardware/software components are on a low level, and need to run real-time and have a very narrow and predictable set of responsibilities, while others are on a higher more administrative level.

Deciding which authority is given to the components and how they communicate will be an ongoing and difficult task. Several strategies exist. One is distributing the decision making the farthest possible way down, so that each component has as much as possible authority to solve problems on their own, giving the robot more resilience to errors in communications.

The opposite approach is of course to centralize as much as the decision making as possible in one central device that then commands the other subsystems, making the decisions more informed, and quicker, but making the solution more vulnerable to single point of failure.

I think that both strategies have both weak and strong sides, and that I will have to make a decision in each separate case whether to put authority centrally or distributed. In other words, an intelligently configured hybrid may be the best solution.

"What does this have to do with Android"? you may ask.

Well, the software that will be put on the embedded low-end hardware will be mostly purpose built and even firmware in some cases, but at the higher levels we will need something really flexible, yet efficient and modern. Something awesome. And that is in one word: Android.

Illustration photo HP tx1000 convertible tablet


That's why I am building Android for x86 to fit my HP tx1000 convertible tablet computer right now. Hopefully it will let me develop a central, top-level, main brain app that can command all the other subsystems big and small in perfect unison.