[OpenRelief Developer] you may find some CanberraUAV code useful
shane at openrelief.org
Fri Jun 15 07:01:56 BST 2012
Shane here. I'm the chap who got irritated last year trying to wander around the Tohoku disaster zone with a GPS phone, ad hoc mapping where the people who needed help from our Western Japan NGO logistics train were located.
On Jun 14, 2012, at 12:38 PM, Andrew Tridgell wrote:
> The lwn.net article today introduced me to OpenRelief, and I thought I
> should make contact given the amount of overlap between one of my own
> projects and yours.
> I'm the lead developer of ArduPlane which I believe you are using in
> OpenRelief. I was delighted to read that you'd chosen ArduPlane for your
> I'm also the software lead for CanberraUAV, which is an entrant for this
> years outback challenge.
It's quite literally an honor to have you drop by, and I want to personally thank you for providing so much information in your postings. It's clear that your project(s) are quite a way ahead of us, and we can both learn a lot and aim for maximum compatibility.
> - we are also ARM/Linux based, specifically using a pandaboard on the
> plane, coupled to the APM. So our work is directly applicable to the
> Raspberry PI you are using. (we're running Ubuntu Precise, but that
> doesn't really matter).
> - we've got some kernel patches to avoid some issues with linking to an
> APM over USB in flight (specifically being able to suppress DTR
> reset). If you haven't come across that issue yet then please ask, or
> it will cost you a plane at some stage.
This is an area where we can hopefully stand on your shoulders to reduce development and testing. Paul Gardner is our autopilot guy, and hopefully he can look into those kernel patches (etc) for us. I'm assuming we will find this code under https://github.com/tridge/cuav
> - in collaboration with another OBC team in Brisbane we have developed
> a new radio that specifically suits the needs of longer range
> telemetry and small image transfer (see
> http://rfdesign.com.au/index.php/rfd900). The firmware for the radio
> is open source (see https://github.com/tridge/SiK)
Other posters mentioned this, but a real headache is that we have different regulations around the world. I suspect Andrew is right, and we will end up having to support several radios on a regional basis.
> - we've developed pymavlink, a python implemention of the MAVLink
> protocol that APM talks. This makes it easy to write high level
> scripts to interact with APM, plus forms the basis for things like
> the geo-referecing of the image data
> - as part of pymavlink we've developed a suite of telemetry log analysis
> tools that you will probably find useful (eg. mavgraph)
> - we've developed UI modules for the display of geographic data on top
> of satellite imagery from any of the major satellite tile services,
> allowing us (for example) to overlay geo-referenced image data from
> the plane in real time onto a "google maps" like interface (actually
> a python script). Using this we can display meta-data from the
> geo-referencing and image recognition (image recognition happens on
> board the plane, and the python code in the plane then sends
> compressed and annotated image data to the ground station for
> - we've developed a command line GCS (MAVProxy) that is designed to run
> on the plane, but also talks to ground station modules on the ground.
These are all very useful indeed. Obviously we want to minimize our time to code and deploy. In short, we are going to review your code, and aim to use as much as possible. Our policy is upstreaming all the way, so anything we learn, we will send right back to you.
Right now we are looking at ArduPilot Mission Planner as the basis of our first GCS. The plan is to extend it to handle multiple drones and allow it to be utilized by RESTful API. It will be called by a little OpenRelief application and web server which distributes data/interacts with parties around the place.
If I understand you correctly, we can use your code on the plane to talk to the ground GCS, thus filling in a blank we had ("how does the drone computer talk to the autopilot most effectively?"). Depending on the extent of your code and UI modules, it may even replace Mission Planner in our development, though from the above it seems most of your code is primarily suitable for making the drone itself smarter, and may initially work best for us in that context, delivering data to the ground Mission Planner instance. Do correct me if I am wrong :)
> - we've developed a simulation environment where we can playback
> synchronised image and telemetry data from real flights, allowing us
> to fine tune the GCS UI and plane interactions based on existing data
That's excellent. We understand that the DIYDRONES community most often uses FlightGear (hence we intended to do the same), but I guess you had some reasons for taking another route? Glad to learn why.
> As you might guess, our code is idiosyncratic, so some introduction to
> its capabilities and how you may be able to make use of it could be
> needed. I could perhaps give a demo to someone on the OpenRelief dev
> team at some stage (maybe via a VNC server if that helps).
An introduction to your code is a fantastic offer. You apologized for not jumping in to help us, but your mail alone provided a shortcut of weeks. Thank you Tridge. As soon as our drone management and comms people have our ducks more in a row, I would really like to take you up on that demo.
More information about the Developer