LED Glasses

Here’s another example of a totally useless project that I took on with no justification other than “because I can.” I love lights. At EDM shows, everybody loves lights. After going to my first Bassnectar show I decided I had to make some kind of wearable lighting system to wear to future shows. Not wanting to spend infinity hours stitching LEDs into clothing, I settled on LED glasses. Just lighting up isn’t enough though—they had to be painfully bright and do some cool effect that can complement music. 

On a long drive last year I thought of an idea for this—just pulsing lights to the music has been done before, but what about making the lights respond to body motion as you move to the music? The idea solidified as an accelerometer to measure hand movement which would control the brightness of the LEDs. The accelerometer had to be mounted on my wrist and get signals to the glasses on my head, so I’d have to run wires along my arm. No way, using wires on a wearable system sucks, and I have a stack of uNRF boards waiting for good applications, so I went with 2.4GHz.

Hardware: The accelerometer I used was ripped from a Wii controller clone from ebay (which I bought just for the housing) and gave me three analog signals for X Y and Z. Both transmit and receive sides would use my uNRF board with a nRF24L01+ and PIC16F1824. The LED driver is a MAX16820 3-Amp buck converter that takes a PWM control signal. The LEDs are just a ton of whatever I have lying around wired in parallel (because sticking high voltage on my face is where I draw the line).

Software: I already had basic code running on my uNRF boards to send and receive, so the radio link was taken care of. I went through a very interesting design process with regards to the signal flow from accelerometer to LEDs. In my initial exploration of the idea, I programmed one microcontroller to handle the entire process from reading acceleration data to outputting the LED PWM signal. I wanted the system to work regardless of orientation of the accelerometer so I set up the software to sample all three axes. 

The system only needed to respond to fast movement, so I wrote an algorithm that calculates a long-term (10-second) moving average for each axis and then calculates the absolute value of the difference between the instantaneous reading and the long-term average. These values for all three axes are summed to create a single value that represents total movement in the short term. This value is then fed into two processes that generate the PWM output. 

In order to create an effect that looked good, I wrote two independent processes that increase and decrease the PWM duty cycle. The increaser increments PWM any time the scaled movement value is greater than the current PWM value, and the decreaser decays the current PWM value at a steady rate. These two processes are triggered by timers that run in the interrupt service routine so they can each be configured to operate at different speeds. The values I settled on run the increase at 1000Hz and the decrease at 250Hz. 

All those processes working together created the whole signal flow, but I had to cut it into two sections separated by the radio link. To do this, I picked the point in the flow with the lowest bandwidth, which ended up being the total short-term movement value. This value is calculated in real time by the microcontroller on the wrist unit and then transmitted at 50Hz to the board on the glasses. The micro on the glasses takes the movement value and handles the PWM increase/decrease and outputs it to the buck driver. 

The final software pieces were some modes which I could switch by pressing a momentary switch on the glasses—I included motion control, lightning mode, strobe mode, and constant brightness. Lightning mode is a really fun one where the LEDs sit at low power and then pulse at full current for 50ms any time the accelerometer reads over a certain threshold; this gives a really cool effect of being able to throw lightning strikes. I also included the ability to scale down the brightness in all modes to 50%, 25%, or 12% (in case people at clubs yell at me).

Here’s  a preliminary software test before any hardware was built:

Build: I found some really cheap cool-looking sunglasses and started building the LED array. This involved a totally insane process of soldering 60 XB-D LEDs directly onto two strands of 30AWG bare wire, which I do not recommend. Nor do I recommend throwing that away and repeating the process with XQ-B LEDs when LED issues appear, and I certainly don’t recommend trashing that and building a third array with color XP-C LEDs. But yes that is what I did. 

When I had to build the array for the third time I decided to switch to a color instead of white and settled on green, so the final product used 56 green XP-C emitters. I build the array in two sections and laid them onto the glasses frame with hot glue. The technique I used was to lay dabs of hot glue on the plastic frame, lay down the leds (shaping by bending the wire between emitters), and then heat the LED strip with the soldering iron to melt the glue.

With LEDs down, the rest of the glasses build was just mounting the uNRF board on one side and the MAX16820 board on the other. I put together a simple 2S1P battery pack out of IMR 18650 cells with a long cable and a connector to power the system. Assuming an average of 50% brightness (certainly an overestimate), the pack should give me 2.9 hours of runtime.

The wrist unit was made from a uNRF board, the accelerometer board, and a small lithium polymer battery (which should last approximately forever at an average current draw of 1.3mA). To make it actually stay on my wrist and be removable, I made a bracelet out of shapelock to which all the components mount.

Here are some complete final system tests:

Here’s the software for the transmitter and the receiver.

UAV part 5: Switch to V911

Just when I started to make progress on my overvolted single-rotor helicopter, the tail motor blew up (as I knew it would). To move forward, I could have gone back to Syma S107s, but I’m starting to dislike the mechanical complexity of the coaxial system. I have a few of the WL Toys V911 helicopters and they’re awesome. Once you get a controller, you can buy the helicopters for $20, which is actually cheaper than the S107. The V911 is bigger, faster, and has more excess lift than the S107, and weighs in significantly lighter:

I stripped down one of my V911s to install a MATH board. There was no good place to mount the board so I made a 3D printed bracket that screws into the posts where the stock PCB attached. The bracket also has a tray to hold the battery. After I mounted everything, I found that the CG is too far forward. I’ll have to reposition the battery later to fix it, but in the meantime the V911 includes an easy way to compensate for this – the swashplate.

I plan on using the pitch control eventually, but for now I needed to lock the pitch and roll. I used pieces of music wire and bent them into links that connect the swashplate control horns to some studs on the frame. I intentionally left them too long so I can make adjustments by slightly bending the wires to reduce the length. This gives me pretty precise control and I was able to adjust everything into balance.

  

Then I had some weird issues with a lack of power from the rotors. I checked my PWM output on the scope and tested 4 different batteries (including the stock V911 battery) with no success. Eventually I figured it had to be my FETs, so I salvaged the motor FETs from the original V911 board and put them on my board, and that fixed it. I’ve never had issues with the FDN5630s that I always used on these boards, but this motor is higher current. Another difference is that on my first single-rotor I had higher voltage on the digital section so the FETs had a higher gate voltage to work with, so they may not have been saturated when I tried it here.

 I started with the same code I had used on my smaller single-rotor, and it held yaw immediately, but with some oscillations which you can see in the video. It’s very promising that the PID loop is transferable to a completely different physical system. I just need to make some adjustments to the gains now to get this one locked in. After that I’ll start on altitude control. I did a quick lift test by taping an ultrasonic rangefinder board to the helicopter to see if it could lift it. It could, but just barely. I’ll have to come up with another altitude sensing solution. I may just have to buy one of the more expensive rangefinders that use the single transducer.

I made some other progress towards helicopter autonomy this week—I got the optical mouse sensor working. The one I found in my junk bin was an Avago ADNS-1620. This part had no available documentation, but I did find a lot of similar parts with identical pinouts. They all have the same serial communication protocol, but some lunatic at Avago decided to put the same registers at different addresses in each variant of the sensor. I went through datasheets one by one and punched in new addresses until I found a set that worked. They came from the ADNS-2620 datasheet.

I now have the sensor reading out x and y movement, as well as a “surface quality” value, which is an indication of how good the focus is. I found that this value tracks the distance from sensor to surface with exact repeatability and plenty of modulation in the value as you move around near the target height… Yeah, that’s a free altitude indicator using a sensor that I was already going to include! The downside is it’s only for one specific altitude (whatever I choose as the focal distance with the replacement lens I find), but I think it’s a viable option. I may attempt that as an intermediate step before working out the weight issues with ultrasonic. Wouldn't that be cool to detect altitude based on the focus of the image of the ground?! This method has another significant drawback: if the helicopter goes high enough above the focal distance that it can no longer recognize the correlation of increasing height to decreasing image quality (because the image quality is equally low for different heights so far from the target), then it could just keep going up. Luckily I don’t have to worry about such things any more since I have the radio link, so I can experiment with it freely.

No code in this post, it’s still the same software as last time. I’ll upload a new one once I pull my mouse sensor functions in. 

Veloster Console Lighting

Here's the first of what I hope will be many posts about modifications to my new car, a Hyundai Veloster. I have a long list of ideas for things I want to do with the car and I thought this one was a good starting point. The car has a little tray under the dash directly in front of the shifter where I usually keep my work badge and other small things. I thought it would be a nice addition to have some lights illuminate the tray, but they would have to turn on and off automatically so they're not distracting while driving at night. There are some plastic handle-type things on either side of it, so I planned to put a beam break sensor across those to trigger the lights when someone reaches in.

Here's a schematic for the circuit I designed. It's run by a PIC12F615 and has an IR led and phototransistor for the beam, a 5V regulator, and three white LEDs driven by a MOSFET. After getting the dash open I discovered a good way to include a programming connector so that's included as well.

The software for the microcontroller operates the beam break sensor entirely in interrupts, and the main loop interprets that information and loads brightness levels into the PWM peripheral. The algorithm for the beam detection is a technique I've used before (in Tiny Tank Bot, among other things): the infrared LED is toggled on and off, and I take an analog measurement from the phototransistor in each state. The two values are then compared to see if they differ significantly, which indicates that the IR light from the LED is "visible" to the phototransistor. This technique works well to reject varying levels of visible light (and other sources of IR) that influence the reading from the phototransistor. Repeated comparison results are then accumulated in a counter so that a confirmed detection of the beam requires a number of consistent positive results. The duty cycle of the IR LED is kept low to save power. 

The brightness levels for the white LEDs are taken from a logarithmic table, and I played around with a variable timing technique on the ramp up and down until it looked smooth. I have the LEDs stay on at 1% while no objects are detected so there will be a nice glow on the tray. The software ramps up the brightness to maximum as soon as the beam is broken, but it waits for the beam to come back for 1.5 seconds without interruption before dimming back down. This makes the lights stay up for as long as you're reaching into the tray, and then smoothly go back down when you're done. Here's a software test on the breadboard:

Once the software and circuit were proven out, I built the circuit on perfboard. I left the IR LED and sensor on headers so I could disconnect them to make installation easier. 

Here's a test of the completed circuit:

 

Next step was the scary part: disassembling my dash. Luckily I found some instructions from a Hyundai service manual posted on a forum. The center piece of the dash that holds climate controls and two vents is held in by friction clips and can be pried off with plastic tools ( I made some from lexan stock I had on hand).

With that piece off there's plenty of room to work in there, and you can see straight down to the piece above the tray (which has the 12V outlets, aux input, and USB port). I could then see how to get that piece off: it's held in by the same type of friction clips, and it just slides straight out towards the shifter. There is a slot to put a (very short) flathead screwdriver in the back to pry it off. If anyone wants to reproduce this, you don't have to take off the climate control piece, just slide that little pod straight out until the clips pop off. I took that piece in to my workbench and prepared an LED board with three cool white XP-Gs. I drilled holes for the LEDs in the plastic and stuck the LED board down with VHB tape. 

The rest of the circuit went in next. It steals power from one of the 12V outlets, which means this is only active while the car is on. This is not ideal--it would be nice to have it on when you first get in the car and for a short time after turning it off, but this way I can be sure I don't make a mistake that kills the battery while it's parked. I could connect it to a 12V line that's on all the time as it only draws 2-3mA in the idle state, but I didn't want to run new wires to this area. 

At this point I noticed that the 12V outlets have little cutouts in the metal cylinder that are just big enough to pass a 0.1 header (pin strip) through, which gave me a perfect way to include a programming connector. I wired in the connector and insulated it with electrical tape. I then close the lid on the 12V outlet and it's completely hidden, but I still have the opportunity to update the code if I think of a change I want or if my parameters don't work anymore in the real application. Also, the signal from the phototransistor is shared with the data line, which may help in debugging since I can put it on a scope without taking anything apart. 

The outlet isn't usable like this, but that's unlikely to be an issue any time soon since there are two of them. Once I'm sure that I'm happy with the software, I can just push the connector up into the cavity and then the outlet will be usable again. Here's a test after everything was installed onto the plastic pod:

After I got to this point, I went back to the car and spent a whole bunch of time trying to get the plastic handle things open so I could install the two parts of the beam sensor. I didn't make much progress, and decided that it was silly to waste any more time on it when I could just change the sensor from beam break to proximity. Beam break would have given more reliable signals, but changing to proximity allows me to install all components onto a single piece of the dash, not run any wires, and also hides the sensor components from view. 

The change to proximity is almost as simple as inverting the logic in the software: turn the lights on when the IR beam is detected instead of when it goes away. In reality I also had to make some tweaks to increase sensitivity and chose a different phototransistor that performed better in that arrangement. You can see both versions of the software at the bottom of the post. After those changes, I drilled two small holes in the bottom of the plastic piece and stuck the IR sensor and emitter down there. The great thing about this location is that it's pretty much impossible to get your head low enough in the vehicle to see the bottom of this piece, so none of the modifications will be visible. 

Here's a final test of the electronics before being installed in the car:

Installation in the car was very easy, just pop the pod back in and plug in the connectors. Here's a camera shot from below where you can see the mods, but you can't see these while you're sitting in the car. 

And from the video at the top, you can see it works very well. So far it's properly detected my hand every time I reach into the tray, and I'll be watching to make sure I never get any false detects while I'm driving which would necessitate a code tweak. 

Here's the original beam break code and the final proximity code. 

Bonus project: 

While I had the climate control piece out, I decided to swap some LED colors just for fun. I changed the passenger airbag indicator from orange to blue (this one always bugged me because most of the other indicators are blue), and I changed the seat heat indicators from both orange to orange and red to indicate low and high heat levels. 

UAV part 4: single rotor

This is the helicopter I’ve been working on for the long period since my last post. After I got the coaxial helicopter up and running with my custom electronics, I flew it way too high outside and crashed it hard enough to break the plastic frame. Then I flew it without the frame like this:

That left the drive gears on the bottom exposed, and I broke one of the gears in another crash. That left all the mechanics pretty much useless, until I had the crazy idea of converting it into a single-rotor helicopter since I still had one working drivetrain.

The board I used for this one is a custom helicopter board I’d been designing for a while. This board put all the electronics I used on the 2.4GHz coaxial into a single PCB, but with a more capable microcontroller to allow for more functions. The board features are:

·         PIC16F1829 microcontroller

·         nRF24L01+ 2.4GHz radio transceiver

·         LY550ALH single-axis gyroscope

·         3 N-channel motor FETs

·         Breakouts for connecting ultrasonic rangefinder & optical sensor

This board is called MATH, for Mostly Autonomous Tiny Helicopter (although at this point it stands for Mildly Autonomous). The core functions are just to get me up and running on a helicopter with the radio link, but later I’ll connect in the ultrasonic rangefinder for altitude control and make it really autonomous.

The connections for the optical sensor (labeled “terrain imager” in the schematic) are for an idea I had that’s not yet tested: I have seen a few robotics projects where people used optical mouse sensors to keep track of motion by focusing them on the ground below the robot. I think it will be possible to use this technique on a helicopter provided I can find optics to focus the sensor on the ground at a height of 3 or 4 feet (and maintain altitude precisely). If this works, the helicopter could keep track of its path and position and navigate autonomously with high precision.

To make the single rotor helicopter, I stripped down the Syma S107 to minimal weight and removed one of the drive motors, gears, and rotor. The tail rotor is now needed for torque balancing so it has to aim sideways. Early tests showed that the stock motor wasn’t powerful enough for this job, so I make a custom tail boom to extend it and increase torque without increasing power draw. I later replaced this aluminum boom with a carbon fiber boom, and put a bigger propeller on the tail motor.

I was able to make the single-rotor fly, but it had to be stripped to less than 20g and run at full power just to stay aloft. Clearly I needed a bigger motor for the main rotor, but I decided to do something crazy just to make this one work, and went to a 2-cell battery to double the voltage. Now I don’t have to worry about weight so much and have power to spare. Unfortunately the motors get hot as hell and will probably burn out very soon, but for code development purposes this setup works well.

I started from scratch on the software to run this helicopter to keep everything clean. I struggled for weeks trying to stabilize the helicopter with my yaw control loop, and finally found the solution this weekend. I was using PID all along but could never seem to get my gains right, but then finally discovered that the control loop was being screwed up by noisy readings. The solution was to use a 100ms moving average (4 samples at 25ms) to get the yaw value from the gyro, and then derive the integral and derivative terms from that value. That smoothed things out and it finally stabilized.

It still jitters right and left, so there is more work to do. Once I’m happy with this I plan to work on adding a magnetic (non-contact) swashplate mechanism to this helicopter to control pitch. Here’s the code

Playstation controller

I had decided a while back that I needed to build a new, more capable controller for RC vehicles & robots. The goals were:
• More buttons for various functions
• More analog inputs than a single joystick
• Operated with two hands
• LCD display to show data sent back by the vehicle

I was about to start designing a board when I came across a PS2 controller. These can be found really cheap now that the PS3 has obsoleted them. Using these controller for robots is not a new idea, lots of people have done it, and they’ve put all kinds of information on the internet about how to interface with them. The controllers communicate with a form of SPI. It’s regular SPI except that the bit order is flipped to lsb first (where standard SPI is msb first). The protocol is close enough that I can use the built-in MSSP hardware in the PIC parts I’m using, if I do some data manipulation before and after exchanges. Thanks to all the people who have worked out the protocol and shared their findings, I got the controller working very quickly.

I wrote robot controller code for the PIC16F1516 (same as the one on the SAVIC board) that can talk to the PS2 controller, a Nordic radio, and a character LCD. The radio and the controller share the SPI bus, but they have different settings for clock polarity and data sampling edge, so I have to switch the MSSP settings before I activate each one with its slave select line. Later I’ll use the LCD to show data coming back from the vehicle, but for now it was just used to help me work out the bugs with the PS2 controller. It turns out the analog sticks on these give pretty messy readings, even with the genuine Sony controller. To counteract this, I’ve added a bunch of processing that the analog readings go through to center them and to apply a logarithmic curve to the output. The code can also poll the controller for which mode it’s in, so it asks you to activate analog mode before it does the centering and starts transmitting.

This first try worked out so well that I will definitely stick with the PS2 controller for robots moving forward. I’m currently working on talking to a graphic LCD so I’ll be able to display images from a camera on the vehicle. Once that’s finalized, I plan to build an add-on that attaches to the front of the controller that contains a battery, radio, LCD, and the microcontroller to operate them all.

Here’s the code for the robot controller.

SAVIC board

I finally got my Semi-Autonomous Vehicle Integrated Controller (SAVIC) boards in from batchpcb. I used this project to learn to use Eagle to do layouts; it’s my first Eagle board and my first batchpcb order. I set out to design the SAVIC board so that I could quickly and easily get moving with small robots instead of custom building new stuff every time I wanted to try something new. This board is meant to include all the features you’d need to get started on a small robot or RC vehicle, and intended to be modular so it can be expanded upon. SAVIC has:
• 2 H-bridges for DC motor control
• 2 high-current sinks for single-polarity loads with PWM
• 2 servo outputs
• 2 analog sensor inputs
• 2 digital (switch) inputs
• RGB status LED
• nRF24L01 2.4GHz radio
• HC-SR04 ultrasonic rangefinder connection
• SPI expansion connection
• PIC16F1516

I managed to pack everything into a 1.5x1.6 inch board. I had learned something about H-bridges from the board I originally used on the RC buggy. The P-channel FETs in that design had their gates switched by the drains of the N-channel FETs, so they were directly connected to the load. That worked for very small motors (in my 6” helicopter), but when I put a bigger DC motor on it, the inductive spikes ruined it. For the SAVIC board, I used bipolar transistors to invert the gate drive signals for the P-channel FETs.

The only issue I had with the first one I assembled was voltage limitations on the peripheral devices connected to it. I designed it to interface to HC-SR04 ultrasonic rangefinders because they’re so cheap and easy to find, but they have crippling supply voltage requirements. They don’t really work outside of 4.5-5.5V, where the PIC can run from 1.8-5.5V. The Nordic radios can’t go higher than 3.6V (but luckily the signal levels can be higher), and servos need 4-6V. On the board I put a 5V regulator to run all digital devices except the radio, which has its own 2.5V regulator. Servos pull tons of current when they move so I didn’t want to load the 5V regulator with them, so they’re powered directly from input voltage (as are the H-bridges). The problem is if I power the board with 6V, the 5V regulator doesn’t have enough overhead so the digital supply isn’t high enough to operate the rangefinder. If I go higher than 6V input, the servos get overvolted.

 The next revision will have to fix this somehow (probably by ditching the HC-SR04), but for now I’m running the board from 2 Li-Ion cells (8.4V) and putting a small adapter for the servo with an independent voltage regulator on it. One big advantage of this setup is that it overvolts the drive motor on the buggy like crazy, which gives it awesome speed and power.

I’m trying to transition to only working in C for robots, so I rewrote most of the functions I had already written for other RC vehicles. It’s programmed to used the same radio packets as the helicopter so I can use the same controller for both. The code has drivers for both servo outputs, bidirectional pwm for one motor, talking to the radio, and rangefinding. Once I got it operating well under remote control, I added an autonomous mode that just wanders around and avoids crashing based on data from the rangefinder. Autonomous mode is activated by a button on the controller, so I can switch between RC and auto on the fly.

Here’s code for the SAVIC board. Controller code will be in the next post.

UAV part 3: C code

Huge UAV progress in the last week. I had figured out that a gyroscope was needed for stable flight (that’s how the stock control boards do it) and installed a gyro on my helicopter, but I wasn’t getting anywhere on coming up with an algorithm that would accomplish stable flight. I kept working in my old source file which was written in assembly and was attempting to write very complex math with 16 bit values (actually 17 bit for some signed values) and it became totally unreadable. After years of working with PIC I reached the point where I couldn’t accomplish the goal without switching to a higher level language, so I set out one day to get things working with the C compiler.

I had been told by many people (including a Microchip FAE) that switching over to C would involve a whole lot of frustration in order to get the whole toolchain working, but it turns out they were full of crap. It was ridiculously easy, and in about 3 hours I had rewritten the entire helicopter source code in C and had it running. I keep running into bugs caused by the way the compiler handles math involving ints (16bit) and chars (8bit) (which I’m often forced to work with based on EEPROM hardware, radio packets, etc.), but once you solve a few you figure out the tricks to force it to work the way you want. Admittedly writing in C creates machine code that is bigger and slower than assembly, so for my cost- and/or time-critical applications (like the ones I write at work) assembly is still the way to go. However, for hobby projects like these, the cost of the processor is meaningless (even something ridiculously overpowered is generally under $1.50), so I have the freedom to run complex code on an awesome processor. Luckily (i.e. as planned) the 16F1824 kicks ass and can run huge amounts of compiled C with no trouble.

Once I got a version of sAAV v3 rewritten in C, I could do experiments and improvements way faster, so sAAVinC (semi-Autonomous Aerial Vehicle in C) evolved pretty fast and I learned all kinds of things about making machines like these fly. The code has now departed quite drastically from what the old assembly source was doing. I have it running a control loop based on the gyroscope reading at 10Hz, and polling the radio for new control packets at 4Hz. After a whole bunch of test flights I arrived at a gyro feedback control algorithm that’s awesome.

It has a proportional term based on a ¼ second moving average (4 readings) and an integral term at 1/4th the gain of the P term. I put in a slow decay on the integral term to counteract erratic buildup. I also do a long (5-second) period of measurements upon power-up to calibrate readings from the gyroscope to establish a baseline of what a rotation rate of zero looks like.

The gyro loop got so good that I didn’t need to do yaw trim any more. With no trimming in the code at all, the helicopter would spin for the first second of flight and then the gyro loop would figure it out and stabilize. To get it even cleaner, I started initializing the gyro integral term to an experimentally-derived value that compensates for extra drag on the top rotor. This initialization is done any time the rotors are stopped for any reason (before I did that, if I was flying and then landed (and possibly moved the heli by hand) and then started flying again, the gyro integral would have been building up the whole time so when I throttled up, only one rotor would getting power).

Another funny thing that happened is the gyro loop was so good that when I tried to send yaw commands, the gyro loop would see the turn as a disturbance and compensate for it, aiming back to the heading it started at. My solution was to remove the yaw command term from the rotor output calculation completely, and instead inject it into the calculations for the gyro P and I terms. Effectively what this accomplishes is: when a yaw command is sent, it makes the gyro loop think the vehicle has turned in the opposite direction, so the gyro loop does its job and counteracts it by turning in the direction the pilot wanted.

In order to make the controller more generic (to use with other vehicles), I moved the math that interprets joystick inputs over to the helicopter. Now, the controller essentially just sends the stick position and button information and the vehicle decides what it means. I’m still doing the same throttle algorithm where pushing the stick up and down adds or subtracts from the current throttle value at increasing intensity as the stick is angled farther from center. I also wrote an update for the controller that puts it into sleep mode so I don’t have to pull the battery when I’m done using it. The last control update was to have the helicopter gradually change to new pitch values (on the tail rotor) instead of changing instantaneously. This came after I kicked on the tail rotor while turning and caused the helicopter to roll and crash spectacularly, breaking the tail fin and tail rotor. Now, when I click the joystick in to toggle forward movement, the tail rotor speed gradually ramps up over a period of about 3 seconds.

The other items I put in the helicopter code are a low-power standby mode and some tones (played on the motor coils) to indicate things like power up, gyro calibration complete, paired with controller, loss of control link, and entering standby.

So now I’m at the point where I have control that’s just as good as the stock helicopter, but running on completely custom code and using a 2-way 2.4GHz radio link instead of infrared. The next steps are to build a more involved controller that will be better able to help develop autonomous functions, and to install ultrasonic altitude sensing on the helicopter. My weight is currently at 39g (stock weight is 42g). I plan to put double-capacity battery on that will bring the weight to 43g, and when I add ultrasonic I’ll strip down more of the metal framework to keep the weight at or below stock.

Here’s a video showing how good the control is. As far as I know, this is now the only Syma S107 in the world that is radio controlled, meaning I don’t need line of sight and I can fly outside in sunlight, which I’ve been wanting to do for so long. The second video shows an outside flight, which is fun because there’s nothing to crash into but difficult because the slightest breeze just carries it away. As you can see, the range on the radio is more than enough to fly so far away that you can’t see it well enough to fly anymore.

Here is the most recent code for the helicopter and the controller.

One more thing: if you have one of these helicopters, take the yellow USB battery charger and throw it in the garbage. I discovered recently that it significantly overcharges the lithium cell, leading to extreme danger of explosions and fire. It actually blew up two small hobbyking cells that I tried to charge with it, after it pushed the cell voltage up to 4.6V. Do yourself a favor and buy one of these chargers (but you should probably replace R2 with something around 5k to set a safe charge current).