Above: Is a flying Riffle a Fliffle?
It might look like somebody strapped things on to a KAP rig in a haphazard fashion (Figure 1), but if you held that Saturn V Rig by one finger at the base of the Picavet shaft, the entire rig would balance perfectly upright. Nonetheless I had to fly it three times to get much out of it. The first time was a disappointment because when I flipped the power switch for the SkyShield autoKAP controller during the hectic launch a Velcro strap pushed the Riffle power switch to the GEN position. So the Fled kite lofted the Riffle on its maiden one-hour flight with 1000 feet of line out but the Riffle was turned off.
Figure 1. A Riffle and its battery strapped to a Saturn V Rig to go where no Riffle has gone before.
The next day a second flight under a PFK Nighthawk kite lasted five minutes because there was not as much wind as I thought there was. I switched to a Levitation Delta kite and let out 1000 feet of line over the Breadloaf Campus in Ripton, VT (Figure 2). The Riffle was logging data from two sensors about every five seconds and the PowerShot S100 was taking photos with GPS data about every four seconds.
Figure 2. The Riffle-laden Saturn V Rig follows the Levitation Delta skyward.
I did not change the three eneloop batteries powering the SkyShield after the first flight because tests with the switching regulator suggested that the servos would be happy for more than four hours of operation. They were not happy after about ten minutes into the flight, so only a few complete cycles of 25 photos covering the half sphere were captured. The camera continued to shoot every four seconds and thereby record GPS data in each of the photos, which were otherwise useless pictures of blue sky.
Figure 3. Very few of the 720 photos taken were of much photographic value, but 14 of them were stitched into this panorama.
The sensors sending data to the Riffle were a DHT22 humidity and temperature sensor and a BMP180 barometric pressure and temperature sensor. These each cost $3.00 on ebay (including shipping from China). To get the GPS data out of the photos and into Excel, I used ExifTool as described here, and then deleted every ninth GPS entry so I had 642 entries each of GPS data and sensor data with timestamps which matched up with varying precision. The GPS data include altitude as well as latitude and longitude.
Figure 4. Altitude of the camera from its GPS during the 50 minute flight and the temperature data from the DHT22 sensor.
The GPS data suggest that at the camera’s apogee it was 185 m (620 feet) higher than its launch point (Figures 4 and 5). The DHT22 sensor data suggests that it was 5°C (9°F) cooler (Figure 4) and a few percent more humid up there (Figure 5). The temperature decline with altitude is similar to that predicted by the adiabatic lapse rate, except for the part of the flight within about 40 m (130 feet) of the ground (Figure 6).
Figure 5. Altitude from the camera GPS and humidity from the DHT22 sensor.
Figure 6. The relationship between altitude (from the camera GPS) and temperature from the DHT22 sensor.
The BMP180 data are not as tidy as the DHT22 data and have lots of apparently erroneous low readings for both pressure and temperature. Comparing the temperatures from the BMP180 and DHT22 sensors (Figure 7) suggests that the erroneous readings are all low, and that only the highest readings from the BMP180 should be considered.
Figure 7. Temperature data from three sensors. The real time clock (RTC) on the Riffle was reading higher than the two external sensors. The DHT22 sensor tracked the maximum readings of the very noisy BMP180 sensor.
The BMP180 pressure data suggest that the pressure change during the flight (Figure 8) was about 20 millibars (0.6 inches of mercury), but it’s hard to know whether the running max is a reliable way to interpret the data.
Figure 8. Atmospheric pressure data from the BMP180 sensor (points) and the six point running maximum values (line).
A six-point running maximum pressure crudely converted to altitude resembles the altitude from the camera’s GPS sensor (Figure 9), but was not corrected for current conditions. The GPS altitude trace seems to lag the pressure altitude trace by about 1.5 minutes early on and then track better later. [UPDATE: I manually matched time stamps between the camera GPS data and Riffle sensor data and improved the temporal alignment. Figure 9 now displays very good synchrony between GPS altitude and altitude computed from barometric pressure.]
Figure 9. Altitude from the camera GPS compared to the running max of altitude computed from barometric pressure (and not corrected or calibrated) from the BMP180 sensor.
The scattered, erroneous readings from the BMP180 sensor probably did not result from power fluctuations because the DHT22 was using the same power pins, but it could have been an intermittent connection somewhere. Or this noise could be a characteristic of the $3.00 sensor. More tests are called for.
The video above is an animation of the flight track of the KAP rig with temperature data displayed with colors.
I used Google Earth to display the flight track of the payload with temperature data from the DHT22 sensor displayed as color along the track (video above). I have not yet figured out how to display more detail of the sensor data, so only one degree C increments are represented. I converted a csv file of GPS coordinates into a KML file, and made separate files (with different colored lines) for each part of the track where temperature was within one degree. If anyone knows how to use KML to display more detail please let me know.
Figure 10. Of the 720 photos taken there was one set of 24 photos that stitched into a half spherical panorama. This is the stereographic projection of that panorama.
4 Comments
Chris,
This is such a beautiful project! The lapse rate calculation is so fun to see.
Quick reactions:
That power switch goof is annoying. I wonder if it would be useful to run everything off a single power supply, with only one switch to worry about ...
Nice to see that the altitude trends lined up nicely in Fig 9 after the manual correction. Craig and I spent some time coming up with code for matching up timestamps in GPS and sensor data a while back -- might be fun to pull out the Jupyter notebook we'd written and see if it can be applied to your data.
The BMP180 data is disappointing -- but great job extracting everything you could from it. One thought: the RTC temperature sensor is encased in plastic; and the DHT22 is inside a plastic cage; but the BMP180 sensor has only that tiny inlet on the top of the chip. I wonder if the BMP180's wild fluctuations in temperature have to do with the way that air is passing over the chip in higher winds at altitude? Perhaps whenever the sensor gets a blast of wind directly into the inlet, it reads an erroneously low temperature? Increased sudden air flow into the sensor could maybe 'cool off' the sensor, consistent with the pattern you're seeing. [I'm sort of making this up ... but sounds plausible, don't it?] Does the sensor show the same variability in temperature when it's just sitting on a table inside? If not, then maybe the temperature readings could be improved even by e.g. loosely wrapping some tape around the sensor to protect it from direct wind during flight. The pressure readings on the device are temperature-compensated via some algorithm on the chip, so finding a way to prevent the temperature goof-ups could also make for better pressure measurements.
The video is incredible. I'd love to learn the process you use to make it.
Is this a question? Click here to post it to the Questions page.
Reply to this comment...
Log in to comment
Reply to this comment...
Log in to comment
Dear @cfastie! How are you? Joaquin from Aerocene project here. One of our community members, Fede from Buenos Aires, has created a Python code that allows to assign color to a KML flight trajectory according to another variable, such as tempreature, height or pollution. The code is freely available on our github: https://github.com/Aerocene/skyholemarkup
Is this a question? Click here to post it to the Questions page.
That's a great development. Thanks for alerting me to that. The key to this advance is knowing how to structure the KML code to define the color of each individual segment of a line. I had always defined a line in KML as below which colors the entire line the same color:
<Style> <LineStyle> <color>ffff00ff</color> <width>3</width> </LineStyle> </Style> <Placemark> <MultiGeometry> <LineString> <coordinates> -72.994171,43.951747,437.6 -72.994163,43.951751,438.7 -72.994148,43.951751,438.2 -72.994148,43.951747,438.1 -72.99414,43.951744,438.8 -72.99414,43.951744,437.9 -72.994163,43.951744,437.2 </coordinates> </LineString> </MultiGeometry> </Placemark>
Now I know that the structure below will define the color for only the single line segment described by the
<coordinates>
tag:<Placemark> <Style> <LineStyle> <color>ff472f7d</color> <width>4</width> </LineStyle> </Style> <LineString> <coordinates> -0.562935,51.423039,47.530000 -0.562931,51.423023,47.530000 </coordinates> </LineString> </Placemark>
I am still not sure how to use the Python code to create a KML file like this, but I will work on that.
Thanks,
Chris
Reply to this comment...
Log in to comment
Login to comment.