[OpenRelief Developer] you may find some CanberraUAV code useful

[al Hart]

Good to see some more Aussies :)          
 
I gather you are talking about the UAV Challenge Outback Rescue, I have posted some info about this project on it recently http://www.facebook.com/groups/177617904551/   Alan
 

 

> From: tridge at samba.org
> To: developer at openrelief.org
> Date: Thu, 14 Jun 2012 13:38:08 +1000
> Subject: [OpenRelief Developer] you may find some CanberraUAV code useful
> 
> Hi All,
> 
> 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
> project!
> 
> I'm also the software lead for CanberraUAV, which is an entrant for this
> years outback challenge. I see you've already discussed the OBC
> challenge a bit on this dev list.
> 
> The CanberraUAV team is a bit unusual as we are an open team - all of
> the code and hardware specs for what we are doing are developed openly,
> precisely because we want other projects (such as OpenRelief) to be able
> to benefit from our work. We're using a bit bigger plane than you are (a
> 3m Mugin with 50cc petrol engine), but otherwise the basic ideas are
> somewhat similar.
> 
> The OBC challenge has less ambitious goals than what OpenRelief has, but
> we are perhaps a bit further along that you are at the moment, so I
> think some of the software components we have built may be useful to
> you. In particular:
> 
> - 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.
> 
> - we are also using some OpenCV components (via python interface),
> although the main image recognition code we have developed is in C,
> with some use of the Neon SIMD extensions. This was just because the
> pandaboard could not run the OpenCV recognition code fast enough for
> the realtime capture we need (we run at 7.5 fps) and the fact that
> the image recognition we need to do for the OBC is a bit unusual.
> 
> - 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)
> 
> - 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
> display)
> 
> - 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.
> 
> - we also have a 5.8GHz link to the ground, using Ubiquity bullet
> radios (specifically the 5-HP). We found considerable problems using
> TCP as the transport, so we developed an alternative transfer
> protocol that is more suitable to the sort of radio environment we
> have, and the demands of mixed image and meta-data transfer. This
> protocol runs on top of any datagram oriented transport, and doesn't
> require an IP transport underneath (we plan on using it over mixed
> MAVLink/UDP). The protocol is specifically design to handle high
> packet loss rates which you get on longer range non-fixed radio links
> 
> - 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
> 
> - for the OBC we've been aiming for about 8km range, but most of the
> stuff we've done is applicable to longer ranges as well.
> 
> 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).
> 
> I'd also like to apologise in advance for not offering to jump in and
> work on the OpenRelief code. I don't have the bandwidth right now to
> actually help with the OpenRelief code, but I just wanted you to be
> aware of what we're doing in CanberraUAV in the hope it may be useful.
> 
> Cheers, Tridge
> 
> Some links to give you pointers to some of the things I've mentioned:
> 
> https://github.com/tridge/MAVProxy
> https://github.com/tridge/cuav
> https://github.com/tridge/mavlink
> http://autotest.diydrones.com/
> https://github.com/tridge/cuav/blob/master/lib/block_xmit.py
> https://github.com/tridge/MAVProxy/blob/master/modules/lib/mp_slipmap.py
> https://github.com/tridge/MAVProxy/blob/master/modules/lib/mp_tile.py
> 
> _______________________________________________
> Developer mailing list
> Developer at openrelief.org
> http://openrelief.org/mailman/listinfo/developer_openrelief.org
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openrelief.org/pipermail/developer_openrelief.org/attachments/20120614/2209cbec/attachment.html>