Roomba Commander

Roomba Commander

Roomba is cool. Not just because of the obvious (it cleans your house/appartment so you don't have too), but rather due to the fact that the designer thought that techies will also like to play with it.

They have added a SCI (Serial Command Interface) and documented it quite well: PDF. You can do lots of stuff with the interface: write on the 7-segment display, check the status, send commands and even play a song. There is a 9-pin connector on top of the Roomba and if you want to reach it, you need to remove the top plate.

As designed, if you want to control your Roomba with your own circuit, you should create a piggy back module and connect it to the top connector. Unfortunatelly, this has two main deficiencies:

• The connector only provides direct battery voltage (14,4V), which needs to be reduced to an appropriate level for the controller circuit (3,3V/5V)
• Sometimes Roomba needs to pass under a low passage, which could pull the circuit from the connector

When the Flyport module was introduced, I created a simple PCB and attached it to the top connector. Roomba displayed the word hi with a smiley (HI :]) and played the Ode To Joy. I also developed a simple web interface and did some testing. Due to the "Piggy back design", the circuit was soon ripped from the Roomba while cleaning. Then the Flyport PRO module was introduced and it seemed to be perfect to fit into the cleaner. The designers of the Roomba did not leave too much space for any additional modules, but it seemed that there is just enough space in one of the "pockets" for what I needed.

Power Supply

Since Roomba works on 5V and the Flyport needs a 3,3V power supply, I bought a module, based on AMS1117 on eBay and wrapped it in heat shrink to be able to supply 3,3V to the Flyport PRO.

Connecting the module to Roomba

Next, I needed to disassemble the Roomba. There are many guides on the internet on how to do this, so I will not focus on this part. Then I used a multimeter to find the pins from the SCI interface (RXD, TXD, DD) and for the power supply (+5V, GND). Luckily, they are quite close to each other (marked by me with a red marker).

The Flyport PRO module did not fit into the pocket first (just a mm short), so I melted of a short peace of plastic to fit the module. I have also trimmed a part of the screw, which is seen on the picture. After that, the fit was perfect. The voltage regulator is tucked to a small hole next to the module. Flyport has remappable pins, so I used the pins that are 5V tolerant, removing the need for a level converter (pin 5 => Roomba/DD, pin 13/RX => Roomba/TX, pin 15/TX => Roomba/RX).

Here are the connections from the Roomba PCB to the Flyport PRO.

Firmware

The firmware for the module can be found on GitHub.

Usage

After everything is connected and the Roomba is assembled, you should connect to an ad-hoc network, called ROOMBA_NET. Type the following address to the browser: http://192.168.1.250 and you will be presented with a screen on which you can set your network parameters to be able to use the Roomba in your home network. Roomba will reconnect to the newly defined network and you can access it via your browser (see the address in the image below, the IP address should be changed to what you have set in the previous step).

You can use the buttons in the bottom to issue commands, view the battery status in the rectangle near the top and best of all, all brushes and wheels are ANIMATED and move in your browser when they move on your Roomba. If the wheels drop, the exclamation mark indicated the error. The code was not tested in all browsers, but it works in most recent Chrome version (desktop and Android). 

Beside the web interface, you can also directly issue commands and query state via HTTP GET.

Status info from Roomba

http://ipaddress/roomba_xml.cgi

http://ipaddress/roomba_json.cgi

will return the current status from Roomba in XML or JSON format:

Commands

http://ipaddress/cmd.cgi?command=clean (Clean command)

http://ipaddress/cmd.cgi?command=dock (Dock command)

http://ipaddress/cmd.cgi?command=power (Stop command)

Firmware upgrade Over The Air

Since the module is neetly stored in the Roomba, the firmware also supports update of the firmware from a FTP server (see the Flyport Wiki and the source code for more details). The network connections are stored in the external Flash, so your connection parameters don't get lost during firmware update.

You can also update the Firmware with an upgrade client, written in .NET, which should be quite easy to build. You can find the client on GitHub. 

The PCBs

Finally, the boards arrived. They look ok, but I have notices I made some small errors (a few holes could be larger). I can use the and I will fix this in my files. I've already managed to assemble a board. Now off to testing ...

The PCBs

The board without the OpenPicus module

The board without the OpenPicus module 

The board with the OpenPicus board

The circuit presented could be used for several usages, it features 10 digital inputs and 10 digital outpus (via Solid State Relays). This one will be used to control 5 blinds connecting buttons and blinds.

Optically Isolated Zero Crossing Detector

Since I am still waiting for my PCBs to arrive, I decided to take some time to design a proper and accurate zero crossing detector, that can be used to create a microcontroller based dimmer.

Proper zero crossing detection is essential when creating a dimmer with a triac controlled by a microcontroller. The circuits I encountered online either used transformers or were not optically isolated towards the microcontroller (like http://ww1.microchip.com/downloads/en/AppNotes/00521c.pdf).

The "heart" of the circuit are two operational amplifiers (in one package) with an open collector. Transistors C1-C4 and diodes D1-D4 represent the tranformless dual voltage power supply, which powers the operational amplifiers. Resistors R1-R4 provide the reference voltage of about 3V.

When the input voltage (sensed over the R5) exceedes +3V or is lower than -3V the IC1A or IC1B output transistors are connected towards the negative voltage and no current is running through the led in the optocoupler.
When neither of op amps is active (sense voltage is between -3V and +3V) the optocoupler led is active and the optocoupler's output transistor connects the external INT pin to the ground, triggering the interrupt.

The circuit was only tested on a protoboard, so take caution when implementing it in your design.

WiFi

I wrote about the reasons for using WiFi in my previous post. Let me cover it in more details.

The Pros

1. WiFi is already present in most homes, the only thing you need is a wireless router.

2. Security can be taken care on a network level, no need for additional security on the end devices.

3. Simple interface from the PC/mobile to the end device (no need for bridges or border routers)

4. It is quite easy to extend the range by adding more routers to the network level.

The Cons

1. No mesh network, the end devices are directly dependent on the router

2. Slightly higher power consumption than in 802.15.4 network

The Hardware

I have set the following goals for the electronics; the circuit should be easy to build, it should contain little or no SMD components (two layer PCB board is acceptable), the circuit size should fit inside some standard size wall boxes (the largest should go inside Gewiss GW 48 003 junction box)

The use of a WiFi module was a logical choise and I spent quite a lot of time searching for the right one, until I stumbled upon this one:

It is called openPicus and it is a spin-off project of Eikon company.  It features 22 I/O pins, which can also be remapped to different functions. The default config has 5 digital input, 5 digital output and 4 analog ports, but this can be changed. It is based on a PIC microcontroller and uses the Microchip TCP/IP stack.

The team has prepared a wizard based development environment, which "hides" the complexity from the developer. You can find more about it at: http://www.openpicus.com.

The first PCB board I will build will support 5 blinds with commands, so the board will feature 10 digital inputs (5xUP and 5xDOWN) and 10 digital outpus (via Solid State Relay).

The schematics and the PCB are already designed. When I get the boards, place the components and test them, I'll publish the designs for the hardware.

Automating my home

What is a computer worth if it is not connected to the real world? When I got my first computer in elementary school (the famous Commodore 64), I took some optocouplers and triacs and created a light show. I even used the Analog Joystick Input to sync the lights to the music.

That was so great! I thought of all the things I could do with my Commodore. Controlling robots, cars ... But the coolest of all, was automating my house (which was, of course, far from reality in that time). Now, more than two decades later, it is finally time to do something about it.

In the past two years, I have evaluated quite a few options, when it comes to the home automation protocols:

• X10
• Zigbee
• ZWave
• "simple" 802.15.4
• KNX/EIB
• Central wiring
• 6LowPan
• WiFi

The first question I had to answer, was whether to buy the whole system off the shelf or to build it on my own. The price tag of the built systems and my interest in electronics helped me to go for the DIY aproach. I didn't want to rush, I took my time studying all available options. I thought about cost, complexity, simplicity, extensibility, adaptability ...

The Protocol

After quite a lot of consideration, I decided to use WiFi for communication. I've looked at Zigbee for a long time, but it is far too complex, even for vendors. 6LowPan has low power consumption and mesh network, but power was not such a big issue for me and I could deal with the range by adding extra WiFi routers.

The Concept

I don't want to put too much logic onto devices. That complicates their code and communication protocols. That is what Zigbee does and that is the main reason I didn't like it. So the system should have a centralized server for complex operations like Scene management and User interface. 

The devices should be simple, but still able to operate independently from the central server. I decided not to split the command (like button) from the actuator (ex. lights, blinds, ...). They are connected to the same board and don't need a server to operate. The devices respond to simple REST commands with a status XML file.

I will post more details of the system as it gets built. I will publish the schematics, PCB and source code (some kind of open source licence). Feel free to comment and to use my work if you find it useful.