ToyBrain Rides Again

Now with WiFi, current monitoring, and the ever-worrying li-poly battery chemistry.


I haven’t tested the WiFi module or motor drivers yet, but the board is fully populated and the battery regulation circuit works.

There are a few design changes in the pipeline, but I’m going to go for a full hardware test and try to find more bugs before I create version 2 of the boards.

The current design is in github, along with all the docs.

Un-Ubuntuing Ubuntu Redux

Ubuntu ships with the “main” and “universe” repos enabled, and the “multiverse” repo disabled. This is because there are legal or ideological reasons to not use the software in multiverse.

However, there are practical reasons to use the rar/unrar packages from multiverse over the unrar-free package in universe: unrar-free frequently doesn’t work, but unrar-nonfree does.

If you want your compression and decompression software to operate, rather than be ideologically compliant:

sudo apt-add-repository multiverse
sudo apt-get update
sudo apt-get install unrar rar

Bah humbug

The V2 toybrain boards have the diagnostic LED on analog input 6, which isn’t able to also act as an IO pin. Other than that, though, they work. This entry is mostly a note to me to fix that if I make another rev of the board.

Flashing bootloaders on an ATMega328 with the internal clock enabled

The V2 Toybrain boards are getting pressed into service for an art project that I’m working on, so I’m trying to get a set of them up and running. I use Linux, so the tools for talking to AVR microcontrollers are the Arduino IDE, and avrdude, which the Arduino IDE uses.

I started today by telling the Arduino IDE that my boards are a Lilypad Arduino with an ATMega328 on them. This isn’t true, but the electrical design of the board is such that this is close enough. I also informed the IDE that I had a USBTiny ICSP programmer. That bit is true. I had high hopes (because I’m lazy, and configuring the IDE is not the problem I’m trying to solve) that this would let me just hit the “burn bootloader” option in the IDE. Such is not the case. I got the error message:

avrdude: Warning: cannot open USB device: Permission denied
Error while burning bootloader.
avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)

I’m a normal user, and the permissions on the USB device are not such that mere users can talk to it. I figured I’d double-check by using avrdude as root (so the permissions would be ok). Then I ran into my next problem:

sudo avrdude -p m328p -c usbtiny
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9514
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
         Double check chip, or use -F to override this check.

The version of avrdude I have is 5.11.1, and doesn’t ship with a hardware definition for the ATMega328, just the ATMega328P. The P is for Picopower, and isn’t related to anything I’m doing (it mostly relates to the technology used to make the chip, and some power handling options like brownout detection). To get around this, I opened /etc/avrdude.conf and copied the ATMega328P hardware definition. Then I changed the descriptions and a few of the fuse bytes to match the parts I do have, and saved the file. Now avrdude doesn’t flip out about my chips.

Unfortunately, programming them through the Arduino IDE is still a bad plan, as the configuration for the LilyPad Arduino isn’t close enough to the hardware I’m using. Specifically, the Lilypad/328 configuration sets the lfuse bits to use an external oscillator, and I’m using the internal oscillator. Once the bad fuse settings are burned in, the chip doesn’t communicate unless it has a 8Mhz crystal attached to it. The error message from avrdude is:

avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

I added a crystal (temporarily) to the bricked boards so I could reset the fuses, and they worked fine after that. One of them had the chip on 90 degrees from the proper orientation too, and gave the same error as the chips with the bad fuses, so that error can be anything from the wiring being bad to the chip being configured wrong.

To use avrdude as non-root, I put

ATTR{idVendor}=="1781", ATTR{idProduct}=="0c9f", GROUP="dialout", MODE="0666"

in /etc/udev/rules.d/99-usb-tiny-asp.rules and restarted udev. That lets users in the dialout group have appropriate access to the USB port for the programmer.

The commands to burn the fuse and flash the bootloader are:

avrdude -c usbtiny -p m328 -U lfuse:w:0xE2:m -U flash:w:/home/ams/arduino-1.6.0/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex

My current fuses are lfuse:0xe2, hfuse:0xda, efuse:0x05.

Now we’ll see if I can send a program to them…

Safety third!

Say what you will about globalization and the downfall of the USA, I still like ordering stuff from China. It’s cheap, and it takes so long to get here that I forget I ordered it, so it’s a surprise to me.

Recently, I got a bunch of li-poly battery monitors. These (not surprisingly) monitor li-poly batteries and sound an alarm when the battery voltage gets too low. Overdischarging a li-poly battery can damage the battery fairly quickly, and so may mean you have to buy a new battery. This is far better than overcharging them, which can start a pretty dramatic chemical fire.

The monitors I got are these or something very like them. The ones I have have a button which you can press to set the alarm voltage, with a default of 3.3V/cell.

Like a good hacker, I immediately opened one of them up. It has two ICs, one of which is a Atmel 24C02BN, which is a 2kbit I2C EEPROM. The other is unmarked. I had high hopes that it would be an Atmel part as well, or at least marked, so that I could possibly reflash it with my own firmware.

Having 16 pins counts it out from being any of the ATTiny or ATMega series, as well as any of the 8, 16, or 32-bit PICs. I imagine it’s something like an Elan microcontroller, and probably not super-well documented.

I did also find out that the speakers are simple dumb speakers, not beepers, so the micro generates the audio waveform for them. That means if I want to use the beep as a shut-off signal, I’ll have to do a little filtering, or add a 555 as a pulse stretcher.

Toybrain Returns Again

I found a motor driver chip that looks promising. It does not support easy (solderless) swapping of the motor drivers, but I’ve also had a bit of a shift in my use case. I’m still looking to lobotomise and re-animate children’s toys, but I’m doing it for swarm robotics on the cheap, so being small outweighs replacing the motor driver chips.

The IC is the TI DRV8830. It is a 1A single-channel MOSFET H-bridge with an I2C interface and automatic current limiting. The automatic current limiting makes it very hard to blow the driver by overloading it, so I don’t have to worry about replacing the drivers as much.

Giving up on the Shark Joystick

I’m going to hang on to the parts, but instead of reverse engineering the joystick control scheme for my Dynamic Controls Shark joystick, I’m going to replace the motor driver and everything related to it.

The main reason to give up on this is that it’s not the project I’m doing. The project is “build a mobility platform for fire art” not “reverse engineer a joystick”. Hacking the joystick would have helped with the real project, but it’s also a time sink. For $60, I can get a “100A” motor driver from China. It’s probably not good for 100A, but it will probably work well enough to let me get on with the rest of the project.

I had hoped that the existing motor driver was able to be easily converted to use my own control IC, but it has a very-fine-pitch surface mount part that appears to be custom silicon, so I can’t easily drop in a programmable replacement. THe custom chip is probably partly to blame for why I couldn’t interface to it, since only Dynamic Controls knows how they implemented the UART. I did figure out where the H-bridge drive lines were, so if I felt like it, I could probably drive it, but the difficulty would probably be on par with making my own driver, and the results would be messier.

Shark Interface Still Not Working

Apparently, having figured out how the Shark joystick sends its information isn’t quite enough to get it working with the motor driver. I wrote software to send the same information that the joystick would usually send, but didn’t get a response. Then I assumed that the way the data lines both go high before serial signalling commences might have been some sort of init signal, so I have an Arduino configured to send the same information, and I still don’t get a response.

It’s entirely possible that I don’t have the bit timing exactly right for the serial link, so I’m now working on bitbanging the serial in a more adaptable way, so I can test different bit lengths.

I’m going to keep plugging away at it for a bit, but I also have a plan B: lobotomize the motor driver. Assuming it uses an ATMega8 like the controller, I can pull the control IC and replace it with one flashed with the Arduino bootloader, and then use rosserial_arduino to control it from ROS. That does mean I’d want to log what the controller does before pulling it, so I have a rough idea what signals go where, but it would vastly simplify controlling the system.

Playatech started charging for their plans

Unfortunately for burners, you can no longer download Playatech’s plans for their furniture without paying them first. They used to offer the plans as free downloads, and then asked that you donate some small amount if you used them.

Unfortunately for Playatech, they left all the PDFs in a world-readable directory. The command line below gets the index of that directory, finds all the lines with “pdf” in them, gets the file names out using cut, and then downloads each file.

for file in `wget -qO- | grep pdf | cut -d ‘>’ -f 2 | cut -d ‘”‘ -f 2`; do wget$file; done

Further Hacking on the Shark

In my previous post, I described how the messages being passed between the joystick and motor driver of my wheelchair appeared to be a differential serial signal at 40,000 bits per second. The data appears to be call and response pairs. Messages from the joystick start with a ‘`’ character, messages from the motor controller start with an ‘a’.
Each message usually has 8 fields with a numerical value in them, and messages end with ’15’.

Tonight, I recorded the signal as I swept the joystick in a clockwise circle, starting at 12:00/full speed forward. Then I graphed the values of each of the fields.

Joystick messages

Fields one and two in messages from the joystick are the forward/backward and left/right axis of the joystick, respectively. The center position is around 128, full forward/left is 255, full backwards/right is 128, so dead center/off should be around 128 + (255-128)/2 or 191.

Field 4 is a very noisy signal between 191 and 128. It appears to peak with field 1 and bottom out with field 1, so it may be the raw magnetic joystick sensor value for that axis.

Field 8 is a very noisy signal between 128 and 255, with clear diagonal slopes at the maximum and minimum of field 1. It may also be related to the raw joystick signal.

Fields 3, 5, 6, and 7 are 191, 128, 132, and 128 all of the time. The joystick has four non-power-button buttons and a power button, and these fields are used to report their values.

Pressing the speed buttons raises and lowers field 3, from a maximum of 255 to a minimum of 128, in 4 steps. There exists a mode that changes the speed in finer steps, but as configured, this is the way my system works. When the speed is lower than half-speed, field 4 has the range of 191 to 128. When the speed is higher than half-speed, field 4’s range is 191 to 255.

Field 5 is 128 when the horn button is not pressed, and 130 when it is pressed.

Field 6 is 132 when the joystick is on and running, and raises to 140

Field 7 is 128 when the joystick is in motion mode, and 129 when it is in seat mode. In seat mode, forward and backward motion of the joystick results in up and down motion of the seat height actuator. The joystick does report left and right motion as well in chairlift mode, but it doesn’t have any effect.

Field 9 is 15, for end-of-message.

Motor driver messages

Fields 7 and 8 are mirror images of each other. Field 7’s minimum appears to be 128, and its maximum is 144. Field 8 maxes out at 236 and has a minimum of 220, so it appears to be 364-field 7. I’m not sure what this field’s value indicates, but it appears to vary with the joystick position, so it may be some sort of current monitor or motor speed monitoring signal.

Field 1 goes from 128 to 146 as the system powers on, and stays there unless the chairlift is used. It appears to transition sharply to 178 when the chairlift moves up, and back when the chairlift moves down, so it is probably connected to the magnetic reed switch that senses the chairlift position.

Field 2 drops from 192 to 128 as the system powers on, and stays there. Fields 3, 5, and 6 are 128 all the time.

Field 6 goes from 128 to 129 the message after the joystick enters chairlift mode, so it is probably an acknowledgement to the joystick that chairlift mode was entered.

Field 4 goes from 128 to 160 as the system powers on, and stays there most of the time. It returns to 128 whenever the chairlift is not moving, so it may be related to breaking or motor activation. Before field 4 goes to 160, the joystick does not send any position commands, so the fields from 1 to 6 may be state signals that the motor driver sends to the joystick.

Field 9 is usually the end-of-packet field, but there are regular messages from the motor driver that are of the form

a '146' '128' '128' '160' '128' '128' '135' '229' '26' '133' '167' '185' '15'

rather than the more usual

a '146' '128' '128' '160' '128' '128' '135' '229' '15'

The additional values do not appear to change. The longer messages occur every 49th message, regularly, and starting with the second message from the motor driver, so I do not think that they are glitches.