The main reviewing periods for Robotics Science and Systems (RSS) and for the Conference on Computer and Robot Vision (CRV) are both done. RSS is not the the reviewers response phase to be followed by discussions and an Area Chairs meeting in LA at the end of the month. CRV reviews are being processed and I am guessing (without specific knowledge) that missing reviews are being beaten out of late reviewers. For CRV my job is kind of done, but for RSS as as Area Chair there is a lot to do, greatly compounded by some taxing work at McGill and at home. The RSS process will probably be harsh since there were a lot of papers this year.
This year I did not do grant reviewing for NSERC, which would have been too much. That review process is complete too and the applicants should get there news shortly, once it is approved by the Canadian Treasury department and whomever else.
2010
2010
This site was unavailable in part of Feb 2010 and some of early March. Although the server itself was running, the upstream DNS server was having problems.
2010
On the weekend, I went with my old friend Robbie Drummond and his girlfriend Kat to the "Bodies" exhibit here in Montreal. hat exhibit includes, among other things, a plastic mold of some the human circulatory system and it's incredible branching structure. This is really one of the most impressive things in the show.
Robbie was impressed by the fact that the veins in the circulatory system, in layed out end-to-end, would reach something like 100,000 km (or miles, since the number is pretty approximate and based on some vague assumptions). I tend not to like this kind of descriptive device since it is unrelated to every-day intuition, and thus lends itself to amazing figures.
To illustrate my point, I thought it would be interesting to consider how much maple syrup we need to make a thin trail of maple syrup from the plate on my dinner table to the surface of the moon.
Well, with 1.21liters of maple syrup (one large bottle), if we lead a trail 0.001 mm thick, we can reach the moon. This is based on the average distance to the moon ( 385000 km ) and the radius of a cylinder of syrup being 0.001mm. The maple syrup you need can be obtained for about $25, but drawing out the stream might be a bit tricky.
In contrast, it you want the trail of syrup to be a more respectable millimeter in radius, you'll need a more substantial 1,210,000 litres of syrup. That's about 1/25 of Quebec's annual maple syrup production: there would still be lots left for pancakes.
In short, with a seeming "minor" tweak in the numbers, we can make it seem easy to get to the moon with maple syrup (or not).
2010
I was at Memorial University in Newfoundland giving at talk. In addition to visiting people in the Computer Science Department like Professors Sharene Bungay and Andrew Vardy, I also spent some time with Ralf Bachmayer (Faculty of Engineering and Applied Science; Marine Institute) as well as some other faculty members. In addition to a generally-robust general computer science program, there is a lot going on there related to Oceanography, Underwater Robotics and general topics related to the sea. That's no big surprise given the location of the school on the Eastern Seaboard, the historical dependence of the Newfoundland economy on the sea, and the relative lack of other non-maritime industries in the area. As a result, they have unparalleled resources for ocean studies.
Among the interesting things was a huge ice tank at the National Research Council (NRC) Institute for Ocean Technology (IOT) (distinct from Memorial). I believe it is the biggest such tank anywhere in the world. The IOT is a secure facility, but I had a chance to look around inside. There are several projects there that are under wraps, including contract work for America's Cup sailing teams. The ice tank is extremely large, 3 metres deep, 90 m long, contains 3.5 million litres of water and can be cooled off to produce a layer of ice of a specific thickness and texture, which can then be used to test the ice worthiness of ship designs. Want a huge basin covered with 4cm think ice? Just give them a day to make it for you.
In the wave tank they have there, they can use 168 computer-controlled wave panels positioned around the basin to reproduce a large variety of ocean conditions. This tank is not as deep of the one I saw in Rio de Janiero a while ago, but more controllable.
They also have a selection of Seagliders, a model of a military submarine that can be used for certain types of open-water testing, and lots of other activities.
2010
Well, the robot field trials I mention in my last report took place as planned. While we tested the robot in warm water and that was great, the schedule was grueling with long days and 3 or more simultaneous experiments taking place most of the time. Especially amazing was the fact that pretty much of the experiments produced successful results. There were a couple of mishaps, including at least one serious one, but that's par for the course. If all of the experiments work and nobody gets hurt, then that's a (very) successful field trip, even if some gear (inevitably) gets fried.
When you are doing field robotics, and especially robotics on the open water, some equipment damage it pretty much inevitable, especially when people are working under (extreme) pressure.
2010
We leave for our Sea Trials in just 36 hours or so. One more long day. The last week has been a wild ride and many software and hardware systems for our robots got a final checkout and some fine tuning. Of course, there was also a mad rush to include some last features or goodies after the last "drop dead" date.
Even our kooky underwater GPS until was waterproofed and attached. I added some final audio feedback elements and software flags. A possible leak was found and fixed. A bad solder joint led to a whole bunch of wiring getting replaced in a much better format. Everything seemed almost under control, until the bad smell came.
Late this afternoon a bad burning plastic small came from inside the robot. From Ramius too, the healthy young stallion, not from crusty old Aqua 1. Everything seems to work, but clearly something was wrong. Well, it looks like the CPU fan on the ADL CPU card died. We have a spare we can swap in, but it involves a major strip-down effort and, if we rush it, there is a risk we'll damage a cable or cause some other mayhem. It not clear there is time. Since the students need to meet at the lab at 3am to be sure to clear security in these crazy days, there is precious little time to lose.
I am still not sure how this is going to work out. Swap out now? Swap out after we arrive? Run slow and brave the heat? This is too frustrating for words!
Well, Philippe is swapping it out now. If all goes well, we can struggle to pack everything in time.
2010
Air Canada now allows frequent flyers to track their annual activity. In 2009 is seems I flew 33 segments on Air Canada. That's sickening... No wonder I don't find flying that exciting any more!
2010
In late December I acted as a plenary speaker at the EVIC Robotics Summer School in Santiago Chile. The Summer School seemed good with a nice selection of talks and poster presentations. In particular I visited the lab of Javier Ruiz-del-Solar at the Universidad de Chile. They have a large team there that is going a lot of very interesting work including walking humanoid robotics, robocup systems, hardware design, robotic mining applications and algorithm development.
Santiago itself seemed prosperous and interesting, but not as exciting from a tourist point of view as some of the outlying regions of Chile, which has a diverse set of different climates and ecosystems. While there I took a quick trip to the town of San Pedro in the Atacama desert, one of the most dry places on Earth. If I find time, I might post some photos eventually.
2009
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.
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.
(click to zoom)
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.
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 try used broadcast 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 figures 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. These different series differ at a hardware level: it's not merely firmware.
(click to zoom)
-- 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 are also known as Freescale and Ember respectively, based on the different hardware makers for the 802.15.4-protocol networking chip. The 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.
-- 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.
-- Another firmware called 802.15.4 for Series 1 modules (which is also the name of the networking protocol) also exists, as well as DigiMesh. This makes for 4 different firmware families, and they should all be considered incompatible with one another.
-- The Zigbee networking protocol is defined by an organization called the Zigbee alliance. They have two variations of the Zigbee protocol: the original Zigbee (Zigbee 2006) and a new protocol called Zigbee Pro. 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.
-- 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.
-- "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.
(click to zoom)
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"
2009
I gave a talk on recommender systems at the Drupal Camp Montreal meeting. The nice people at DBN.ca did a great job of
recording the talk and have put it on line. It's not super-technical but it gives an overview of recommender systems in general and a bit about how our particular system, Recommendz.com, operates.
