My project launched a payload with GPS, camera, sensors and communications to an altitude of 30km. I obtained most parts ready years ago, but only recently had time to finish it.
High altitude ballooning is an emerging hobby, since price of GPS and communications equipment has gotten quite low.
It is an excellent hobby for people fascinated by space flight and telerobotics and has many learning aspects —
from systems design to electronics design to software engineering. There is also an exciting risk factor, namely, that you could lose your precious electronics if something malfunctions.
In this project, many of my interest and knowledge areas came together. Also, I have verified that the Earth is indeed round and that space is black.
— Alexei Karpenko
Mission at a glance:
|Launch Time||17:22:30 UTC (13:22:30 local)|
|Launch Point||43.951532,-81.554507 near Lucknow, Ontario, Canada|
|Landing Time||19:21:20 UTC (15:21:20 local)|
|Payload Mass||~1.5 kg|
|Balloon||KCI 1200 Totex Sounding Balloon|
|Balloon Lift||~4.2 kg Gross, ~3 kg Net; with payload resulting in Free Lift of >1.4 kg|
|Helium Volume||~4.06 m3|
|Flight Trajectory||halo2-pictures.kmz (with pictures), halo2-videos.kmz (with videos)|
|Highest Altitude||Over 30 km|
|Sensors||Temperature, Absolute Pressure|
|Camera||Canon PowerShot A510 with tilt servo (2048x1536 pictures, 320x240 videos)|
|Camera Shots||269 pictures, 58 videos (30 seconds each)|
|Battery||LiSO2, 5 cells in series resulting in 15V, operating time (8-16 hours)|
|Main Computer||Verdex ARM single-board computer, 600MHz, USB host|
|Communications||GM862-GPS cellular module with SiRF III GPS and Python interpreter, 900MHz XTend Modem|
|Parachute||48" Military Surplus Parachute, theoretical descend rate of about 20km/h|
The hardware consisted of a redundant communications and computer system with sensors, servo and camera.
The first communications system consisted of MaxStream XTend — a long-range 900MHz radio transceiver — connected to a Verdex 600MHz single-board ARM computer via serial port. The second communications system was a Telit GM862-GPS cellular module with built-in GPS and built-in python interpreter.
GM862-GPS module was a self-sufficient GPS tracker that would accept requests via SMS and send responses via SMS as well. It also monitored latitude and longitude and performed a payload cutdown when they went over the constraints. That was to prevent landing in a lake, since I am surrounded by them.
Verdex single-board computer controlled the camera, logged GPS positions and sensor data and communicated with the ground via the 900MHz radio modem.
An Atmel ATmega32 microcontroller was used to control two relays (cutdown and camera power), read temperature sensor via SPI, read pressure sensor via ADC and control camera tilt servo. It was connected to the Verdex via serial port. One pin was connected to GM862-GPS so that the module could request a cutdown.
Camera used was a Canon PowerShot A510. Flight 1 used USB to remotely capture pictures from the Verdex and save them on the USB key as well as scale them down for ground downlinking. Unfortunately this system was not very reliable and broke on that flight at an altitude of 6km. So for this flight (Flight 2), I decided to wire the Verdex directly to camera buttons (via GPIO pins) and use electrical signal to "press them." That also had an advantage because I could switch the camera to video mode. The disadvantage was that pictures could no longer be downlinked, since they were stored on a 4GB SD card inserted into the camera. As a fail-safe, camera was regularly restarted by cutting power via a relay.
GM862-GPS ran a python script that would accept SMS messages requesting GPS position and reply with position also using SMS. The script is based on nick84's code with bug fixes, modifications and additional commands. The commands that the script accepted were: request GPS position, cutdown the payload, cancel cutdown, restart GPS, restart module.
Unfortunately, the SiRF III GPS chip of GM862-GPS breaks at an altitude over 24km as noticed with Flight 1 which was nearly lost because of that bug. I tried to reflash SiRF III firmware before Flight 2 by soldering to the internal SiRF binary port (Port A) but was unsucessful (more on that later). So I just added automatic rebooting of the GPS module into the Python script when there has been no fix for over 10 minutes. Also, a couple of failure modes were detected — for example, 3D fix, but 0 satellites (this was the failure mode for Flight 1). Because of this code, the payload was not lost (but the GPS stopped working when the payload was above 24km).
The Verdex ran a few shell scripts as well as custom programs. One custom program (gpslog) would talk to gpsd and log GPS position to a file. Programs temperature and altitude would talk to the ATmega32 to return sensor status from the temperature sensor and the pressure sensor. The camera script controlled the taking of pictures and tilting of camera. It would also restart the camera periodically as a fail-safe.
Communication with Verdex took place via shell over the 900MHz radio modem. It was just a regular linux terminal.
The ground software consisted of a C# program running on a Laptop with Windows XP. It communicated with a cellphone via bluetooth to send and receive SMS to/from the payload. It also communicated with the ground 900Mhz modem. The retrieved position was shown on Google Earth via a program called GooPS. The ground software also connected to a bluetooth GPS receiver and forwarded the position to Google Earth via GooPS. That enabled to see positions of both the payload and the car in Google Earth. As a bonus, the software was also able to forward positions via WiFi to other chase cars so that they could follow the action.
Flight trajectory was predicted by the excellent University of Wyoming's Balloon Trajectory program. It grabs up-to-date wind data for different altitudes and is able to produce a predicted flight trajectory for Google Earth. From Flight 1 I already knew that it was pretty accurate.
Launch was very smooth, because our team was already experienced from the previous launches. We launched from a farm about 110km from home. That's because of the direction of jetstream — if we would have launched from home, it would have landed in a lake.
Flight time was just a bit over 2 hours and I didn't have contact with the capsule most of the time. I think I need to use a directional yagi antenna instead of the omni-directional high-gain antenna that I used. Cellphone connection was lost pretty early on, 900MHz radio worked to an altitude of 5km or so. After the capsule landed, I received an SMS with position and we went there and retrieved it. It was a farmer's field — we asked for permission to retrieve the capsule from his property.
When we got close to the capsule, we saw that it landed pretty hard. The parachute was very entangled with what remained of the burst balloon. It turns out that the Verdex became disconnected, but the GM862-GPS module worked fine. Later, I calculated impact speed to be over 60km/h. Luckily all hardware survived and works fine. This is because the padding was very good — thick layers of styrofoam were used in important places, components were hot-glued and separated with styrofoam and the comparatively heavy battery was at the bottom and strongly fixed.
Below is a video of the launch and retrieval.
This launch was very successful. Things to improve for next one: reflash SiRF III chip so that it works at an altitude over 24km, use yagi antenna instead of omni-directional antenna, improve parachute system.
Contrary to this flight, parachute worked well in Flight 1. Impact speed was 27km/h and a witness described the landing being smooth. But with this flight, Flight 2, the balloon didn't burst as cleanly as in Flight 1, so there was a higher chance for it to tangle. I think I just need to add a tensioner (i.e. a ring) underneath the parachute for the next flight to fix this problem.
Next flight should be in summer 2008. I plan to fix the radio systems so that uninterrupted contact is maintained.
— Alexei Karpenko
Q:Why only a 3 megapixel camera?
A:Megapixels are a myth. More than 3 megapixels do not make sense for a camera sensor of that size and would actually be worse because smaller area per pixel results in more noise and fewer color levels. Now with a DSLR, more is better. But for this project a 3 megapixel camera is perfect and much better than a >=5 megapixel one. It would have been nice to do hi-def video and a separate video camera might be an idea for the next launch.
Q:Why not make the parachute system unnecesarily complex?
A:This parachute system has been tested on Flight 1 and worked fine. The problem can be mitigated by a tensioner ring and by a longer distance between balloon and parachute.
Q:Isn't it a danger for manned aircraft?
A:Even though the chance of collision is very small, there was an aluminium foil inside the capsule for radar reflection. Control towers should have been able to track it. As for legality, as far as I can tell, it's permitted for that weight without requirements to notify any authority.
Q:Haven't this been done before?
A:Yes, like I said it's an emerging hobby which is great to see. I am very impressed by other launches some of which are more complex than mine. I have been following other people's progress and have still alot to learn. There are a couple of high altitude clubs and societies that you can join. Initially most launches were done by licensed radio amateurs, but now license-free solutions are readily available (at least in Canada/USA). I tried to do something unique, so a tilted camera taking both videos and pictures was used.
Q:How much did it cost?
A:The system that is presented is a little over-engineered for historical reasons as well as for future expansion and test purposes. It's possible to build a system for $500 with just a cellphone link and a microcontroller, but make sure that coverage is good where you intend to launch and use a good cellphone antenna.
Showing 465 comments.
Commenting has been disabled.
© 2007 Alexei Karpenko, Contact: alexei*karpenko.ca