kopia lustrzana https://github.com/projecthorus/chasemapper
Updated readme.
Mark Jessop
rodzic
5f611d7750
commit
73e75421eb
56
README.md
56
README.md
|
|
@ -1,10 +1,23 @@
|
|||
# Project Horus - Browser-Based HAB Chase Map
|
||||
|
||||
This folder contains code to display payload (and chase car!) position data in a web browser:
|
||||
Chasemapper is a mapping system designed specifically for chasing high-altitude weather balloons, be it those you might launch yourself, or those launched by your local weather bureau. It is Project Horus's cross-platform replacement for [oziplotter](https://github.com/projecthorus/oziplotter), which was our original offline mapping system, used during many high-altitude balloon flights from 2010 through 2019.
|
||||
|
||||
|
||||
|
||||
The general idea is this application is run on a 'headless' machine like a Raspberry Pi (could be the same one that's running [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx)?) and is accessed from a tablet or laptop computer via a web browser.
|
||||
The primary purpose of chasemapper is to provide an easy-to-use mapping interface to help you as close as possible to the landing location of a high-altitude balloon, ideally before the balloon gets there! It does this by providing live predictions of the balloon flight path during the flight, calculated from GFS weather models which are downloaded before you head off on the chase. Maps can also be served up from a local cache, allowing use of the map without internet connectivity.
|
||||
|
||||
Chasemapper is intended to be run on a 'headless' machine like a Raspberry Pi and is accessed from a tablet or laptop computer via a web browser. Multiple clients can connect to the server to see what's going on, which is a nice way of keeping passengers entertained ;-)
|
||||
|
||||
It will quite happily run alongside other Project Horus applications such as [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx).
|
||||
|
||||
### Contacts
|
||||
* [Mark Jessop](https://github.com/darksidelemm) - vk5qi@rfhead.net
|
||||
|
||||
You can often find me in the #highaltitude IRC Channel on [Freenode](https://webchat.freenode.net/).
|
||||
|
||||
### Help Wanted!
|
||||
Currently Chasemapper is a bit mandrolic to set up, and this could be improved considerably, perhaps through the use of a docker container or similar. This isn't my area of expertise, so any assistance with this would be much appreciated!
|
||||
|
||||
## Dependencies
|
||||
|
||||
On a Raspbian/Ubuntu/Debian system, you can get most of the required dependencies using:
|
||||
```
|
||||
|
|
@ -24,11 +37,13 @@ $ git clone https://github.com/projecthorus/chasemapper.git
|
|||
|
||||
## Telemetry Sources
|
||||
To use the map, you need some kind of data to plot on it! The mapping backend accepts telemetry data in a few formats:
|
||||
* 'Payload Summary' and 'Chase Car Position' messages, via UDP broadcast in a JSON format [described here](https://github.com/projecthorus/horus_utils/wiki/5.-UDP-Broadcast-Messages#payload-summary-payload_summary). These can be generated by:
|
||||
* 'Payload Summary', 'Chase Car Position' and 'Bearing' messages, via UDP broadcast in a JSON format [described here](https://github.com/projecthorus/horus_utils/wiki/5.-UDP-Broadcast-Messages#payload-summary-payload_summary). The standard ports used for these are 55672 (for hobbyist HAB payloads) and 55673 (radiosondes). These can be generated by:
|
||||
* [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx/wiki) - See [here](https://github.com/projecthorus/radiosonde_auto_rx/wiki/Configuration-Settings#payload-summary-output) for configuration info.
|
||||
* Various 'bridge' utilities within the [horus_utils](https://github.com/projecthorus/horus_utils/wiki) repository. For example, [FldigiBridge](https://github.com/projecthorus/horus_utils/wiki#fldigibridge-processing-of-data-from-dl-fldigi) or [HabitatBridge](https://github.com/projecthorus/horus_utils/wiki#habitat-bridge)
|
||||
* The [horusbinary](https://github.com/projecthorus/horusbinary) 4FSK telemetry decoder will emit these messages on port 55672 by default.
|
||||
* My [Kerberos-SDR fork](https://github.com/darksidelemm/kerberossdr) will emit TDOA bearing information in the appropriate UDP message format on port 55672. Note that the bearing functionality is very much experimental at this time.
|
||||
* 'OziMux' messages, via UDP broadcast in a simple CSV format [described here](https://github.com/projecthorus/oziplotter/wiki/3---Data-Sources#3---oziplotter-data-inputs).
|
||||
* [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx/wiki) - See [here](https://github.com/projecthorus/radiosonde_auto_rx/wiki/Configuration-Settings#sending-payload-data-to-chasemapper--oziplotter--ozimux) for configuration info.
|
||||
* [radiosonde_auto_rx](https://github.com/projecthorus/radiosonde_auto_rx/wiki) - See [here](https://github.com/projecthorus/radiosonde_auto_rx/wiki/Configuration-Settings#sending-payload-data-to-chasemapper--oziplotter--ozimux) for configuration info, though I suggest using the 'Payload Summary' message as described above as it provides callsign information.
|
||||
* Pi-in-the-Sky's [lora_gateway](https://github.com/PiInTheSky/lora-gateway) - Using the `OziPort=8942` configuration option.
|
||||
|
||||
|
||||
|
|
@ -66,13 +81,11 @@ You will then need to modify the horusmapper.cfg Predictor section setting as ne
|
|||
|
||||
You can then click 'Download Model' in the web interface's setting tab to trigger a download of the latest GFS model data. Predictions will start automatically once a valid model is available.
|
||||
|
||||
|
||||
## Chase Car Positions
|
||||
At the moment Chasemapper supports receiving chase-car positions via either GPSD, a Serial-attached GPS, or Horus UDP messages. Refer to the configuration file for setup information for these options.
|
||||
|
||||
This application can also plot your position onto the tracker.habhub.org map, so others can see when you're out balloon chasing. You can also fetch positions of nearby chase cars from Habitat, to see if others are out chasing as well :-) These options can be enabled from the control pane on the left of the web interface, and can also be set within the configuration file.
|
||||
|
||||
|
||||
## Offline Mapping via FoxtrotGPS's Tile Cache
|
||||
(This is a work in progress, but is functional.)
|
||||
Chasemapper can serve up map tiles from a specified directory to the web client. Of course, for this to be useful, we need map tiles to server! [FoxtrotGPS](https://www.foxtrotgps.org/) can help us with this, as it caches map tiles to `~/Maps/`, with one subdirectory per map layer (i.e. `~/Maps/OSM/`, `~/Maps/opencyclemap/`).
|
||||
|
|
@ -137,7 +150,30 @@ To stop the service, simply run:
|
|||
$ sudo systemctl stop chasemapper.service
|
||||
```
|
||||
|
||||
## Contacts
|
||||
* [Mark Jessop](https://github.com/darksidelemm) - vk5qi@rfhead.net
|
||||
## Radio Direction Finding Support
|
||||
As of August 2019, Chasemapper can also plot bearings from radio-direction-finding devices. Bearing information is accepted in the 'horus_udp' format (essentially, JSON over UDP broadcast), and can be provided as either 'relative' (bearing relative to front-of-car, with no source position information), or 'absolute' (bearing relative to true north, with a source lat/lon). Relative bearings will be fused with the instantaneous car heading, which is currently calculated from speed-gated GPS headings.
|
||||
|
||||
You can often find me in the #highaltitude IRC Channel on [Freenode](https://webchat.freenode.net/).
|
||||
The following formats are currently supported:
|
||||
```
|
||||
# Absolute bearings - lat/lon and true bearing provided
|
||||
{'type': 'BEARING', 'bearing_type': 'absolute', 'latitude': latitude, 'longitude': longitude, 'bearing': bearing}
|
||||
|
||||
# Relative bearings - only relative bearing is provided.
|
||||
{'type': 'BEARING', 'bearing_type': 'relative', 'bearing': bearing}
|
||||
|
||||
The following optional fields can be provided:
|
||||
'source': An identifier for the source of the bearings, i.e. 'kerberos-sdr', 'yagi-1'
|
||||
'timestamp': A timestamp of the bearing provided by the source.
|
||||
'confidence': A confidence value for the bearing, from 0 to [MAX VALUE ??]
|
||||
'power': A reading of signal power
|
||||
'raw_bearing_angles': A list of angles, associated with...
|
||||
'raw_doa': A list of TDOA result values, for each of the provided angles.
|
||||
```
|
||||
|
||||
Bearings are plotted on the map as thin lines, which slowly become transparent as they get older, and then disappear. The style of the line and the maximum age bearings shown can be configured in the new bearing settings tab on the left of the screen (click the compass icon). You can also filter bearings by the optionally supplied confidence level ('Confidence Threshold'). Bearings provided while the chase-car is stationary (i.e. when the heading is essentially unknown) are filtered out of the display by default, but can be enabled if desired ('Show stationary bearings'). Most of the filter settings will only take effect by clicking the 'Redraw Bearings' button.
|
||||
|
||||
My [Kerberos-SDR fork](https://github.com/darksidelemm/kerberossdr) will emit relative bearings in the above format, including the raw TDOA data, which is plotted on a polar plot on the bottom-right of the display. Bearing data will be emitted as soon as TDOA processing is started. Note that I have only tested with data from a Uniform Circular Array and do not currently handle forward/reverse ambiguities from a linear array configuration. I would *not* suggest running Chasemapper on the same device as the Kerberos-SDR software, due to the high processor load of the Kerberos algorithms.
|
||||
|
||||
Note that the bearing display (in particular the TDOA data polar plot) does put a fairly big strain on some slower devices. Currently the polar plot is generated in a fairly naive way, and definitely has room for improvement.
|
||||
|
||||
I make no promises as to the usefulness and/or performance of this feature in chasemapper - it's essentially a re-implementation of a radio-direction finding mapping system developed by fellow Amateur Radio Experimenters Group members a very long time ago, and has yet to be used 'in anger'. It's also important to note that attempting to direction-find radiosonde/high-altitude balloon payloads which are located at high relative elevations (>40 degrees or so) is likely to lead to very inaccurate results due to coning angle limitations (where a bearing cannot be resolved due to insufficient phase-delta between receive antennae).
|
||||
|
|
@ -132,6 +132,9 @@ class Bearings(object):
|
|||
'source': An identifier for the source of the bearings, i.e. 'kerberossdr', 'yagi-1'
|
||||
'timestamp': A timestamp of the bearing provided by the source.
|
||||
'confidence': A confidence value for the bearing, from 0 to [MAX VALUE ??]
|
||||
'power': A reading of signal power
|
||||
'raw_bearing_angles': A list of angles, associated with...
|
||||
'raw_doa': A list of TDOA result values, for each of the provided angles.
|
||||
|
||||
"""
|
||||
|
||||
|
|
|
|||
|
|
@ -132,18 +132,21 @@ def playback_json(filename, udp_port=55672, speed=1.0):
|
|||
|
||||
if _log_data['log_type'] == 'CAR POSITION':
|
||||
send_car_position(_log_data, udp_port)
|
||||
print("%02d:%.2f - CAR POSITION" % (_time_min, _time_sec))
|
||||
print("%02d:%.2f - Car Position" % (_time_min, _time_sec))
|
||||
|
||||
|
||||
elif _log_data['log_type'] == 'BEARING':
|
||||
send_bearing(_log_data, udp_port)
|
||||
print("%02d:%.2f - BEARING" % (_time_min, _time_sec))
|
||||
print("%02d:%.2f - Bearing Data" % (_time_min, _time_sec))
|
||||
|
||||
elif _log_data['log_type'] == 'BALLOON TELEMETRY':
|
||||
print("%02d:%.2f - BALLOON TELEMETRY" % (_time_min, _time_sec))
|
||||
print("%02d:%.2f - Balloon Telemetry (%s)" % (_time_min, _time_sec, _log_data['callsign']))
|
||||
|
||||
elif _log_data['log_type'] == 'PREDICTION':
|
||||
print("%02d:%.2f - Prediction (Not re-played)" % (_time_min, _time_sec))
|
||||
|
||||
else:
|
||||
print("%02d:%.2f - UNKNOWN" % (_time_min, _time_sec))
|
||||
print("%02d:%.2f - Unknown: %s" % (_time_min, _time_sec, _log_data['log_type']))
|
||||
|
||||
except Exception as e:
|
||||
print("Invalid log entry: %s" % str(e))
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue