A hardware GPS Simulator for HAB using Arduino with an optional LCD shield.
Arduino
Switch branches/tags
Nothing to show
Latest commit 250f86d Apr 26, 2012 Jim revised the last revision so that the ideal Sim speed is now 10hz. Ad…
…ded a really rough re-randomising to the bearing while moving through 2000 - 2100m
Permalink
Failed to load latest commit information.
LCD.ino
README.mediawiki
do_crc.ino
do_segment.ino
fscale.ino
habsim.ino revised the last revision so that the ideal Sim speed is now 10hz. Ad… Apr 26, 2012
output_NEMA.ino First Commit Apr 18, 2012
testButtons.ino
update_alt.ino
update_wind.ino
update_wind_walk.ino reformatted the debug output. changed the SIM_HZ rate to 20hz to bett… Apr 26, 2012

README.mediawiki

Table of Contents

What is GPSsim?

GPSsim is a project to create a drop in replacement for a physical GPS unit in a HAB payload. It's primary roll is to allow for Hardware-in-the-loop testing of payloads during the development and testing poccess. By replacing the flight hardware GPS module of your payload with a connection to GPSsim you can allow your payload to 'dream' that it's flying. While on the workbench (or freezer!) you can test any number of in flight logic processes, such as altitude (or GPS boundary) Cutdown triggers, Camera control, or telemetry testing.

How do I connect it?

The Arduino running the GPSsim firmware is connected to the payload's flight computer in the same way that physical GPS device connects. Connect the RX/TX ((usually) pins 0 and 1) on the GPSsim Arduino to the GPS input to your flight computer (so that the GPS TX pin is connected to the flight computer's GPS RX line, an the RX to TX). In addition to this you need to (probably should) connect the a ground line between the GPSsim Arduino to a ground line on your Flight computer, to ensure good RS232 TTL communication.

How do I get it going?

Just like a physical GPS unit, once powered up, GPSsim will start spewing forth NMEA sentences. Currently, the flight simulation also starts on power up, but this could be delayed.

Can I configure it to my needs?

Yes, there are lots of #define calls at the top of the code that can be edited to change parameters such as:

  • Lat/Lon/Alt/kPa of launch site
  • Targeted Ascent and Descent rate
  • Terminal Velocity of payload
  • GPS HZ
  • Burst kPa (Outside pressure at which balloon will burst)
Throughout the code there are also comments which point out variables that can also be changed to suit your needs, such as the Baud rate of the serial connection and the GPS "time"

How does the simulation work, and how accurate is it?

GPSsim, is not a fantastically accurate simulation of the dynamics of a balloon in flight, but it should be fit for purpose as it's described above. If you take the output of a GPSsim run and push it into Google Earth as raw NEMA sentences, it looks pretty similar to to paths of many of the balloon flight data tracks on the UKHAS wiki. There are few different processes going on in the code, and it's worth briefly discussing each one independently. (It has already been pointed out to me on IRC that the accuracy of simulation is severely compromised due to the absence algorithms during descent that describe the immense magnetic influence of Trees/Powerlines/North Sea/Heathrow/Girls???)

Vertical Simulation

The Vertical simulation (the balloon's ascent and descent) are possibly the most accurate elements of the whole simulation (although that's not saying much!). The maths for this is all contained with the update_alt() function. The specific part of this which is relatively accurate is the implementation of the International Standard Atmosphere Model which is used in this context to determine when the balloon will burst. Once burst, and descending the payload drops at it's terminal velocity while drag increases to slow it, again as a function of the pressure verses altitude (this time working on the parachute). The drag calculation is not at all accurate, but serves our purpose of realistically slowing the payload. Two other inaccuracies in the Vertical simulation are the instant acceleration to terminal velocity (minus drag) rather than an acceleration of (9.8m/s^2 - drag), and the rather rude clamping of the descent speed so that it can never fall below the targeted descent speed. Neither of these are believed to have a major impact on the usefulness of the simulation as implemented (and saved me a lot of time and headaches!)

Horizontal Simulation

The Horizontal simulation deals with the movement of the balloon due to the effects of wind. It is almost completely powered by nonsense and has very little baring on reality, other than producing and end result that looks slightly plausible. The function update_wind() takes in as it's parameters, the current Lat and Lon of the balloon, the direction the wind is blowing, and how far the wind has blown the balloon in this 'step' of the simulation. This is then fed into an implementation of the Vincenty Direct equation which updates CurLat and CurLon with the new co-ordinates after this step of the simulation. The direction the wind blows in based on a simple random walk algorithm, changing slightly throughout the flight. It is intended that the balloon will undergo a major change of direction and speed when it transitions the tropopause, but this isn't implemented yet.

NMEA output

The GPSsim outputs NMEA sentences on the serial port in an exact simulation (on of the more accurate parts of the simulation) of a real GPS unit running in NMEA mode. The main reason I can be confident of the accuracy of the simulation here, is that I didn't write it myself, it's a Arduino port of the existing GPSGen emulator (specifically the emulate.c file) on the UKHAS wiki. Full credit goes to the author (rocketboy?) of this code for a job well done. Currently the NMEA output renderer runs independently from the simulation, so that you can simulate a 1Hz GPS unit while the simulator ticks over at about 50Hz. However, due to a bug I've found in the Vincenty Direct equation, when presented with changing values for windspeed (or more specifically distance per simulator step) I may have to lockstep the simulator and NMEA renderer to the desired GPS output Hz.

LCD output

GPSsim supports and makes use of the common two line LCD shields that are common in Arduino world. I've developed it using this model, but there are many clones on ebay that are built to exactly the the same plan. They should all work. The LCD gives you output on the current Lat/Lon, altitude, outside pressure, and ascent/descent rate. It also has a glyph for the balloon state (Ascent/descent/landed) and an altitude graph. It's quite a busy little screen. The sheild also has buttons, and using the 'select' button you can toggle acceleration of the simulation by about x100.

I still don't get it, why is this useful, why use an Arduino?

I come from a background (i.e. my other hobby is...) UAV's (of the Ardupilot kind). In the UAV world we are taught at an early age that hardware-in-the-loop testing is the most important phase of development. By fooling the flight computer into thinking it's really flying (dreaming) you can discover and nail many bugs before they surprise you in the air. (Surprise situations in the UAV world (as in HAB), tend not to be recoverable). You can use a laptop/desktop PC/Mac to emulate the GPS and build your HIL testing rig, but when HAB flight times last at least a couple of hours, do you want to tie up your PC for that long? The Arduino is more than capable of performing this simulation anyway, it seems well suited. There may even be applications for this in the field as part of a flight readiness test, when a laptop isn't available, but having flown yet myself, I wouldn't know .. sigh..

Further Development

I offer this code out to the HAB community, please fork if you wish, or mail me to be added as a developer to the project if you are able to contribute directly. It's going to be a useful tool for me in the development of my HAB flight hardware, and if anyone else finds it at all useful then that's a win for us all. I'm happy to help support the use of this as far as my time allows, both in terms of advise on setting it up, and with code bugs/feature requests (just add them to GitHub)

You can mail me jim at jimblackhurst dot c o m, or catch me in the UKHAS irc channel as Jimthree or Jim3