Serious MOSFETs

Posted: August 27th, 2015 | Author: | Filed under: Uncategorized | Comments Off on Serious MOSFETs

image

I’m designing a simple H-bridge for simple but large projects. These are 300A 40V MOSFETS.


ToyBrain Rides Again

Posted: August 26th, 2015 | Author: | Filed under: Uncategorized | Comments Off on ToyBrain Rides Again

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

image

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

Posted: July 7th, 2015 | Author: | Filed under: Linux | Comments Off on 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

Posted: June 19th, 2015 | Author: | Filed under: Arduino, ToyBrain | Comments Off on 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

Posted: June 18th, 2015 | Author: | Filed under: Arduino, ToyBrain | Comments Off on 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!

Posted: May 27th, 2015 | Author: | Filed under: B work, Electronics, Reverse Engineering | Comments Off on 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

Posted: April 22nd, 2015 | Author: | Filed under: Robotics, ToyBrain | Comments Off on 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

Posted: April 5th, 2015 | Author: | Filed under: Reverse Engineering, Robotics | Comments Off on 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

Posted: February 26th, 2015 | Author: | Filed under: Electronics, Programming, Reverse Engineering, Robotics | Comments Off on 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

Posted: January 14th, 2015 | Author: | Filed under: Bad Ideas, Linux, Scripting | Comments Off on 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- http://playatech.com/wp-content/uploads/2013/05/ | grep pdf | cut -d ‘>’ -f 2 | cut -d ‘”‘ -f 2`; do wget http://playatech.com/wp-content/uploads/2013/05/$file; done