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.

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!

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.

KURIO USB deviceID

I am writing some software for android, and I wanted to test it on my KURIO pad.

It has device ID: 18d1:0003

You need to put the following line in /etc/udev/rules.d/51-android.rules file:

# kurio 7
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="0003", MODE="0666", OWNER="<username>"

Be thankful, I just saved you several milliseconds worth of command-line hassle:

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.

Installed first OS on the Roboard RB-100

After building a case for my RB-100 controller board, it was only natural to continue by installing one of my favorite OSes, namely Debian.

I followed this excellent guide, and in no time at all was I booting the RB-100 for the first time.

In steps:

1. I downloaded the .ISO image from the guide.
2. Inserted an USB-key of sufficient size (4GB) and waited for it to mount.
3. Opened a shell and on the prompt i figured out which device my USB-key was by typing "mount" as root (see the detailed transcript of this step below).
4. Unmounted the USB-key with "umount /dev/sdg1"
5. Copied over the .ISO image to the USB-key with "cat mini.iso > /dev/sdg"
6. Synchronized to make sure all buffers flushed with "sync"
7. removed the USB-key and inserted it into the RB-100 USB port.
8. Booted the RB-100 and pressed F11 key to select the USB-key as boot device.
9. Inserted empty 2gb micro SD card in the slot on the RB-100
10. Followed the normal Debian install procedure, answering the occasional question about identity, language, location and connection.

root@katana:# mount
/dev/mapper/isw_ejahfggfg_Volume01 on / type ext4 (rw,errors=remount-ro,commit=0)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/lennart/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=lennart)
/dev/sdg1 on /media/6D9E-DAF4 type vfat (rw,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush)
 
The USB-key is marked in green, thus the device is /dev/sdg

In the end i could finally get my uname: