[Canberrauav] hello!
tridge at samba.org tridge at samba.org
Sat Jan 15 22:38:31 EST 2011
Hi All,
I met some of you (Andrew, Jack and Combust) at the MHV space today.
I thought I'd introduce myself and let you know what my interest is in
the UAV project.
I'm a developer on the Samba project (see http://samba.org), plus
occasional lecturer in CS at ANU. IBM pays me to support my Samba
habit. I've been hacking on free software for about 20 years or so
(see http://samba.org/tridge and http://blog.tridgell.net for
projects).
I know almost nothing about RC planes, although I'm keen to learn. My
only attempts to fly RC planes so far have ended up with the planes in
several pieces scattered over the ground :-)
I like the sound of the outback UAV project, and perhaps I can help a
bit on the software side of things.
After our discussions today, I did a bit of googling and came up with
a few things that may be interesting. My apologies if this is all
basic stuff you've already covered.
The first is a video shot from a UAV with a 10x zoom camera:
http://www.fpvflying.com/products/10-x-zoom-UAV-%7B47%7D-FPV-camera.html
if you pause the video you can see that it is easily making out
objects of the sort of size we are after (one lost dummy in the
outback) at distances of 600-700m or so when using the full zoom. That
gives us a base line for the sort of resolution we can look for in a
moderately priced UAV camera (that camera is US$300).
The second thing I came across is this arduino based autopilot
project:
http://diydrones.com/notes/ArduPilot
it would be very interesting to think about using an autopilot for
this project I think. It doesn't look very expensive (looks like a
complete autopilot setup will be around $300 or so) and it would make
it much easier for us to reliably run a well defined search pattern.
The autopilot software is all open source, allowing us to modify it to
suit.
Cheers, Tridge
[Canberrauav] ardupilot + flightgear
tridge at samba.org tridge at samba.org
Mon Jan 17 09:57:19 EST 2011
Hi All,
In an attempt to learn a bit more about autopilots and flying planes
I've been experimenting with autopilot control of the flightgear
flight simulator. I started with this:
http://diydrones.com/profiles/blogs/closed-loop-autopilot-1
and modified the autopilot code a bit to allow it to be
enabled/disabled in-flight, to set a target altitude and make it work
with flightgear 2.0.
It is working quite well on my Ubuntu Linux system using a "Rascal
110" model (a RC plane model available for flightgear), and it
confirms the fact that I'm a hopeless pilot. Soon after I disengage
the autopilot the plane is usually out of control fairly quickly, but
when I re-engage the autopilot it quickly recovers.
I was surprised to find how simple the core autopilot code is. This is
the key code:
/* Proportional control for roll and pitch */
aileron_ctrl = -0.05*(fdm.roll - 0);
pitch_ctrl = 0.1*(fdm.pitch - 2);
the rest of the autopilot is just code to let it talk to flightgear
(over a pair of UDP sockets), so it can get instrument data from the
simulator and write aileron and pitch control values back to the
simulator. It recovers amazingly well even if I put the model into a
nasty dive or spin before I engage the autopilot.
The next step I thought I'd try is to replace the simple autopilot
code with ardupilot. That would allow us to build a full simulator for
the project, which would allow us to experiment with various autopilot
mods more easily. Quite a few other people have done this
successfully, eg:
http://diydrones.com/profiles/blogs/the-ardupilot-fg-control-for
So I've ordered a ardupilot-mega and a IMU board from diydrones. Once
they arrive I'll try to set them up to control flightgear.
It might also be useful to build a flightgear model of whatever plane
the project ends up using.
Cheers, Tridge
[Canberrauav] hello!
Dave Woodgate dpwoodgate at gmail.com
Mon Jan 17 19:37:23 EST 2011
On 15/01/2011 10:38 PM, tridge at samba.org wrote:
> Hi All,
>
> I met some of you (Andrew, Jack and Combust) at the MHV space today.
>
> I thought I'd introduce myself and let you know what my interest is in
> the UAV project.
>
> I'm a developer on the Samba project (see http://samba.org), plus
> occasional lecturer in CS at ANU. IBM pays me to support my Samba
> habit. I've been hacking on free software for about 20 years or so
> (see http://samba.org/tridge and http://blog.tridgell.net for
> projects).
>
> I know almost nothing about RC planes, although I'm keen to learn. My
> only attempts to fly RC planes so far have ended up with the planes in
> several pieces scattered over the ground :-)
>
> I like the sound of the outback UAV project, and perhaps I can help a
> bit on the software side of things.
>
> After our discussions today, I did a bit of googling and came up with
> a few things that may be interesting. My apologies if this is all
> basic stuff you've already covered.
>
> The first is a video shot from a UAV with a 10x zoom camera:
>
> http://www.fpvflying.com/products/10-x-zoom-UAV-%7B47%7D-FPV-camera.html
>
> if you pause the video you can see that it is easily making out
> objects of the sort of size we are after (one lost dummy in the
> outback) at distances of 600-700m or so when using the full zoom. That
> gives us a base line for the sort of resolution we can look for in a
> moderately priced UAV camera (that camera is US$300).
Looks good. I'm not sure how we are going to handle fiddling around with
zooming in and out of different places quickly looking for joe though.
> The second thing I came across is this arduino based autopilot
> project:
>
> http://diydrones.com/notes/ArduPilot
>
> it would be very interesting to think about using an autopilot for
> this project I think. It doesn't look very expensive (looks like a
> complete autopilot setup will be around $300 or so) and it would make
> it much easier for us to reliably run a well defined search pattern.
> The autopilot software is all open source, allowing us to modify it to
> suit.
Yes, Jack has been playing with the ardupilot that he bought.
> Cheers, Tridge
> _______________________________________________
> Canberrauav mailing list
> Canberrauav at canberrauav.com
> http://www.canberrauav.com/mailman/listinfo/canberrauav
>
[Canberrauav] hello!
tridge at samba.org tridge at samba.org
Mon Jan 17 23:13:03 EST 2011
Hi Dave,
> Looks good. I'm not sure how we are going to handle fiddling around with
> zooming in and out of different places quickly looking for joe though.
I think it would be harder without a zoom, unless the IR beacon is
very bright.
Jack and I did some very rough calculations on Saturday, and worked
out that for a 1 megapixel camera flying at 500ft with a ground speed
of 70km/h or so, we'd probably take about 45 minutes to cover all the
ground, and at that height the target dummy would be only about 2
pixels wide.
So I think it may be better to fly as high as we can, and look around
with the camera to find potential target sites, then zoom in to
confirm. Otherwise we'll just spend too much time in a search pattern
and not enough on the package delivery.
If I can get the FlightGear sim in reasonable shape, with ArduPilot
control, then maybe we can test out some strategies with satellite
images and randomly chosen target sites. Perhaps we can work out how
to fake up a "video feed" based on the sat images. It won't replace
real practice, but it might give us some idea of how we can approach
the task.
While I'm waiting on my ArduPilotMega to arrive I've managed to get a
version of ArduPilot running on my little TwentyTen Arduino board. I'm
working on feeding it fake GPS and sensor data from FlightGear now,
along with control data from APM to send to FlightGear.
Cheers, Tridge
[Canberrauav] thoughts on data link, camera etc
tridge at samba.org tridge at samba.org
Tue Jan 18 13:40:45 EST 2011
Hi All,
I've been talking to two HAM friends of mine, Hugh Blemings and
Anthony Wesley, about this project. Hopefully they will be joining
this list soon, although both have other commitments this year which
means they won't be able to put a lot of time in. They also have some
expertise that may be useful in other areas of the project. Hugh is
the co-author of the "Practical Arduino" book, and Anthony knows a lot
about specialised cameras from his digital astronomy hobby.
This email is a bit of a dump from the discussions that I had with
Hugh and Anthony this morning.
Both Anthony and Hugh thought that the best setup would be to use
2.4GHz digital 802.11 point-to-point wifi.
Hugh pointed me at this link budget calculator:
http://store.freenet-antennas.com.au/linkbudget.php?osCsid=14b1b88947984dccc1fd
this allows you to put in all the parameters of your proposed radio
setup and work out what range you can expect. If we enter the maximum
allowable power for 2.4GHz in Australia (4W EIRP which is 36dbm), then
we could go with this setup:
on the plane:
2W 2.4GHz USB wifi dongle (these are cheap, eg. $42 on ebay)
3 dbi simple antenna
that puts us right on the 36dbm limit for 2.4GHz in Australia
On the ground:
15dbi antenna
100mW wifi access point
that puts us right on the 36dbm limit on the ground as well. The 15dbi
antenna should be very easy to point without any need for tracking.
For example, we could use this one:
http://store.freenet-antennas.com.au/product_info.php?products_id=408&osCsid=14b1b88947984dccc1fd
which is 15dbi and has a 120 degree angle, so we don't need to worry
about a tracker at all. That combination should get us over 13km with
plenty of room for error. If we have a receiver with better
sensitivity we might do 20km or so.
If we find that interference between the RC and the 802.11 link is
really a problem then we could have have the option two phases of
operation:
- takeoff and landing would be done with the normal RC, Jack flying
- once in the air, the autopilot would be engaged, and we'd switch on
the 802.11 link. The RC link would be switched off.
- all data from the plane (digital video, telemetry, control etc)
would be carried on the 802.11 link.
- when coming back to the airfield we'd switch back on the RC for
landing
I think we'd need a much more powerful computer on-board than the
arduino. We'd still use the arduino for the autopilot, but that would
talk to a small ARM board running Linux which would run the 802.11
link, and do video compression plus control the camera.
Anthony suggests a firewire camera, something like this one:
http://www.ptgrey.com/products/flea3/flea3_firewire_camera.asp
That is the camera that Anthony currently uses for his astronomy
work. Apparently it is particularly good for IR. Anthony thinks that
this is the sort of camera to use as it could use very short exposure
frames, so vibration and motion of the plane should be much less of a
problem.
This camera has a firewire link, which is also used to control the
lens (the lens is bought separately and screws into the mount on the
front of the camera). So we'd need an ARM board that has a firewire
link (Hugh, can you recommend one that you think is suitable?). Then
we'd need to find a suitable zoom lens, and add pan/tilt servos to
control the camera direction.
I also thought we could put a Telstra3G dongle with a small antenna on
a spare USB port on the computer in the plane. It won't get 3G
coverage in Kingaroy, but it should get a 64kbit GPRS link. That would
give us a backup link into the onboard computer which we can use to
get the basic telemetry data from the plane, and GPS data. So if we
lost wifi we'd still have a way into the plane to find its position,
and potentially reset the 802.11 link. The GPRS link could also be
used to switch us between RC and 802.11 operation.
I know that using wifi introduces latency, but I don't think that will
matter too much. For takeoff/landing the RC will do the job. The
autopilot will fly the plane on the approach to the target area and
the search pattern, once its in the air, and the onboard computer
would be sending back images as fast as it can. We'd control the
tasking of the camera from the ground station, but not in terms of say
"pan left, tilt up", instead we'd send commands saying "take a
high-res photo of the following location", or "take a series of
low-res photos along this path". So we wouldn't be trying to control
the camera in real-time, we'd be reviewing the images as they come in,
and it won't matter if there is a delay between the images being taken
and us seeing them. We just need to timestamp the images accurately so
we can calculate the GPS coordinates of any position in the image
(based on the some trig, and the known positions, angles, heights
etc). We'd buffer the images on a SD card on the onboard computer.
The same goes for the package drop. We take enough photos of the
target at different angles to pinpoint its location as well as we can,
then we have an autopilot program to actually do the drop. We have to
do the drop from as low a height as possible to have any chance of
success, which means the radio link will be at its worst (maybe we
wouldn't even have line of sight when dropping the package?). I think
that makes it essential that we be able to automate the package drop.
Cheers, Tridge
Copyright 2011 http://canberrauav.org.au/