Tuxdroid with Debian (lenny/testing)

I ordered a tuxdroid from Firebox, and although they politely emailed me during the week to say that stock was delayed and it would be next week, they sent my tuxdroid yesterday and it arrived today, excellent service.

I’m used to buying hardware and discarding the CD that comes with it, since it’s usually windows only, but this is a GNU/Linux only device, and it doesn’t even come with software. I had already downloaded the setup program from their website in .deb form. I had to install python-ctypes before the .deb would install but after that all was routine. I also downloaded the UK voices, though they have some issues, notably they mispronounce some words used by the tuxdroid software, such as “tux” itself.

My nabaztag and tuxdroid together

It was routine to put the device together, a RF dongle in the shape of a fish (really) plugs into the USB on your computer, and communicates with the penguin. I plugged in the penguin to charge him up (very sensibly he has a rechargeable battery pack, which should make him much more portable than the nabaztag, and despite the instructions saying otherwise, I had to turn him on. His eyes lit up and he said hello. Very nice. Next I ran the tuxgi program, not the main executable, but just to play with the device. All seemed to be working pretty well.


I now ran the main gadget manager, which is installed in the accessories part of the gnome menu. I downloaded some gadgets from the community website and started to play. I was aware that not everything was working correctly. In particular the device claimed to be looking for a firmware upgrade interminably, and some gadgets like the RSS one locked up the manager. A little digging revealed this was due to Python 2.4 being used rather than 2.5. I quickly confirmed that 2.5 was already installed, but the issue is that at least for now, Debian links /usr/bin/python to python2.4, not 2.5.

tuxdroid in programming mode

So, I went into /usr/local/bin/ and edited the following scripts tuxfw, tuxgi, tuxsh and explicitly changed the python to python2.5. Now, when reloading the gadget manager, I was immediately warned of a firmware upgrade and went through the process to do this. This is interesting in itself, a programming lead is used to make a physical connection between the fish and the penguin. The upgrade failed first time, but was successful the second time. The RSS feeder gadget also no longer crashes.

Here’s an example of the change to show how trivial it is.

#python /opt/tuxdroid/apps/tux_framework/TFW.py 1 # CT change, run 2.5 instead python2.5 /opt/tuxdroid/apps/tux_framework/TFW.py1

Initial thoughts on the device are positive. It seems well designed, even for example, disabling its ability to turn when the power cable is plugged in. The gadgets show great potential. A remote control is supplied that allows the gadget manager to be controlled through the penguin.The obvious comparison is with the nabaztag. It is a wifi device that works independently of a computer, but does require continuous power. This means the device is hard to move around, and needs to be near power at all times (and obviously the wifi network), it also uses a central server for all its services, and although it has a limited API, this probably makes it harder for independent people to improve it.

On the other hand, tuxdroid is not wifi, and uses the RF link from the fish. Unfortunately early experiments suggest the range is extremely limited, even in the next door room the reception is poor, but I may just need to arrange the fish more carefully. The penguin is potentially much more portable, since the batteries allow it to be moved around the house more easily, but unless the range can be improved this might be somewhat pointless, since you still need to be pretty close to the computer. As an example, my wireless router and machine are close together here, and upstairs in the main bedroom we are almost overhead from the machines, the wireless network is still easily accessible and the rabbit works well. The penguin breaks up a lot, so it makes it very hard, or next to impossible to test some of his other features.

I have also (so far) failed to get the device to work as an audio device. I can see it from the various applications discussed in the instructions, but I permanently get a “unable to open audio device” error, maybe because the gadget manager itself is loaded. One nice thing about this device is that most of its innards are written in Python, and it so happens I am learning Python for a consultancy job at the moment, so I hope I’ll have more to report on this later.






Leave a Reply

Your email address will not be published. Required fields are marked *