Tag Archives: Arduino

Drone Sounding Prototype

Again we have a short project post in-between the posts of the open science series (part 3 coming soon)! This time I want to share a fun little project involving cheap drones and an instrument pack that I designed on top of the Light Blue Bean module. The pack uses an HTU21D temperature/humidity sensor and a BME180 pressure sensor. I designed the board in the open-source PCB/EDA tool KiCAD. Should you want to reproduce the boards, the files to send off to a board house are available on a GitHub repository here.

I designed the pack to be a measurement device for a home, truck, or airplane of the weather enthusiast or storm chaser. Ideally it will send the data to a smartphone/tablet that then sends it out to the web or lets you do whatever you want with it. It was also a good excuse to play with the bean after hearing about it. While delivering another product to a friend, we decided to strap this sensor to a small and cheap ($33) drone and see what happened. We got some vague data, but the drone didn't get over a few meters high due to the high load. Zip ties provided some protection on takeoff/landing.

Our initial test flight with some quick plots in the background.

Our initial test flight with some quick plots in the background.

After playing we though it would be fun to do this on a drone with some more power. I grabbed a $55 drone (Syma X5C) on eBay and gave it a shot. After a couple of test flights I just couldn't get the bluetooth link to stay connected at the distances I wanted (50m).

My breakout and the bean attached to the top of the drone body.

My breakout and the bean attached to the top of the drone body.

I added a kludge that wrote data to an SD card using the OpenLog. It was extra weight since I needed two more coin cell batteries, but the drone turned out to be able to carry it to 45 m once or twice. Then the drone looses signal and shakily falls out of the sky until I can get control again. While inspiring me to drool over more advanced drones, I did get some interesting data! Some of the plots are rather small in web-view, but click on them to expand. I just didn't want a bunch of individual figures making the post scroll forever.

2015-07-27 19.17.44

First I'll show my first SD logged flight(s). Below is the altitude plot (derived from the barometric pressure sensor on-board).

A few up/down flights of the drone. The ascent in the grey box will be examined in detail.

A few up/down flights of the drone. The ascent in the grey box will be examined in detail.

If we take the highest and most constant climb rate ascent (gray box) and look at the temperature/dewpoint data we see rather clean results!

flight1

It was a dead still evening, just before sundown. Without any mechanical mixing,  we see radiation from the ground producing a temperature inversion (temperature increases with height here). We also see a nice dew point trend to drier air as we ascend. For fun, I calculated the lapse rate. This just means how fast the temperature changes with height. Plotting the data and fitting a line we get about +11 degrees/kilometer of height. A reasonable number. (Perhaps coincidentally about the negative of the typical dry adiabatic lapse rate? It's been too long and I didn't ever do much near ground meteorology. Thoughts appreciated.)

lapse_rate

The next evening, a very similar setup without wind, I did another sounding that got up to 45 meters. On this flight I noticed that the bumps in the temperature and dew point trends match rather well with the bump in my ascent rate. Since this drone isn't programmable, I do this by hand which is tricky to judge. It probably has to do with the sensors needing a lot of settling time to equilibrate to their surroundings (a couple of seconds). Maybe flying small circles on the way up is a solution. I also have the video from this flight if you're curious what it looks like. Nothing too interesting, but the uncontrolled descents are rather exciting. I've read about hacking better antennas on this drone for more range, so that's a thought. Before I get it much further away I want to do it in a large field to decrease the risk from a runaway drone. If this proves to be interesting enough, maybe a drone update will be in order. They are pricey though!


Flight 2 data

Flight 2 data

Measuring the Speed of Sound

In the past on the "Don't Panic Geocast" we've talked about the speed of sound varying with temperature and how that can cause sound waves to bend. This phenomena, known as refraction, can result in all kinds of weird events, like being able to hear things from very far away when a thermal inversion is present in the atmosphere.

As I was researching some for that episode, I found that the standard formula for the speed of sound with temperature is a nice simple linear function over the ranges we care about. True, pressure and humidity can factor in there, but for simplicity, let's consider the largest factor... Temperature.

Formula for the speed of sound in dry air in m/s. Temperature is Celsius.

Formula for the speed of sound in dry air in m/s. Temperature is Celsius.

The formula above means that the speed of sound varies with temperature by 0.6 meters/second for every degree celsius of temperature change. That's about 2 ft/s for those of us more used to imperial units. A change that large should be pretty easy to see, right? This experiment and post were born from that statement.

To measure the speed of sound, I had several ideas. I could generate a short burst of noise and using an oscilloscope time how long it took to get to a microphone. That would require me to manually make the measurements, which probably means not a ton of data points since I'd have to either use the refrigerator to get a temperature difference or sit outside for a day. Neither of those were appealing. I ended up remembering some hardware that I had sitting around from the ultrasonic cave profiler.

The part of interest is the ultrasonic ranger. This little device (an SRF05) sends out a packet of ultrasonic pings and listens for their return. The device lets us know how long this takes by toggling an output from a digital 1 to digital 0. I already had the code to run this sensor, so I was half way there! The next thing I needed was a way to log the data. I didn't want to leave the door to the outside open to get power out there for the setup. I ended up using an SD card logger on top of the Arduino that was keeping track of the travel time.

Finally, we needed a target to range. Luckily, this was easy to do with some wood sticks, hot glue, and a plexiglass base plate. I glued the target to the base 260mm from where the pinger was mounted. After a couple of quick tests, I had verified that the setup was working! Adding a temperature and humidity sensor to the breadboard gave us everything we needed. Time to collect some data!

setup

Schematic of sound packets being transmitted and reflected. Really these are spherical wave-fronts, but the illustration is much cleaner this way!

Luckily, we've had pretty wide temperature swings during the day here in Pennsylvania lately. Using a decent sized 12V battery and voltage converter I could get days of run time on a single charge. To get the best data possible, I averaged many travel times per sample. This took less than a minute to do, which is fine since temperature isn't changing that rapidly.

The complete setup in a tub ready to collect data outside.

The complete setup in a tub ready to collect data outside.

Now that a simple apparatus was complete, I placed it in a Rubbermaid tub to keep any stray precipitation (or the rodents) from damaging things. The data was stored in a text file containing two-way travel time to/from the target in microseconds, device estimated distance to target, and the temperature/humidity readings. I collected several days worth of data, each time slightly improving my recording setup to get the cleanest data. I had problems with days where the temperature varied very fast and it appears to have introduced noise, some days there was direct sunlight (a rare thing in the PA winters) that caused very high temperatures and convection in the tub. Finally, on the last day of my experiment, I got a nice data set. It was a day with slowly varying temperatures and mostly cloudy. I trimmed the ends of the data so things were equilibrated and got some decent results!

Temp_RH

If we plot the temperature and the speed of sound against each other, we see what looks like a line! The steps are a result of being at the smallest increments in time that our system can sense. A better sensor could solve this, but for a rough estimate it turns out to be fine. Finding the best fit through this should tell us how well our measurements match the accepted formula. The slope of the line represents the rate of change of the speed with temperature (this should sound familiar to those calc. students out there), and the intercept represents the speed of sound at zero degrees.

Temp_Speed

 

We got the rate of change dead on! In fact we are within a few percent of the accepted value. The y-intercept is off by about 6 m/s, but I think that is a systematic offset due to a delay in the way the sensor is read. We could back that out, but maybe that is another topic for another time, or maybe we'll try this again with a different sensor. Please leave any comments or questions below!

Progress on Ultrasonic Mapper

My last post was on the idea, brainstorming, and basic setup of a ultrasonic mapper intended for cave passages.  This post is an update on the prototype that is running now and will hopefully be tested relatively soon when a bit more hardware mounting has been done.

Attached are several photos of the current state of the system, a simple plexiglass mount was constructed to attach the servo and sounder to an old tripod.  This mount will be stronger on a final version and detachable from the tripod.  This is just a proof of concept prototype.

Since servos only rotate 180 degrees the final model will use two sounders opposed to each other to collect a full 360 degree profile.  This means a similar connector (5-pin mic style) will be used with two units mounted in one case, or it may be possible to go with a more sophisticated sounder.  Keep in mind that the point of the whole project is to construct the profiler on a student shoestring budget.  

Below is an 'image' collected.  The vertical line on the right side is the back of an office chair and the feature on the left is the back and seat of a couch.  This was scanned rather slowly over about 40 seconds with many pings averaged out to reduce error.

Since I collected these images I have implemented an intelligent algorithm that makes a quick three ping assessment and based upon the results it will move to the next position or ping up to an additional fifty times to reduce the uncertainty.

The next step will be to make an intelligent scanning rate method that will scan with lower resolution over smooth surfaces and slow down over surface features.  Hopefully the whole scan can be a 15-30 second ordeal allowing quick mapping of passages.

Holiday Engineering Project - Beginning an Ultrasonic Mapper

Over the Thanksgiving break I decided to tackle a small engineering project that has been on my mind for the past month or so.  The basic idea was inspired by learning about Bill Stone's underwater cave mapping system (Stone Aerospace).   It is a relatively complex system constructed by more funding that a college student has at his/her disposal.  Being a caver myself I decided to build a much simpler and cheaper version for both above and below ground mapping.

Since this project is not too large it should be easily constructed over a few weekend hacking sessions, and over the last day the first steps have taken place. The machine uses and Arduino Uno as an interface between a computer and the real world.  While it is true that it would be possible to make a self-contained unit that would store data on a flash drive and maybe even display initial results on some simple display, I opted out of that option for cost and control concerns.  It should be simple to make a simple GUI that allows a netbook to control the setup very nicely and process the data real time.  
Above the basic layout from my notebook is shown.  The ultrasonic ranger (an SRF05) is attached to a rotating mount to sweep through the space around it.  In the initial prototype stages I'm using a simple RC servo since I have it on hand.  Servos only sweep close to 180 degrees to avoid bending control links on models.  While continuous rotation servos are made, they have no position feedback which does not allow accurate positioning of the servo.  It would be possible to use multiple rangers so 180 degrees is enough rotation, but it will be more economical to switch to a slow geared motor with an encoder (maybe a quadrature rotary encoder?) to detect the position as the unit slowly sweeps the space around it.  
Also pictured is the Arduino board and the range finder mounted in a custom case built this afternoon (the window added allows the ping LED to be seen inside the case to confirm the link).  Modification of the PCB and mounting hardware was required.  CAT5e cable along with 4-pin radio mic connectors are used for the power, ground, echo, and trigger pins.  The ranger has a built in PIC controller to pulse the output with a length of the echo time.  The unit seems to range effectively up to about 17 feet.  
While I don't know the accuracy at large distances, or the spread of the 'beam' with the increasing path length, some simple tests should help sort that out.  Currently I've written the interface on the Arduino in C, which will listen for commands over the USB connection.  It this executes those commands (such as move servo, get distance, etc) and returns the appropriate values if necessary.  The communication is asynchronous and not really 'handshaking', but using startbits there is some error checking involved.  
The control from the computer is in the form of a python script that takes easy user input and converts it to the short serial commands in the home-made quick transfer format in the Arduino C code.  Currently it moves the servo and returns distances in cm.  At distances less than 30 cm results seem to be accurate to about 2-5mm.  

The next steps include mounting everything up to get 180 degree scans produced, assessing the accuracy and noise limits of the unit.  I also plan to implement a scanning algorithm that scans more quickly over plan surfaces and slows down over more interesting surfaces.  It will also throw out false returns, which could be due to a range folding issue in large spaces (I have not done anything past back of the envelope on if the signal is strong enough to cause a range folding issue).  A leveling mechanism (manual or automatic) would be nice for field applications.  If this were to be used in mapping a tunnel some kind of simple inertial navigation system with a combination of gyros and accelerometers could be used.  These are all for future development and future posts.  
Have a happy and safe Thanksgiving!