DIY Prox Probes

I wanted to see if cheap inductive proximity switches could be reworked to output a voltage proportional to displacement. This is what it looks like on the inside after I ham-handedly snapped off the fragile copper coil (inductor). Some strands of the coil are visible on the right trapped in potting epoxy.


On the inside they have this PCB connected to the coil and three pigtails that are Vs, GND, and a high/low signal indicating the probe is some distance from a conducting target. The LED lights up when you’re in range of the target.


I tried to reverse engineer it and came up with this circuit (possibly wrong, and I’m not sure where the coil attaches – it’s made of very delicate wire and tore off when I was trying to remove the potting epoxy):circuit

Resistors values are all visible, don’t know what the caps are, all transistors are NPN type. I think it’s probably an oscillator that excites an LC or RLC circuit, but my circuit analysis skills are insufficient to make heads or tails of it now. Eddy-current or inductive proximity probes are a very common vibration sensor in industrial turbomachinery, but are way outside the hobbyist budget. The premise is very simple so I’m curious why they get so expensive.

Posted in Uncategorized | Leave a comment

Reviving a bricked Arduino ProMini

Something anomalous happened to the ProMini on a flight about a month ago, and the ProMini would not run the sketch that was uploaded to it. I tried to reupload the sketch and got the following errors:

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x40

Thinking somehow the bootloader got corrupted, I tried to reupload the bootloader, but received these errors:

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

Now I think some of the fuse bits on the Atmega328 may have been corrupted or changed, so I’m trying to read them using my Uno running the ArduinoISP sketch. I removed the Atmega328 from the ProMini and soldered it to a breakout board (after failing to make my own). I had to translate some of the ArduinoToBreadboard pins from 28-pin DIP to the 32-pin TQFP that the ProMini uses. Here’s what I came up with:

UNO---->328 Breakout 
5V----->Pin 4,6,18 (Power)
GND---->Pin 3,5,21 (Ground)
11 ---->Pin 15 (MOSI)
12 ---->Pin 16 (MISO)
13 ---->Pin 17 (SCK)
10 ---->Pin 29 (Reset)

But when I run the following avrdude command

avrdude -P com3 -b 19200 -c avrisp -p m328p -v

I get what I think is a failure to communicate with the chip. I don’t know enough about avrdude to interpret or troubleshoot this.

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature. 
         Double check connections and try again, or use -F to override 
         this check.

This is a stream-of-consciousness post. I’ll add and modify as I keep working it.


Posted in Uncategorized | Leave a comment

Helicopter upgrades and stupid I2C problem

I replaced the stock 11T pinion with a 12T pinion, and replaced the stock E-Flite 800 mAh LiPos (68 g) with Turnigy Nano-Tech 370 mAh (38 g) batteries. The Turnigy batteries are 30 g lighter, and deliver 7.5 to 8 minutes of (mostly hover) flight. These modifications, in addition to the throttle gain increase described here, make the helicopter very zippy – it lifts off at ~50%. I’m replacing my Sparkfun RedBoard and SD card shield (35 g combined) with an Arduino Pro Mini and MicroSD breakout board (6 g combined). The combined changes should give me sufficient T/W for experiment with sensors on board.

I have several FreeIMUs that I built myself a while ago, but never got farther than running Fabio’s yaw/pitch/roll demonstration. The FreeIMU library is very large, and takes up almost all of the ATmega328 memory, so I’ve been experimenting with communicating with the sensors directly via I2C so I can have a lightweight program to log raw data to an SD card. I’ve discovered that the MPU-6050 is a very complicated little device – its user manual and register map total 98 pages. The HMC5883L compass is much simpler, so I decided I’d start with that sensor. However, I encountered weird behavior where sometimes I could access the compass via I2C, but sometimes I couldn’t. The screenshot below shows the ouput of I2c.scan() – it only identifies the MPU-6050 accelerometer/gyro at 0x68 and the MS5611 barometer at 0x77.


Fabio has the HMC5883L compass tied to the MPU-6050’s auxiliary SDA/SCL – not the main SDA/SCL – and the MPU-6050 blocks I2C access to devices on its auxiliary bus unless certain bits are set. Fabio’s FreeIMU library sets these so I2C can access the HMC5883L, but they reset when the power cycles. So before running I2c.scan() I set the following registers on the MPU-6050:

I2c.write(ACCGYR_ADDRESS,0x6B,0x00); //Take device out of sleep mode I2c.write(ACCGYR_ADDRESS,0x6A,0x00); //Disable master mode, precondition to enabling I2C bypass                                                                                   I2c.write(ACCGYR_ADDRESS,0x37,0x02); //Enable I2C bypass

And after all that head scratching, I can see all three devices on the I2C bus.


Lots of reinventing the wheel. Blerg.


Posted in Uncategorized | Leave a comment

Raw IMU data from helicopter flight

I put an IMU (Fabio Varesano’s FreeIMU with the MPU-6050 and HMC5883L) on the helicopter and flew it until I crashed. The y-axis on all the plots below are raw ADC output, not scaled to engineering units, but the obvious message is the sensors get noisy as soon as the rotor spools up. I was using both sensors’, or Fabio’s, default settings. I think both have a low pass filter feature that I can tune, and I’ll try some different mounting techniques. I tried to fly level passes back and forth: the magnetometer X-axis looks almost useful and you can kind of see my turns in the gyro Z-axis. All of the accel channels are garbage, and clipped for most of the record.



I’m kind of re-inventing the wheel here, because the Blade SRX 200 has a really effective stabilization feature. When I opened up the receiver, it found it’s using an MPU-6050, and I suspect it’s using Invensense’s DMP. IMG_1131

The noise in the accelerometer and gyro is narrowband at 5.6 Hz (336 rpm). Magnetometer noise looks broadband, and by the shape of the amplitude, it looks like the LPF cutoff frequency is around 20-25 Hz.


Posted in Uncategorized | Leave a comment

LIDAR data from helicopter flight

I stripped the helicopter LIDAR setup down to minimum usable form factor and flew during lunch. Setup works pretty well, this time it looks like I got up to 31.8 m. I think the LIDAR malfunctioned for approximately 1 second near t = 140 s; the 40 m peak is erroneous. I still stay at full throttle for most of the flight, which I think will make controlling altitude difficult, but consistent with what people say about this little helicopter. While the helicopter is in the air, the throttle PWM duty cycle only varies between 59.5% and 63.9% (also, the full throttle duty cycle is a now a little higher than I measured before…not sure why). Next up, some state estimation and closed loop altitude control. I also ordered some lighter LiPo batteries – sacrificing flight time, but shaving almost 30 g of weight.


Posted in Uncategorized | Leave a comment

First try LIDAR on helicopter

It’s been a while since I worked on this project in earnest, but this weekend I tried to fly the helicopter with the LIDAR mounted to the tail to record altitude. I bought the original LIDARLite for $90 like 3 years ago. Since then, Garmin acquired PulsedLight (the original manufacturer) and now sells what looks like the same sensor for $150. The V1 LIDAR had an unfortunate cable – a tiny 6 pin JST where one of the wires is red, and the remaining 5 are all black, so it was very tough to distinguish GND, from SDA, from SCL, and so on. This weekend I realized that two of the wires had snapped off at the connector, and after a futile effort trying to reuse the the JST contacts, I decided to remove the JST connector from the board and solder my own (uniquely colored) leads to it.


My first sensor package is too heavy, and even with the throttle gain at 200%, I was basically at T/W = 1 and barely got off the ground. The plot below shows the LIDAR altitudes and the throttle PWM high period. I characterized the throttle signal before flying using pulseIn() (so take that with a grain of salt), and the command a 337 Hz (T = 2.96 ms) PWM with duty cycle = 37.4% (1108 us) at 0% throttle and 63.2% (1872 us) at 100% throttle. I think the highest altitude is 80 cm (31.5 inches) near the 8100 sample mark.


Here’s what the helicopter looks like now. I’ll trim some weight and try again this week. Expect rubber bands and hot glue.


Posted in Uncategorized | Leave a comment

Altitude control w/ Kalman filter

I incorporated a Kalman filter into the altitude control loop; it estimates altitude and velocity from a model of the helicopter and the altitude measurement from the LIDAR Lite. It doesn’t compensate for tilt errors, so it only works for small pitch and roll angles. The dynamics model includes a lag between issuing the thrust command and when the rotor thrust reaches steady state, so a transfer function Tactual/Tcommand = 1/(tau*s + 1) goes between the controller transfer function and the plant. This plot shows a climb to 20 m then a descent at 1 m/s. The black curve is the Kalman filter altitude estimate and the red points are the noisy LIDAR measurements.


This plot shows the commanded control output and the actual control output for tau = 0.9 seconds.


Posted in Uncategorized | Leave a comment