Wednesday, June 27, 2012

TTB Update: Tiny Wheel Bot (I guess?)


As I said I would in my Tiny Tank Bot post, I stole the electronics from TTB and ditched the mechanics because the bike chain treads are terrible. I just wanted to make something run, so I spent an hour after work making this:

I guess he would have to be called Tiny Wheel Bot. The wheels are polycarbonate lenses from a product at work. I just drilled a hole through the middle and wrapped electrical tape around the edge. The servos are screwed directly onto the wheels, and I globbed some ShapeLock around the servo output so it wouldn’t slip.

I cut a little strip of HDPE and zip tied the servos to it.

The control board and battery are stuck on the top and bottom of the plastic frame with VHB tape, and lastly I zip tied a tail made from music wire. This was so easy and quick compared to those stupid treads, all robots should come together this fast!

 The big wheels make him pretty fast, and the tail doesn’t have enough weight so he flips over sometimes when trying to back up, which is hilarious.
video

I had to tweak some motor speed values in the code, but otherwise it’s the same as the TTB code.

Tuesday, June 19, 2012

Obligatory Pyro System post


While I don’t have a lot of progress to show on Pyro System, I feel like I should put up a post here since putting up some robot videos on YouTube will inevitably lead to a lot a subscribers asking me why the hell I’m not doing stuff with fire. It’s been a long time since Prometheus, but rest assured Pyro System 4 is in the works. I have a lot of ideas to try and I’ve gained a lot of embedded control experience since then. It will be better than versions 1 through 3. Here are some key ideas:
Silent ignition system. No moving parts, no loud electric arcs. Yes I have a proof of concept working
Smaller than Pyro System 2. I really want it to be able to hide under a sleeve
Smarter than Prometheus. Distributed computing, flow rate feedback, information readouts, all kinds of cool stuff that will be fun to build and make the device easier to use
The focus is on good control, because after all, the point is to emulate the ability to control fire by pyrokinesis. Here is a preliminary schematic for one section of the system. Keep watching for updates on PS4.


UAV Progress: initial assembly


So after my initial UAV failures and the mild success of TTB, I’m ready to move forward with the tiny autonomous helicopter project, and to do it right this time. One of my self-imposed UAV rules is the constant wireless link to the ground, so I found these awesome 2.4GHz boards on eBay for about $2 shipped from Shenzen (how does anyone make money on that?). I spend a couple hours learning to use the SPI hardware on the PIC16F1824 and having that configure the radios, and now I have a good wireless setup for UAVs and tons of other projects. The Nordic chips are awesome, their built-in functions pretty much handle everything for you except frequency hopping, which probably isn’t necessary for most of the stuff I’ll use them for. 


I also had the “no IR for altitude sensing” rule, so I ordered a cheap ultrasonic rangefinder board. This was really quick to get up and running, but it seems to give me glitchy readings sometimes. Some simple software techniques can fix that.

I finally opened the box on my third Syma S107, and did the obligatory test flight to make sure it’s stable. I also measured the stock weight so I will have some idea of how heavy my additions are. Then I stripped absolutely everything off of it that wasn’t critical to spinning the rotors, and put on some music wire landing gear, which left this funny-looking thing:

A while back, I had designed a UAV PCB and had it made on the same panel as the TTB board, but a lot of my ideas for the UAV project have changed since then. I still populated it and hooked it up to the rangefinder, but after a weigh-in I decided there was way too much extra stuff that I didn’t want and scrapped it.

I ended up using two small boards that I threw onto my last PCB order just to fill space: a little breakout board for 14-pin SOIC parts with low-side FETs on the two pins that correspond to PWM hardware on the PIC16F1824, and a generic tiny H-bridge board. I populated these two, glued them together, and wired together the power and signal lines for the tail rotor H-bridge. This was stacked on top of the rangefinder board and the total electronics size and weight is now much lower.

I threw this assembly with the stripped copter and a 130mAh (stock capacity) lithium polymer cell on the scale, and the weight came in under stock weight! It actually will be able to fly carrying the new electronics.

I spent a while staring at the two main pieces trying to figure out how to attach them, and finally came up with this goofy setup with little plastic strips and tape. It seems to hold up well, it’s lightweight, and it lets the board move around which may reduce damage in a crash. I wired the motors in and the first spin up was successful. Initial tests of simple hover algorithms were awful, I think because the rangefinder gives me a bogus number about 25% of the time. While I was trying to figure that out, I wrote a routine to play a little tune on the motors before it starts up. This idea came from Shane Colton's MIDI scooter. I just run the main rotor motor PWMs at a very low duty cycle (so low that they don’t spin the rotors), and adjust the frequency to play different notes. A bonus feature without any extra hardware! It's a little hard to hear in the video:
video

I took the helicopter with me on vacation (where I’m writing this from now), and I had just started to make some progress on hovering when a ceiling crash ripped one of the motor wires off the PCB, so development will have to wait until I’m back and have a soldering iron. The attached code includes playing the tune and all the basics for running the helicopter hardware, but hovering isn’t working yet. I implemented a basic slew-rate limiter to clean up the data from the rangefinder, and that seems to work well.
UAV 2.0.asm

Tiny Tank Bot




I decided to build TTB after losing two helicopters at the beginning of my tiny UAV project. Making a flying robot as a first foray into robotics is a lofty goal. After my initial UAV failures, I decided that I needed to prove I could actually build a robot that actually worked and didn’t flee from me, before I was allowed to try a third time on the UAV. Somewhere along the line I had the idea that it would be really cool to make a small tank-like vehicle that used bike chain for the treads, so these things were combined into Tiny Tank Bot. The goals for TTB were simple: make it actually move on bike chain treads, and just run a simple obstacle-avoidance algorithm. 


Electronics
The processor is a PIC16F1824. I used infrared for obstacle avoidance, using the same technique from my initial helicopter attempts. I don’t like the hacked servo technique for doing bidirectional drive, so I made my own H-bridges on the PCB. I also added an indicator LED, connections for switches (bump sensors), and I threw a 38kHz infrared receiver on there in case I wanted to do remote control.


Mechanics
I had originally bought some tiny gear motors but they turned out to be underpowered. As it turns out, making tiny tank treads out of bike chain IS A TERRIBLE IDEA. A series of factors such as: 1. Chain pitch too large 2. Sprockets made by hand with a Dremel 3. “Journal bearings” that are really just holes in an aluminum block and 4. No room for real tensioners,  all lead to an enormous torque requirement just to move the treads. Instead of addressing any of these problems, I just used MORE TORQUE. I ordered some fairly cheap Tower Pro metal-geared servos, removed the control boards and pots, and wired the motors directly into my PCB.
My axles were made from #6-32 screws with some unthreaded length to go through the bearing blocks. I made couplers out of some F-F standoffs by drilling and tapping a radial hole for a #2-56 set screw to contact the axle (which was filed to a D profile where it went into the coupler) and drilling radial hole through all to put a shear pin into the servo shaft. The short, splined servo output shaft thing is terrible for interfacing to anything that’s not a servo horn, so I drilled a 1/16th hole straight through it radially. A put a small pin of something soft (copper wire) through my coupler and through this hole, and hope that it will shear off before destroying the gears in the servo.

The frame is a 4” square of 3/16ths aluminum, and the bearing blocks are chunks of ¼” aluminum with the axle holes and tapped #4-40 mounting holes orthogonal to each other. Tensioning the chains was a pain, but I just kept messing with these little arms made from music wire until the chains stayed on. It also provided a cool-looking kind of suspension, and raised up the front of the vehicle to help climb over stuff.

Software
For obstacle avoidance, I used a technique with an IR LED and a phototransistor that I had developed previously. I read in a voltage level from the IR sensor, then turn on the IR LED and read again. Measurements are subtracted and then a bunch of samples are averaged, and I know if an object is there reflecting the light back to me. I never ended up implementing the bump sensors or remote control (mostly because the mechanics turned out so bad that I didn’t want to pursue the project any further). The motors are able to be PWMed (very slowly (about 1Hz), as I found this is the only way to make geared-down motors run slower without killing the torque) by two identical interrupt routines that run off two identical timers. The routine can also run them in either direction. The main loop just updates two variables, one for the speed of each motor. 127 is stop, 0 is full speed backwards, and 255 is full speed forwards.
The software has the tank drive along until its reflected IR number goes over a threshold. Then it stops, backs up, and turns by running one motor forward and the other backward. It keeps turning and measuring IR until the obstacle is no longer visible, then continues driving along. After 5 turns, it toggles a flag and will then turn the other direction for the next 5. I found that this number gets it out of most situations without getting stuck in a loop in a confined space.
video

And TTB works! Barely. The tank treads are awful. I originally wanted to do tank treads so it could drive outside, but the mechanics are so bad that anything but smooth, flat ground just stalls it out. I did accomplish my goal of making a working ground-based robot, so I’m allowed to continue on with helicopters now, but I won’t be continuing to develop TTB any further. The PCB and the code for it seem to be pretty good though, and easily transferrable to other kinds of robots. I think I’ll end up leaving the frame and treads intact as a paperweight, but remove all the electronics and put them on something that works a bit better mechanically. I have some ideas which I’ll try out after I make some UAV progress.
TTB 1.0.asm

UAV Beginnings


Here’s my first project post! It is a bit lacking in pictures because it chronicles a series of mishaps which did not result in any functional device. I’m writing it though because it’s important background information for subsequent projects. It turned out to be ridiculously long-winded, so skip to the rules at the end if you’re not interested in the details that led me there. As I will do in any post that mentions some software I wrote, I’ve attached source code to the post. 


Ever since I got my first tiny, 2-channel, IR-controlled, indoor RC helicopter (probably ~7 years ago) I thought about making one autonomous. Back then that goal was way out of reach, but my embedded control capabilities and build skills have progressed far enough since then to make it achievable. I started real work on the project a few months ago. I am using the Syma S107 because they are amazing and only cost $20. My first step was to learn the commands that the remote sends so I could use a microcontroller to command the helicopter. With the help of a lot of online info from people who had already done this, I had the helicopter running pre-programmed flight paths in a few hours:
video

This success got me so excited about the project that I spent about 2 hours the next day putting together a mess of freeform-soldered components and taped them to bottom of the helicopter. There was a PIC 12F617, two IR LEDs, and an IR phototransistor. The PIC used a simple algorithm to get a distance measurement from one IR LED and the phototransistor, which were both pointed down at the ground. It would take an analog reading from the sensor, then turn on the LED and take another, and then find the difference between the two. A series of these measurements were collected and then averaged and the final value gave a crude indication of whether an object (the ground) was there and how far away it was. The PIC then used this measurement to turn the throttle variable up or down, and an interrupt routine periodically sent a command to the helicopter over the second IR LED, which was taped right up against the receiver on the helicopter.
Once I got that all up and running, I tried to test it in the lab at work and it kept crashing into things. So I took it outside to the parking lot. At first, it worked great. The IR reflectivity of the pavement was very low, so the setpoint I had established inside corresponded to a height of only about 4 inches outside. But it did actually manage to automatically regulate its altitude, and it floated around the parking lot for a couple of minutes. Then it suddenly took off straight up, and kept going up until I could barely see it in the sky. It was hit by a gust of wind, knocked over, and crashed irretrievably on the roof of the building. I went inside and ordered two more helicopters.
While I was waiting for those to arrive, I had time to think about the stupidity of rushing to make it fly and doing things half-assed, most notably by preserving the IR control and adding extra stuff to the outside of the stock helicopter. So when my replacements arrived, I ripped it completely apart and desoldered their unmarked (bastards!) microcontroller from the board. Then I traced all the connections so I could map the pinout, and replaced their micro with a PIC16F1824, one of my favorites.
<stock pcb image to be added later>
The board was fairly simple to understand—it needs to control two motors for the main rotors with variable speed but only one direction, and a third motor for the tail rotor that pitches the helicopter at variable speed and in both directions. Therefore it has an N-channel FET (or an NPN bipolar if they’re cheap) switching the low side of the two main rotor motors, and an H-bridge formed by four transistors for the tail motor. They also have the IR receiver, an LED, two current sense resistors for the main motors (awesome! But they obviously didn’t implement an overcurrent shutdown in software. Maybe they used them to help balance rotor speed, but I see no performance improvement between models that don’t have them to those that do), and a mystery sensor on a tiny daughter board:
<sensor image to be added later>
If anyone knows what this sensor does, please tell me. I can’t figure it out. Anyway, I wrote code that uses the two CCP modules to do PWM on the main rotors and an interrupt routine to (more slowly) PWM the tail rotor in either direction. I made a function that sets all the outputs based on four variables: throttle, yaw, yawcorrect, and pitch. This is called periodically, so all the main loop has to do is put the desired values in those variables and the motors react accordingly. With all that done, I wrote a simple main loop (which wasn’t really a loop at all) to gradually spin up the rotors and do a quick hop and then shut down, and the helicopter flew under my own software control!
I then used an available GPIO pin to run an IR LED, pointed down. The first iteration of my IR altitude detection had terrible range, so I had the neat idea to keep the integrated demodulated IR receiver that was already on the board and use that instead of my phototransistor. This gave me a huge amount of gain because of the internal amplification and band-width filtering, but with the disadvantage of being a binary output instead of an analog signal. If I pulsed my IR led at the carrier frequency used by the remote, the receiver would pick it up if the ground was there to reflect the light. I discovered another neat trick to get a bit of variation out of the sensitivity: if I intentionally skewed the frequency I was putting out on the LED, it would decrease the sensitivity of the receiver, and the ground would have to be closer for it to register. This seemed to work pretty well, but it was almost impossible to automatically hold an altitude when my only altitude data was “yes” or “no” instead of a number. I was making pretty good progress (despite having to fish the helicopter out of some bushes in my yard) until I flashed a new algorithm that sucked, and it took off straight up until I couldn’t see or hear it anymore.
That night I decided to make the rules, and I was not allowed to even open the box of my remaining helicopter until I had the ground work laid to follow them. I also decided that I was required to build a functional non-flying robot before I started on the next helicopter, and that’s where Tiny Tank Bot came from.

Everett’s rules for tiny autonomous helicopters
1. Infrared cannot be used for altitude sensing. It is way too dependent on the reflectivity of the surface and way too susceptible to sunlight interference. The exception to this rule is if I actually measure the travel time of a reflected infrared pulse, but at 3 nanoseconds per meter, I doubt I’ll find a microcontroller fast enough to do that.
2. All outdoor tests must have a failsafe wireless signal. While it’s in the air, I’ll have a transmitter on the ground continuously sending the “ok” signal, and the helicopter will initiate a landing sequence if the signal stops. Adding the hardware to comply with this rule also opens up a lot of new capabilities for the device, like radio control and telemetry.
3. All alpha tests of new hover algorithms need to have a shutdown timer implemented in software of no more than 60 seconds.

Code:
helicopter preliminary.asm For PIC12F617, transmits throttle value based on IR proximity sensor. This code emulates the controller IR protocol, so with modifications it may be useful for anyone who wants to build a custom remote control for a Syma S107.
UAV 1.0.asm This code doesn’t work! That is, the hover algorithm doesn’t. It still has good base code for running the three motors in the helicopter.

Monday, June 11, 2012

new blog

I'll be posting info about some of my electronic/mechanical/pyrotechnic projects in the near future. I haven't posted any YouTube project videos for a long time, so I have a bunch of things to share and I think this will be a better medium than video alone. Here's my YouTube page with all my old stuff: YouTube.com/everettbradford

test post

test!