Repairing Roomba charging circuit

Sometime ago, a colleague told me that she bought a Roomba 405 but the battery seems dead, unable to charge. Being the curious me and how I like to fix things, I made a deal that if I could fix it, I can use it to clean my house for 1 month :-)
So, this post is a sharing and also a kind of documentation for myself on how I got the Roomba working again.

Initial diagnosis....
So, the next day she brought the Roomba to me in office and I took it home.

First step, I tried to charge it by connecting the AC-DC adapter to the robot. According to the user manual, it seems charging. The amber LED is blinking slowly. A few hours later, I detached the power and try to see if it moves by pressing the "Clean" button. Nope, it is dead as a log. So, next step, I took my multimeter, removed the battery and measured the battery terminal voltage. Huh, it reads approx 0.6V? Now, I gotta monitor the voltages while charging to figure out what's wrong. I attached 2 thin wires to the terminals, replaced the battery into Roomba and attached the charging adapter again. It still reads O.6V! So, then I could say that it is somehow not charging properly.

Next, I gotta verify that the battery is still working by manually charging it. The label on the battery shows 14.4V NiCd battery with 1800mAH. A NiCd battery with 14.4V rated voltage means that it is 12 x 1.2V NiCd cells. So, the fully charged voltage should be 12 x 1.45V = 17.4V.

Since the Roomba's DC adapter outputs 0.75A at 22V and NiCd batteries are relatively easily to charge, I can just make a very simple charging by directly connecting the adapter's 22V output to the battery via a 5ohm resistor as a current limiting resistor. To be safe, I also will keep an eye on the charging voltage and current to ensure they are within reasonable safety limits. Once I applied power, I can see that the battery voltage steady goes up. This should mean that battery seems to be still chargeable. The charging current is approx. 700 mA; seems the the DC adapter has internal current limiter which is a good news. Since the battery capacity is 1800 mAH, it should take approx 2-3 hours to fully charge it, but I have to be careful not to overcharge and damage the internal chemistry.

After about 30 mins and the battery voltage got up to 16V, impatient to wait till fully charged, I poped the battery back into the Roomba and press the "Clean" button. The time the little robot roars to life! It goes around the room while cleaning the floor for about 10 mins before it stops with a blinking red LED and a 4 tone melody that indicates low battery. Alright, now I can confirm that the battery is OK, but Roomba is just not charging it.

Why did it broke?
To fix it, I had to find out why there is no charging voltage applied to the batteries although the LED indicates it is charging. I did a search on google and eventually I came to this forum: http://www.robotreviews.com/chat/viewtopic.php?t=3909&highlight=mosfet#p20787
I also found a reverse-engineered schematic at http://mysite.verizon.net/gsplews/misc-pix/charging_n_control_schema.GIF
The problem described seem very similar, so I disassembled the roomba. I probed the MOSFET, U2 and it seems really dead. There are no voltage at the drain although the voltage at source and gate seems normal.

To replace the STN3PF06 P-channel power MOSFET, I found that RS-Online sells them for RM2.58 each and minimum order quantity is 10 but I don't need 10. Even if I replace all MOSFETs in the charging circuit, I'll only need 4. Also, it seems to be a fairly common issue that will probably reoccur if the batteries are fully depleted, causing the initial charge current to be too high that it killed the MOSFET.

Solution...
Alternatively, I dug around my toolbox and found that I still have a few LM317. Then, I got an idea that if I could bypass the original charging circuit to provide constant current to the battery positive terminal, the Roomba will still be able to indicate charging status but the actual charging current is supplied from the LM317-based constant current charger as shown below on my literally back-of-envelop design.

Prototyping
First, I did a prototype on breadboard to the circuit to verify that it works. From the LM317 datasheet, the resistor value should be:
R = V_ref / I_out = 1.25 V / 180 mA = 6.94 ohms.

However, I used the two 12ohm resistor parallel was used because those are the resistors in my toolbox that gives the closes value. The output current is still 1.25V / 6 ohms = 208.3 mA which is slightly more than 0.1C charging rate for the 1800 mAH battery. So, I added the additional 1Kohm resistor and LED to the output to siphon off about 15 to 18 mA current depending on the battery's charging voltage. After successfully charging the battery which this constant current regulator (which takes approx. 10 hours), I decided to go ahead and put it in the Roomba.

Building the circuit
I cut a small piece of stripboard and arranged the components as tightly as possible. Then I took out my old solder gun and solder them together. This is what I got... no too bad considering my soldering skills are long expired since my college days :-p

Robot surgery...
Below is a few pictures I took as I was disassembling the Roomba.

Battery, brushes and dust container removed

Top cover removed

From the picture above, you can see the battery connector is at the top right. However, due to limited space, I decided to place the circuit on the top left side.

Next, I have to connect the circuit to the original wiring. I had to temporary remove the battery and power connector solder on the wire as shown below.

Yellow is the regulator output, red connects to the positive supply and black connects to ground.

Next, I fastened the board on the Roomba using the screw hole on the LM317 to a screw hole just beside the battery compartment. The weird silver coloured strip is actually a few pieces of kitchen aluminium foil folded together to be the regulator's heatsink. This is because from earlier experiment and also from the datasheet, the power dissipation has exceed the limit of using it without heatsink. According to the datasheet, the power dissipation when is battery voltage low should be approximately:
P_D= (V_out - V_in) I_out = (22 V- 15 V) 0.208 A = 1.46 W

Maximum allowable temperature rise, T_R(MAX):where T_J(MAX) is max junction temperature from datasheet and T_A(MAX) max ambient temperature :
T_R(MAX) = T_J(MAX) - T_A(MAX) = 125 - 32 = 93°C

Thermal Resistance:
θ_JA = (T_R(MAX) / P_D) = 93 / 1.46 = 63.6 °C/W

For the TO220 package, the junction to ambient thermal resistance without heatsink is 50 °C/W. So, I needed a heatsink to reduce the thermal resistance.
Since we have only exceed the thermal resistance not much, a simple heatsink should work.

Also from thermometer, without heatsink, the temperature can go dangerously above 80°C. With the heatsink added, temperature stabilizes at around 50 - 60°C throughout the charging.

Finally, below is the picture of the repair Roomba before the housing is assembled again.

I have done a few rounds of change and clean cycle. So far, it seems good. It takes approx. 8 - 12 hours to charge until the top LED turns green.

I have just return the Roomba to the owner a few days ago and I am starting to miss it because now I have to clean the floors manually again :-(

This whole experience made to so tempted to buy a Roomba myself :-D

Kubuntu Jaunty Jackalope 9.04

Just some long over due update....

I have upgraded to Kubuntu Jaunty 9.04
This time, they have finally got it rt73usb wireless drivers right.
I have disabled my own complied driver before upgrade.
Now I am using default driver. I have been using it for a few weeks and so far no connection dropping and download speed is good.

One little surprise after upgrade was that my display was corrupted when it enters KDM, I can't even go to console mode with Ctrl-Alt-F1. I had to SSH into my machine from another computer and type:

aticonfig --initial

This configures a default set of display settings into my xorg.conf.
After this, everything is working great.
The only slight disappointment is that lm-sensors module for my phenom processor is still not available. I can only monitor using mobo sensors. Perhaps I'll try to compile my own module when I have some time later. Now I am just too busy at work and also all the wedding preparation.. sigh..

rt73usb problem with Ubuntu Intrepid

Recently, my wireless connection seems unreliable. It keeps dropping from time to time unpredictably. I cannot just reconnect it with network-manager. I had to unplug my Linksys WUSB54GC usb stick and plug it again to work.
After getting frustrated with this, I finally did a quick google search and found out that this is somewhat a know issue with as describe in https://bugs.launchpad.net/ubuntu/+bug/283759
The suggested solution is to install linux-backports-modules-generic package.
I am trying it out now and I'll update this later if it works out well.

UPDATE:
Nope, not working for my current intrepid kernel:

$ uname -rv
2.6.27-9-generic #1 SMP Thu Nov 20 22:15:32 UTC 2008

The kernel module won't even load due to some "unknown symbols" error in the syslog

Next, I have also tried compiling the compat-wireless from http://linuxwireless.org/en/users/Download but also could not work. This time, the kernel modules could load, but could not connect at all due due to time-out errors.

Finally and hesitantly, I tried the legacy rt73 serialmonkey drivers. Thanks to the instruction from http://linuxbidouille.com/2008/10/25/wifi-rt73-rt73usb/ [ it is in french, but the shell commands is a universal language ;-) ], I had to blacklist rt73usb and then compile and install rt73 module with the following steps (slightly different steps, probably due to newer CVS version).

First, download the latest legacy rt73 package from http://rt2x00.serialmonkey.com/wiki/index.php?title=Downloads
Then, decompress and compile it with the following commands:

tar xvf rt73-cvs-daily.tar.gz
cd rt73-cvs-*/Module/
make -j4 # where 4 is the number of concurrent jobs; I have a quad core Phenom X4.

Next, I unloaded the drivers, blacklist the existing drivers by adding two lines to /etc/modprobe.d/blacklist and add the new module to /etc/modules

sudo ifconfig wlan0 down
sudo modprobe -r rt73usb
sudo modprobe -r rt2500usb
echo 'blacklist rt73usb' | sudo tee -a /etc/modprobe.d/blacklist
echo 'blacklist rt2500usb' | sudo tee -a /etc/modprobe.d/blacklist
echo 'rt73' | sudo tee -a /etc/modules

Then, install and reload the modules

sudo make install
sudo depmod -ae
sudo modprobe rt73

Because legacy serialmonkey drivers are not supported by Network Manager, I need to manual configure the wireless network before I could bring up the network interface by adding the following lines to /etc/network/interfaces:

auto wlan0
iface wlan0 inet dhcp
pre-up iwconfig wlan0 essid "YourWirelessSSID"
pre-up iwpriv wlan0 set AuthMode=WPA2PSK # or WPAPSK
pre-up iwpriv wlan0 set EncrypType=AES # or TKIP
pre-up iwpriv wlan0 set WPAPSK="Your_WPA_Password"

If you worry about storing the password as cleartext, it can be encrypted using wpa_passphase command:

$ wpa_passphrase YourWirelessSSID
# reading passphrase from stdin
Your_WPA_Password
network={
        ssid="YourWirelessSSID"
        #psk="1234password5678"
        psk=6d5a47c07977445329d6701c78a26ce1df86263c9779aa83b4e8d125637b9d5b
}

then copy the long hexadecimal string to /etc/network/interfaces to replace the line

pre-up iwpriv wlan0 set WPAPSK="your WPA password"

with

pre-up iwpriv wlan0 set WPAPSK=6d5a47c07977445329d6701c78a26ce1df86263c9779aa83b4e8d125637b9d5b

Finally, bring up the network with:

sudo ifconfig wlan0 up

Wireless should be working fine now, so far I have been running KTorrent for almost whole day and wireless connection is still working, no connection drop :-)

The only disadvantage is if you are using laptop and roam between wireless networks and you have to manually configure the /etc/network/interfaces. I believe wpa_supplicant could be used, but I have not figure out that part yet. Perhaps next time...


Update May 2009: I have upgraded to Kubuntu Jaunty, and they have finally got it right. I am using the default drivers and things work out of box, so far it has been reliable, not drop connections and download speed is good. So no need for the above workaround unless you really want to stay with Intrepid.

Native 64-bit Adobe Flash Player 10 for Linux x86_64

Recently I have upgrade my machine to a Phenom 9650 with 4GB RAM. So I decided to use install Kubuntu 64-bit. However, I had to install the 32-bit libraries and nspluginwrapper for Adobe Flash Player to work as it previously only 32-bit binaries was release. Now, Adobe has released an Alpha "refresh" version of native 64-bit Flash Player to enable pure 64-bit web surfing experience!
To install, first uninstall currently installed flashplayer with the following commands:

sudo apt-get purge flashplayer-nonfree nswrapperplugin

Then download Flash Player 10 for Linux 64-bit from here.
and extract libflashplayer.so to the following directories:

~/.mozilla/plugins/
/usr/lib/firefox/plugins/
/usr/lib/mozilla/plugins/

Restart firefox and go to your favourite flash site.
For me, youtube.com and various flash site works well!
The only problem is that konqueror doesn't seems to like it and does not display properly and it has been reported as bug 169626.

VirtualBox Hardware Virtualization and Nested Paging

Recently discovered that I could enable nested paging for Virtualbox 2.1.
Nested paging is a new hardware virtualization extension on AMD K10 Barcelona/Phenom and Intel Core i7 Nehalem processors that allows processor to offload memory paging required by the guest OS that is traditionally done by the VM with shadow paging.
Since it is a new feature, it is not available in the configuration UI yet.
First, you will have to enable hardware virtualization (VT-x/AMD-V) in Settings -> Advanced. Then, nested paging can be enabled as described in the VirtualBox User Manual with the following command:

VBoxManage modifyvm   -nestedpaging on

The performance boost is quite noticeable.
The boot up time for my virtual Windows XP has drop from about 25 seconds to 18 seconds.
Super PI Mod has dropped from 39.159s to 36.016s
Various benchmarks on the net show performance boost up to 30%.
I'll run more benchmarks next time.