Cell phone vendors are despicable

I gave up my cell phone plan close to a year ago, and rarely regret it. The companies that provide cell service in Canada, and most of the US, are despicable money grubbing monstrosities. Despite the chronically awful customer service, Canadians have become accustomed to paying outrageous prices for cellular service; some of the highest in the world. We are gradually moving back to a mediaeval systems where workers pay a substantial fraction of their salary as a tithe and are never able to get out of debt.

Worse yet, the cell companies (and some ISPs) often impose ridiculous and essentially untenable terms of service. I happen to have looked at some of the terms from Rogers.com today and was disheartened to see how crazy their terms had become.

... ...
There's more. Read the whole story on "Cell phone vendors are despicable"

  

Testing Robotics Systems

I had the honor of speaking at a working at MIT yesterday on the testing of robotics systems. My own talk was heavily based our experiences testing our robotic boat, robot plane and underwater vehicles. The field trials we do involve a range of challenges in terms of experiment planning, but also including logistics, safety and team management.

The workshop overall was motivated by a project called PATFrame that deals with understanding and optimizing test planning, especially for large military-sponsored robotics projects. Other participants from the US government and military spoke about the challenges of testing adaptive systems that both change over time, and also exhibit performance which depends on (variable) features of the environment. In short, it is essentially impossible to cover al possible conditions when a system is so versatile and complex.

As intelligent systems gradually approach the complexity and richness of humans, testing them definitively will become as tricky as testing people. Even when you think you know a person very well, they can exhibit surprising behavior and there is no way to preclude the same phenomena from robotics systems. This poses a challenge not only for testers, but for society at large.

  

Perseid meteor shower 2010

The perseid meteor shower had ideal conditions this year: clear skys, almost no moon, and bearable temperatures. Unfortunately, we saw only a small number of meteors, but the overall viewing conditions make the experience nonetheless very pleasant.

I've been on holiday, but planned to do some work while away. My laptop broken irreparably on the second day, however. While it has been somewhat inconvenient, it has made for a superlative vacation in terms of stress relief and relaxation. All the better to stay up watching the stars.

  

Underwater stuff

On Thursday we did a big pool trial testing out some new human-robot interaction software that Junaed, in particular, has been developing. In addition, we tested out a couple on not-yet-autonomous surface vehicles. Everything went very well.

Almost all the students and employees in my lab were able to make it, so we have a biggish crew of about 16 people plus a few additional visitors and family members. This proved very helpful since we had a lot of gear to carry in an deploy, including scuba equipment for people who could stay down and either observe the robot or interact with it.

The boats also fared nicely and I think, for once, every single experiment came off well. That seems impossibly good; I hope nothing got lost or damaged on the way home.

One of the great side benefits of in-the-field robotics experiments is that they are excellent social events bonding everybody together by the shared objectives (and occasional hardships). It's a bit like a sports team in that way. In fact, I think the level mutual support and good sprits seems to be at a local maximum and it's an honor to be part of it. Of course the downside is that such substantial effort and infrastructure is required to do this kind of work, but that kind of tradeoff is the way of the world.

  

Xbee Znet and gps

This post deals with Xbee/Zigbee firmware with non-windows software for editing the Xbee parameters from the command line. There's also a trick for re-flashing and Xbee in an Arduino shield. Below, I explain the different kinds of hardware and software.

Contents: my application, XBee hardware versions, firmware versions, non-Windows programming software.

My application

Last weekend I implemented a GPS broadcasting system using Xbee (Zigbee) modules from Digi International. These are small wireless networking nodes that can be connected using a serial line. The Funnel IO variant of the Arduino open source CPU module directly supports the Xbee hardware, and also provides a lithium-polymer charging circuit, so it seemed just right for my needs. (FunnelIO is very nice, but poorly documented.) The idea was to receive GPS data on one module and transmit it to another one (that was in a location where direct GPS reception was impossible: i.e. inside our robot). While everything seemed pretty straightforward in principle, I had few problems.

I programmed the Arduino to pull in GPS data on a software serial port, and then retransmit the data on the hardware serial driver connected to the Xbee. I also wrote some diagnostic code to verify the GPS data was solid, to check the fix and do some housekeeping. This worked well, and I was even able to deploy the GPS receiver at the end of a 10 meter cable. When I tried to relay the data across the Zigbee link, however, I encountered all kinds of data losses. These looked like buffer overflows which led to lost data.


Hardware

On the whole, I found the terminology and variety of options pretty confusing, partly because terms have changed and there are both obsolete and even misleading documents widely readily available on the net. Also, non-windows support, and even Windows Vista/7 support, was poor. Hence this page.

Firmware and device families

Now these xbee modules can work in either point-to-point mode, or via broadcast. My first attempt was with broadcast using ZB firmware since that was easier to configure. Well, broadcast mode automatically retransmits packets multiple times (since acknowledgements can;t be sent in a broadcast context). I figured I'd try point-to--point mode. I could never get this to work.

My observations and inferences about the Xbee line:

-- There are at least 4 main families of the hardware, and several variants of the firmware for each hardware family. All the modules on a network should have the same hardware and firmware. (In addition, within each family there may be different modules with alternative antennas, but I'll ignore those little differences since they don't impinge on functionality at a software level.)

-- There are 2 different hardware "series": Series 1 and Series 2, and each has a Pro (and non-Pro) variation. This makes for 4 classes of hardware: Series 1 non-pro, Series 1 Pro, Series 2 non-pro, Series 2 Pro. These different variations differ at a hardware level. You cannot reprogram one to become another.



-- Confusing names: Series 1 is now officially called "XBee 802.15.4." Series 2 was renamed "XBee ZNet 2.5" which is really confusing since this names also seems to be used for one of the types of firmware for these devices.

These two series (1 and 2) are also known as Freescale and Ember respectively, based on the different hardware makers for the 802.15.4-protocol networking chip. The Freescale MC13213 is an integrated radio transceiver and a 8-bit 689S08A microcontroller. The Ember EM250 is a radio and a 16-bit XAP2b RISC microcontroller with AES encryption support and 128kB of flash memory. Series 1 and Series 2 differences are described in this document from Digi.

Firmware versions (4 types)

-- ZNet 2.5 firmware is based on the "EmberZNet 2.5" radio networking software. (This equivalence and terminology is indicated in the Firmware Revision History, although a Digi employee I spoke to disputed some details.)

-- ZB firmware is also known as Zigbee, or more correctly as "ZigBee PRO" since that is the name of the protocol specification it adheres to. It is based on the Ember "EmberZNet 3.x" rio-networking software. Thus, ZB is newer than ZNet 2.5, but for me ZNet 2.5 worked better.


-- Devices running ZNet 2.5 firmware cannot talk to devices running the ZB firmware, even though they are used in very similar ways and with similar commands.

-- Another firmware called 802.15.4 for Series 1 modules also exists, as well as DigiMesh. This makes for 4 different firmware families, and they should all be considered incompatible with one another. Note that 802.15.4 appears the name of one of the firmwares, but it is ALSO the name of the networking protocol. This 802.15.4 has two different meanings: the firmware and a IEEE standard protocol. (Yes, this is bewildering.)

-- The Zigbee networking protocol is defined by an organization called the Zigbee alliance. They have two key variations of the Zigbee protocol: the original Zigbee (Zigbee 2006) and a new protocol called Zigbee Pro based on Zigbee 2007. This "Pro" suffix is unrelated to the word Pro in the name of the "Xbee Pro" module family, where refers to modules with high power output. Also, both these Zigbee protocols are built upon the lower-level IEEE 802.15.4-2003 standard.


-- "XBee Pro" modules operate at higher RF power levels, 50 or 100 milliwatts. Same pinout, slightly longer chip housing for the Pro models. The regular (non-pro) units work at 1 or 2 milliwatts. (It is possible they inter-operate with non-pro, but I have not tried.) Regular XBee devices have serial numbers starting with "XB" (e.g. XB24-B) while Pro devices start with XBP.


Using the "DD" command, you can read the pre-loaded device family code.


The Xbee's using I purchased came with "Zigbee" firmware pre-installed. I believe this is what they suggest for new customers. I could never get point-to-point (non-broadcast) communications to work with or without a coordinator, so I tried another firmware. When I eventually decided to download and burn in the "ZNET 2.5" firmware instead of the Zigbee firmware, everything worked. Point-to-point worked, but I am pretty sure the throughput was so much better that broadcast would have worked fine also. My morale: use the ZNet 2.5 software on the Xbee if you can.

Firmware versions -- details
Using the VL command, you can query the currently-loaded firmware version. It is a 4-digit number (ABCD), but if the last digit is zero it might appear in the form ABC. The digits have the following interpretations:

• A: seems to be 1 for ZNet 2.5 release firmware, 2 for Zigbee firmware and 8 for beta-test code.


• B: the "variant". 0 for coordinator in AT mode (one of two possible command languages used for the modules). 2 for end device code. 1 and 3 are for API command mode.


• C: seems to identify the version of the code. New releases have bigger values.


• D: revision number of the version.

Thus my XBee Series 2 node in coordinator mode currently uses firmware version 1047.

See also Digi's firmware documentation, the list series 2 firmware releases.



Reflashing in an Arduino shield

To reflash the Xbee firmware you need to use the XCTU program. My Xbee was in an Arduino "shield" (which provides a USB interface). To directly control the Xbee, you need to remove the microcontroller from the Arduino CPU board (as described here). This is great for accessing the Xbee serial interface from a computer, but to use XCTU you will also need to reset the Xbee a couple of times and no such button it provided on the shield. With a small section of wire, you can do this the "hard core" way. Just touch the wire between pin 5 and pin 10 of the Xbee (or the solder pads beside it). Pin five is the reset pin and pin 10 (at the corner of the module) is the ground pin. Pulling the reset pin low (to ground) does the reset. This is pretty easy and works reliably.



Python-based XCTU replacement

I rarely use Windows and thus I also wrote a python-based program to allow the parameters of the Xbee to be queried and set. This allowed me to configure the Xbee from OS X and (later) from other software systems. This is command-line based. I've tested it on Apple's OS X and it is likely to work on Linux. On Windows I have no idea, but Windows supports XCTU which in the vendor supported solution. On the other hand, since as of this date XCTU does not seem to support either Windows Vista or Windows 7, this might be useful even there. If you try this on Windows, let me know what happens. This software does not support re-flashing the firmware, so to switch from Zigbee to ZNet you still need to use XCTU from Digi.

My Python program called "xbee-gdxctu.py" is available for download.

This software is is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.


If you find problems of have suggestions, please let me know. An example session is given below.

... ...
There's more. Read the whole story on "Xbee Znet and gps"

  

London, England

Last week I was in London, England with my daughter and we had a chance to visit the British Museum. It is, of course, an exceptional cross section of the human civilization. What of the great aspects of the collections are their breadth: the way you can compare and contrast are creations of different civilizations that are greatly separated by time and geography. For example we visited the Elgin marbles from ancient Greece, and then almost immediately afterwards went to see a collection of Chinese Buddhas and then, on the way out, I had a chance to look at one of the heads from Easter Island.

During the visit I was struck by two obvious realizations. Firstly, there is both a huge diversity, variety and depth of feeling that various civilizations have been able to express in their artworks. Even though the subject matter at hand is often the same, different cultures have managed to depict is highly characteristic ways. Even one civilizations are closely related and intentionally use the same expressive forms, as with Ancient Rome and Ancient Greece, the individual nature of the local context is irrepressible. Much like different people interpreting a Rorschach, each civilization cannot help but leave it's own unique signature.

Secondly, the immense productivity and impact of our current technological civilization are totally out of keeping with everything that has come before. Not only has our current phase been amazing brief so far, but the extent of its impact is completely off the scale in every possible measure. We all know there are been immense technological chance in the last hundred years, but seeing the artifact of one long-lived civilization after another provides tremendous emphasis to how weird and anomalous the last hundred years have been. It's not just technology, but the nature of what we are now producing that is so different.

In some ways a species is defined not merely by its genome (DNA) or phenotype, but by the information matrix is carries along with it. For many species this matrix of ideas, behaviors and thoughts is encoded in DNA and constantly rebuilt (for example, with ants). For some non-human species, there are substantive cultural characteristics that are passed from parent to child, as with some hunting animals of chimpanzee clans. It is similarly easy to imagine that if true machine intelligence is every achieved, then the information matrix that defines it will be the primal characteristic of a species, just as it defines the distinction between Microsoft Word versus Apple's iPhoto. For humans today, it seems we have crossed a barrier between a state where the information binding us was evanescent, as with ants, to a very different mode of existence where our species has been redefined by a combination of physical form and information state.

  

What a nice surprise

I was awarded a prize from the Canadian Image Processing and Pattern Recognition Society at the annual CRV conference. Thanks!

  

Android Nexus-1 Phone vs the iPhone: pros and cons

Here are more thoughts on the Nexus-1 phone (from Google) and some of it's pros and cons in comparison to the Apple iPhone (and iPod touch). Both phones have advantages: the iPhone is clearly a smoother and more elegant user experience and has better ergonomics. The Nexus-1 is more unconstrained and thus lets developers, and hence users, to a larger variety of things with the phone and configure in more idiosyncratic ways.

Both phones use pretty impressive hardware to provide a range of impressive mobile computing abilities.

The fact that the Nexus-1 on uses the Android operating system means is, essentially, running UNIX (i.e Linux). The Apple iPhone is also UNIX based, although it is derived from a different lineage of the UNIX family tree. The iPhone, however, uses a layer of data security protocols to regular what programs can be executed, and also to limit what programs can do. Although it is possible to write programs that escape these safety protocols and limits, that it only for people who want to serious hack with their phone. The Android operating system, on the other hand, is a bit closer to a standard desktop-style UNIX release making it easier for users to install just about anything, and for programs to do whatever they please.

As a result, there are many programs for the Nexus-1 phone that fiddle with the way the phone operates. Some of these are useful, but by-and-large there is a huge clutter or applications that "tweak stuff," but many such programs are unreliable, incompatible with one another, or otherwise problematic.

The Apple iTunes store takes a lot of flak for being restrictive about what can be offered for sale. Among it's positives, it provides an level of assurance that all programs work more-or-less as advertised, and that they satisfy a minimum level of presentation quality, utility and consistency. On the other hand, Apple has been getting more and more controlling and autocratic, which is a very worrisome trend especially as they achieve market dominance in this arena.

While I found a few interesting applications on the Nexus-1 market (i.e. store) that I have kept on my phone, I had much more trouble finding good applications than I did on the iTunes store. The Android market is a bit like shopping at a very big pawn shop attached to a Walmart: lots of stuff, not very well organized, mainly low prices, a lack of quality good. This may improve as time passes, but the ability for people to stick almost anything on the store means a stream of shoddy hacks obscures whatever good content might be hiding there (for example these are many applications whose description says, roughly, just and experiment -- does not work properly). As a fan of UNIX, Linux and open-source development, I can't help but appreciate the virtues of this model, but for a standard consumer it seems to be seriously problematic.

Now, if you want to develop code and hack around, the Android and the N1 have a lot to offer. Getting shell access is not too hard, although getting root access does void the warranty. The android scripting environment (ASE) lets you run python, lua, and other interpreted languages and that's very pretty.

  

The Nexus-1 Android phone: not a joy

Here are the top 4 reasons why I am frustrated and disappointed about the Google Nexus-1 made by HTC. Two weeks ago I borrowed a Google Nexus-1 phone for a few days and last week I bought one. I was initially unhappy with my purchase (although I have gotten used to it).

All-in-all I would say the Nexus-1 is usable, but it has numerous rough edges and for such an expensive phone it was a substantial disappointment and frustration.

The key downsides are:

1 - Poor power management and power consumption. The first two days I had the phone, it went from fully charged in the morning to out-of-power before I went to bed. If you turn off the cell-phone radio, the GPS and the wireless and don't run anything intensive, then the battery can last 24 hours. It's not a very useful device in that case, however. This isn't just bad, it's utterly ridiculous and unforgivable.

2 - Limited or missing support for WPA-Enterprise ...

... ...
There's more. Read the whole story on "The Nexus-1 Android phone: not a joy"

  

NY Times robotics coverage

Robotics gets a nice, albeit fluffy, plug in the New York Times, at least in the on-line edition.

The "Robots Are Among Us" posting describes several interesting robotic systems pictorially. Oddly, the omit some of the most ubiquitous robots like the Packbot and Roomba, but I guess that are after the most exotic looking stuff.