Category: ToyBrain
Further Troubles with TinyRobos
The white version of the TinyRobo board that has the missing ground trace also doesn’t have a proper connection for the pullups on the I2C address lines for the motor drivers. The drivers are still there, and scanning the I2C bus with a Bus Pirate (Amazon) showed me that they were at 0x63 and 0x64 on the I2C bus, rather than where I expected them to be (at 0x66 and 0x68). The difference is consistent with a connection that should have been to Vcc being left open.
I’m not wild about the problem, but it did give me an opportunity to set up and use Pulseview/Sigrok, my cheap clone logic analyzer, and my Bus Pirate, so it’s not a total waste.
For my own future reference, as well as anyone else who’s interested, the way to set up the Bus Pirate on Ubuntu is this:
- Plug it into a USB port
- Open up a terminal and type screen /dev/buspirate 115200 8N1 , where /dev/buspirate is whatever device your bus pirate ended up on. Mine was /dev/ttyUSB0.
- The terminal will go blank. Hit enter, and you should get the “HiZ>” Bus Pirate terminal.
The I2C bus scan is run by hitting “m” to get the menu, “4” to get I2C mode, “3” to set speed to 100kHz, and then “(1)” to run the scan macro.
The cheapo logic analyzer I got is a USBee & Saleae clone, which I got because I’m bad and should feel bad not rich. It has a switch to determine which device it claims to be. In Saleae mode, Sigrok loads an alternate firmware onto it, so I’m not really sure where that falls in the intellectual property/doing the right thing by small businesses framework, but if you can afford one, get a proper USBee or Saleae. They’re much better built (the Saleae Logics in particular are tanks) and have more and better features.
I’m doing all this stuff in Enschede, at U. Twente. I’ve been hanging out with the people in the HMI group, which “does things with stuff”. They do a lot of work with things like proxemics in interaction, socially aware robots and technology, and so forth. There’s something of a distinction here between technical stuff, which is what I do a lot of, and more abstract work with avatars and such. I’m a better fit with the RaM (Robotics and Mechatronics) group, which builds things like pipe-crawling robots and quadcopters.
Bugs in new boards
I seem to have left a ground connection off the PCB, which causes the 3.3v regulator to not work. I’ve fixed it in the PCB design in the repository, but the DirtyPCBs order link goes to a product that doesn’t work, so I still have to fix that.
Since I’m going to have to do a new version of the PCB anyway, I’ve added a blinky light on one of the IO pins so that I can have an additional channel for debug information.
New Swarm Controllers
I’ve ordered the second version of the swarm control boards. If you want some, you can get them here, but I advise against doing so until after a post shows up here saying either that they work, or that they’re busted.
In the mean time, I’ve been realizing that the boards are good for all sorts of stupid tricks. For instance, you can control people using galvanic vestibular stimulation, which uses 1-1.5mA at pretty low voltages (More academic version, more hacking). Since the swarm control boards already use a 3.7v lithium cell, additional voltage regulation isn’t needed (if anything, they may be too weak), and PWM can be used to control the current. A resistor in series might also be good, in case of… errors.
The same board could also be connected to a door latch, or magnetic strike, which would let a user connect to a web page (the ESP8266 can serve web pages and act as an AP) and put in a password to open the door. Lockitron appears to be making a business out of selling this, but the mechanics are cheaper.
Given that there’s also an I2C bus on the device, IO expanders, sensors, and other goofiness could be added to make wearables that respond to the environment, smart dust sensors, IoT nodes for home automation, scales that tweet about how much you weigh, etc. IoT is the new black! It’s a floor wax! It’s a dessert topping!
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…
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.
A New Contender!
As I mentioned back in this entry, I don’t think the further development of the ToyBrain controller is useful. The main use case is amply solved by the Pololu Baby Orangutan. However, there is a project that I want something similar for, where the Baby Orangutan won’t work.
The idea behind the project is to make cheap swarm robots out of small robot toys, using something like the ToyBrain or Baby Oranguntan, but with wireless. The Moteino has wireless, but no motor drivers. The Baby Orangutan has motor drivers, but no wireless. The solution, then, appears to be to make a motor driver shield for the Moteino or a wireless shield for the Baby Orangutan. Of the two, I’m more inclined to do the motor shield for the Moteino, but I haven’t done any really analysis.
Potential ToyBrain Substitutes
The point of the ToyBrain project isn’t really to create the ToyBrain hardware. It’s to allow me to have a module that I can drop into children’s toys to add programability. Building the actual ToyBrain modules kind of got off into the weeds a bit, so I’ve taken a look around to see what the prices are like for modules that do more or less what I want. Here’s a comparison.
The Pololu Baby Orangutan. ($20) The Baby Orangutan has a 20MHz ATmega328P microcontroller (32k ROM/2k RAM) and a dual H-Bridge motor driver that can supply around 1A continuious power per channel.
The Cal-Eng MicroDuino ($25) Uses a 16MHz ATmega328P and a dual H-bridge that can supply 800mA per channel.
The Cal-Eng NanoDuino ($35) Essentially the same hardware as the MicroDuino, but about the same size as a penny.
The TinyCircuits TinyDuno + TinyShield Motor ($20 + $20) ATMega328. The motor shield can drive four motors, but has an upper limit of 500mA without heat-sinking, so it would need either a heat sink or for the driver channels to be paralleled. It also needs an $18 programming shield, but that’s a one-time expense. Measures about an inch square, and can be cut down to be round.
Microduino Studio Microduino ($?) Not available yet. Proposed hardware is in line with the others, but the motor driver, programming board, and CPU are all seperate, so the system cost will likely be around $40-60 per system. The proposed motor driver is the A3906, which is a dual 1A H-bridge.
Femtoduino ($12 + $5) ATMega328P microcontroller, 400mA per channel motor driver board. Cheap and very small (dime-sized), but the motor driver is weak.
Digispark + Motor Shield ($9 + $10) ATTiny85 (8K ROM/512 RAM) with 6 IO lines, 4 of which would be used to drive the 1.2A motor drivers. Smaller than a quarter, and very cheap. This probably does not have sufficent IO for my purposes, and is barely cost-competitive with the Baby Orangutan.
Looking at the available competition, if I want something better than just buying hardware, I have to essentially make the Pololu Baby Orangutan, only smaller, and with a higher output current. If there’s a 2A dual H-bridge motor driver IC available, this might be possible, but it won’t be by continuing the development path that I’m on (with a socketed, replacable motor driver). The STMicroelectronics L620x series bridges look good, but cost $7, so my $20 budget for parts would be half-blown on one IC.
For my projects that would have used the ToyBrains, I’m going to use the Baby Orangutan controllers instead. I may eventually see if I can get a small board together that uses the through-hole motor driver chips, but it’s not going to be a big priority.
ToyBrain Version 2 Firmware Troubles
I’ve started trying to load a bootloader onto the V2 hardware for the ToyBrains, as part of attempting to make a luminous fez for my girlfriend. I ran into a few problems.
The first problem I had was that the IC I’m using is the ATMega328, not the ATMega328P. So far, the only difference I can find between the two is their voltage range, but they have different ID strings. To get around this, I duplicated the chip definition for the 328P in avrdude.conf, and replaced the ID with the proper ID for a 328 (no P). This seemed to work for getting the Arduino IDE to burn the bootloader to my chip.
Unfortunately, I had made the Arduino boards.txt file description of my board by copying the Arduino Nano section. This includes a fuse setting for an external clock crystal. The toybrain boards don’t have a clock crystal, and use the internal RC oscillator of the Atmega328 instead. This meant that when the board was reflashed, it had no clock, and so not only could it not be programmed from the IDE, it also couldn’t be reflashed with a new bootloader using the USBTinyISP. The big symptom of this is that avrdude immediately fails to init, and if I used the -F (force, which you should never do) flag, it reported a part ID of 0x000000.
To fix that problem, I wired two small caps and a crystal to add an external oscillator to the board, tacked it to the appropriate pins, and reset the flags.
At this point, I think I have the bootloader installed, and the fuses at least mostly correct. The Lilypad Arduino with the ATMega328P uses these fuses: Low: 0xE2 High: 0xD8 Extended: 0x05, which mean that the clock is internal, and not divided by 8, so it runs at 8MHz. The bootloader settings set the size of the bootloader, which is the same as the one I am using (ATmegaBOOT_168_atmega328_pro_8MHz.hex), and the boot interrupt vector.
However, I still get a problem when I attempt to upload a program to the device. If I set the upload speed to 57600, avrdude beefs about the chip ID. If I set it to 19200, avrdude says the programmer is not responding.
My current guesses at the cause of the problem are these:
- My clock settings are slightly off, so the chip is running at the wrong speed for the bootloader. As a result, the serial data rate is bad, and the data that avrdude gets back is nonsense. This can be fixed by applying the above fuse settings via the USBTinyICSP.
- I have the reset vector or bootloader size setting wrong, and so the chip doesn’t start the bootloader correctly when it is reset. Again, this is a matter of fixing the fuses.
- Something else that I haven’t considered yet, e.g. there is something wrong with my hardware.
I’m going to work on it more tonight and see if I can get it going.
Toybrain further improvements
I populated one of the Toybrain V2 boards and gave it a bit of a shakedown. I still have to test the motor driver, but I’ve at least fixed the backwards ICSP header and the reversed TX/RX lines. I did add a LED for debugging, but then hooked it up to a ADC line, so lighting it up means losing an analog pin.
For those as don’t know, you can get the analog pins on an Arduino/ATMega168/ATMega328/whatever to act as a digital GPIO by treating it like one, using the aliases “A0” through “A5”. Full instructions are here.
The V2 boards also have a reset button, which is very useful.
I’m already working on V3, which is going to be smaller. The V2 has headers for power, ground, and data for each pin, which I think is a bit much. I want that room back to build a voltage regulator and some filtering onto the board. The microcontroller can run at 1.8 to 5.5 volts, so the filtering is a bit more important than the regulation. However, some toys surely run at 6 volts or more, and would ruin the microcontroller, which is a SMD device.
So V3 will include filter capacitors, probably SMD, on the power rails, and a 3.3V regulator (The Micrel MIC5209-3.3 in SOT233 package looks good) or the option to short around it. The regulator only supplies the power for the microcontroller, so it won’t need to be very high power.
Recent Comments