Saturday, December 16, 2017

Flakey sensor or circuitry again

After gaining confidence that, with proper ESD protection, the probe circuitry was not destroying my sensors (any more), I installed 2 more sensors for a total of 3 (alpha, beta and dynamic pressure) and went out for a road test.

After a few minutes' worth of run time -- some of it when parked and raising the mast, and some at the beginning of my road route -- the probe stopped sending data. It resumed momentarily after a minute or so, then stopped again and did not restart.

I had my computer handy so I did some debugging, and it turns out that one of the sensors was freezing up. It enumerated properly on the I2C bus, but when asked to give a pressure reading, it hung in its "waiting" state forever. The other two sensors worked fine.

Power cycling the probe did not help immediately. Note, from previous work, that the probe remains powered up to some small voltage due to the battery, and I did not remove the battery.

Later on, after leaving the probe off for a while and turning it back on, it started working again magically. Note again from previous work, that when turned off with the battery connected, the probe VCC dies down to a small amount over a few minutes, then remains at that small amount thereafter.

My current provisional conclusion is that the sensors are flakey, either because of how I am using them, or some detail of my circuit, or some internal issue that I am running into. I do not currently have an obvious way forward apart from an extensive re-design of my electronics and/or extensive debugging of the problem hoping to reproduce it.

Hobby servo accuracy is poor

I have been thinking of building a pan/tilt mount for the probe, at least for the road testing to allow me to program "sweeps" through different AoA/yaw combinations. Pan/tilt servo mounts are pretty common, using hardware like this one, so I figured I'd give them a try.

I purchased a Hitec D645MW servo and a Pololu 6-channel Micro Mastro USB controller and tried them out. Using the published conversion factors for the servo, I tried commanding it to 30 degrees and 60 degrees, based on the book conversion between PWM pulse width and output angle (0.08 degrees per microsecond). Here are the results below. Clearly the conclusion is that "out of box" accuracy for hobby servos, even this relatively nice one, is not to be expected.

I'm upgrading to Dynamixel AX-12A actuators and will publish my results.




Friday, December 15, 2017

Poor filtering is poor

I noodled around with the data from the road test, passing it though a 25-tap lowpass FIR filter. Here are the results -- purple is original, and green is filtered. The X axis is in seconds:


Looking more closely, we have:


Notice the 1 second delay, and the DC bias. Clearly this is not okay.

Now it's true that I studied signal processing at some point in my life, but that was literally 30 years ago. :) So I have a big ramp-up I need to do, and clearly I need to learn about, and implement, a proper Kalman filter.

The data above is nominally at 20 Hz, but because I have had trouble getting timers to work on my Arduino, what this really means is that I acquire data with a 50 millisecond delay in between. This is no way to acquire data. :)

And finally, it's possible that the road environment has more turbulence than flight, so it may be that the filtering requirements for flight are less stringent, which would mean I could defer the fancy filtering until later.

Therefore what I've learned here is:
  1. I need to move to flight testing sooner;
  2. This means I need to figure out my airplane mounting again -- the mount I bought was a bit wobbly, and maybe I should move to using a Citabria that has 2 struts for more stability;
  3. For this testing I need to buckle up and add my 2 other sensors to my probe and hope I don't fry them;
  4. I also need to get Arduino timers working so my data is at a consistent sampling rate (no sense paying for a flight test then using crappy sampling); and
  5. Meanwhile, I need to start learning about Kalman filtering.
That should keep me busy.



Sunday, December 10, 2017

First road test, Pitot only

Today I ran my first road test of the actual probe, using only one sensor, the gage sensor for the center hole relative to the static pressure probe. In that configuration, it was just a fancy Pitot tube. Here is the sensor mounted on the mast:



And here is the Airball display unit in the car, along with an XBee receiver connected via USB to my laptop acquiring the data for analysis:



I drove the car while my wife rode shotgun acting as Test Range Safety Officer [tm]. Her job was to look out for stupid stuff, and indeed she did catch some possible snafus with low-lying telephone wires and trees, and kept situational awareness on the general road environment.

Here is a video of a portion of our trip:




We set the cruise control for 80 mph and read off approximately 66 kias on the probe. We are at sea level and as you can see we were at approximately 64 degrees F or about 17.7 degrees C so conditions were close to standard. 80 mph means we should be reading 69.5 kias, which means our error is more or less acceptable for now. The data is not filtered, and the reading was estimated simply by changing the IAS scaling until the ball more or less filled the screen then reading off full scale, so there's lots of error there.

The following is the plot of Q (in Pascals) versus sample number. Our sample rate is approximately 20 Hz -- approximate because I'm still trying to figure out how to get timer interrupts to work on the Arduino.


Here is a 40-second expanded section:


And this shows a bit more clearly what is noise (due to turbulence -- the sensor by itself on the bench is very quiet to within +/- 1 Pascal) and what is speed variation as we navigate the busy Bay Area traffic.

As before, my expectation is that we need some digital filtering.

The probe survived the experience and, so far (knock on wood), with good anti-ESD practices and clean power-down and discharging of the electronics prior to making any changes to the circuit, the parts have survived. If this continues, I will be encouraged to commit more of my precious, expensive pressure sensors to testing. For now, I remain with one sensor in the "fancy Pitot tube" mode.

Thursday, December 7, 2017

Water manometer verification of sensor

I built up a new sensor board and, after a whole lot of pain with previous sensor damage, I am taking it slowly. I only installed one of the pressure sensors: the gage sensor for measuring dynamic pressure in the center hole of the probe.

To figure out whether the readings it's giving me are even remotely related to reality, I made a very simple water manometer and connected it to my sensor:


Meanwhile, I set up my PC with an XBee to receive the serial data:


I then applied a measured water column:


and 4.94 in. H2O should be 1229 Pa. My sensor board reports its data in SI units, so looking at the numbers coming off it:


the reported 1224 Pa is close enough for me. This was not an attempt to calibrate the sensor, or to determine its accuracy, but rather simply to figure out if I had a serious math error or mis-configuration somewhere. We are good to go now.

Next up, installing the sensor on the Toyota mast and getting some "flight" data. As I mentioned before I'm probably going to have to make a foray in to digital filtering. Expect more soon.

Sunday, November 19, 2017

New sensor board in the making

I'm trying to be far more careful now about how I build up and qualify my boards. I got 6 boards made from Osh Park and fully stuffed one of them yesterday. Today, I'm doing a step by step qualification to make sure everything works well.

I attached a Fio V3 to the board with a temporary header and rubber bands (someone should make Cleco fasteners for 0.1 inch headers!!) and used a Sparkfun TMP102 breakout board I had lying around as a generic I2C device to test the pressure sensor slots (so I don't risk my actual, expensive pressure sensors).

First, I learned that unless I de-populated the pullup resistors and decoupling cap on the TMP102 breakout, the bus did not work properly. I suspect it was the pullups that were overwhelming the bus, given that my board already has pullups.

With that fixed, I was able to verify that each of the pressure sensor slots were interrogated correctly by my bus scanner and that the TMP102 showed up where I expected it to.

Here is a picture of my test setup, followed by a picture of the signals as digital and analog traces on the scope. You can see how each of my 4 I2C buses is lit up in sequence by my bus scanner program.




Turbulence at the top of my mast

I installed a little tuft to estimate the amount of turbulence at the top of my mast:


As you can see, it is in view of my video camera. The result of a test run on the freeway is here (and note also impact with a tree branch ... happily no harm done).


Here are some things I noticed:

1. The piece of copper wire holding the tuft in place is a little bit wiggly, which could be exaggerating the movement of the tuft.

2. That said, even when there were few road bumps and the wire was staying put, the tuft was wiggling around quite a bit.

3. It seems difficult to estimate the frequency of the oscillations but I'm going to suspect it's just broad spectrum noise.

4. If this is any indication of what things look like on a crowded runway, I'll have to do some serious digital filtering to basically reject everything except the bandwidth of interest, which is probably no faster than 0.5 Hz or so.

With that in mind, then, the following is my plan of attack:

1. Build up and qualify a reliable new probe.

2. Test it with the 60 mW XBee modules, pushing the sampling rate as high as I possibly can while still getting reliable comms.

3. Thus oversampled, now add a simple lowpass filter on the display.

4. Give myself a TODO item to learn about Kalman filters and implement a more proper filtering strategy later.