[Canberrauav] Ardupilot & Mission Planner Development
Stephen Dade stephen_dade at hotmail.com
Thu May 9 12:51:12 EST 2013
Hi Michael,
(I've cc'd this to the CanberraUAV mailing list too. I'd recommend that you sign up too
to get responses from our entire team)
Answers are below.
Thanks
Stephen
---------- Forwarded message ----------
From: Thomas, Michael (RTIO) < Michael.Thomas at riotinto.com>
Date: 8 May 2013 01:31
Subject: RE: Ardupilot & Mission Planner Development
To: Canberra Uav < canberrauav at gmail.com>
Hi Stephen,
Thanks for all the info! Really appreciate your guys help and the team’s openness. J
If I understand correctly your on-board Mission Planner Computer does the following
functions:
· Commands sent from GCS to autopilot are received by mission planner computer
and passed to autopilot
Yep. The GCS<->Mission Planner link had many items within it (MAVLink telemetry/
commands, images, ssh, etc). The MAVLink packets were forwarded to/from the APM
· Is there a diversity set up of the 900Mhz link and 5.8Ghz link, or is it only the 900Mhz
that is used for the APM datalink? In this case are the commands sent over both channels
and then if the same command was previously received it was ignored?
The links were redundant. MAVLink was streaming over both links and the mission planner
used the MAVlink timestamps (and a RSSI feed from each radio) to filter out a single stream
to the APM. When a radio failed, the mission planner handled the switchover automatically.
· The autopilot detects loss of GPS, loss of datalink, geofence as per standard on-board
functions and communicates this to ground station via the standard MAVLink protocol à the
mission planner computer then picks up on this, and according to the programmed logic
(based on the OBC rules) will give the autopilot new GPS waypoints. I assume the mission
planner computer would also notify the ground control station that it has given the autopilot
a new waypoint?
The APM detected loss of GPS and Geofence. The mission planner detected loss of radio
link(s). This was all forwarded to the ground station. If the specific failsafe called for new
waypoints (as per the rules), the mission planner would command the APM to the appropriate
waypoint ID/number corresponding to the appropriate waypoint stored on the APM's memory.
This would all be forwarded to the ground station.
· In the case of mission boundary crossing, the failsafe itself would pick this up and immediately
engage the flight termination mode
Yes, it would. This was why the failsafe board was in between the APM outputs and servo inputs.
· The on-board mission planner computer also received the bottle drop commands and flight
termination commands from the GCS and forward these to the failsafe or bottle drop servo
The bottle drop command was done via MAVLink, so it went via the mission computer. I believe
the termination command (if from the ground station) went to the mission computer then straight
to the failsafe (there was a TTL connection between the two)
Given this configuration I believe no specific changes are required for the autopilot, is this correct? It does
seem like a better way of doing it than trying to implement the mission logic into the ardupilot unit itself,
as we are currently planning on doing. Although it does mean an extra computer is required! Out of
interest what were the changes that you made to the code that are now implemented into the standard
firmware?
Geofence was the big one. Also loss of RC radio link. It should be noted that the standard firmware doesn't
take into account having a failsafe board, hence there are a few patches of ours that are not in the standard
firmware.If you plan to do on-board image detection, you'll need an extra computer anyway!
What GCS software were you using? If you were using a standard one such as the APM Mission Planner,
did you make any changes to this to monitor the status of the mission logic? And did you make any changes
to command the bottle drop and flight termination? Did you make any changes the MAVLink protocol at all?
We used MAVProxy. It's a python-based command line ground station. We wrote several OBC specific
modules for it (and a basic GUI). You can find it at http://qgroundcontrol.org/mavlink/mavproxy_startpage.
We made no changes to the MAVLink protocol itself, but some of the underlying code was optimised for the
OBC (such as the ability to carry images within the stream).
Yes that’s a good point about getting as much practise operating the Ardupilot as possible. Definitely a
complex piece of software, it’s proven a challenge to get it flying properly in the simulator! And good point
about equipment backups – looking at our budget about half the cost is going to be transport and
accommodation so it definitely makes sense to plan for a few extra airframes and autopilots along the way.
Also make sure to log every flight! You'll soon become experts at trawling though logfiles looking for "what
went wrong". I'd also suggest getting a number of small (cheap and simple) aircraft for basic testing too - it's
less stressful loosing a small $70 foamie than a large $300 frame.
Thanks again, I hope we’ll be able to get to the stage of helping out other teams at some point.
Mike
From: Canberra Uav [mailto:canberrauav at gmail.com]
Sent: Wednesday, 8 May 2013 11:25 AM
To: Thomas, Michael (RTIO)
Subject: Re: Ardupilot & Mission Planner Development
Hi Michael,
Looks like your team is coming along nicely! In answer to your questions: The exact APM
source code that we used for the competition is available at https://github.com/diydrones/
ardupilot/tree/CanberraUAV-OBC-2012 (note this is several versions behind the the current
APM version)
The Image detection/mission planner code is at https://github.com/CanberraUAV/cuav
We had a failsafe board connected between the RC outputs of the APM and the servo. The
failsafe was also receiving status data from the APM and mission planner computer. If any
of the failsafes were triggered, the mission planner computer would change the UAV's flight
path as needed (ie. loiter during GPS failure). If a hard termination was required, either the
APM or mission planner computer could signal the failsafe to move the flight servos to termination
mode.
In terms of the specific failsafes:
-Geofence: Standard feature on the APM
-Loss of GPS/Datalink: able to be detected by the APM.
-Bottle drop: on our mission planner code
-Flight termination: our our failsafe board
Unfortunately, I can't find our failsafe code at the moment. I'll check with the other team members
to see where it's hiding.
In terms of documentation for the APM, it's all on the DIYDrones site. Unfortunately there's not
too much in regards to the structure of the code. However, I don't suspect you'll have to make many
modifications to the code, since most of our OBC2012 patches are now incorporated.
As for your plan of attack, I'd suggest doing:
1. Use the APM in SITL, HIL and real flight to get experience in using it (particularly AUTO mode).
The APM is a complex piece of software and many, many flight settings. Incorrect settings have the
potential to cause spectacular crashes (we lost at least 2 airframes due to this!)
2. Start testing the other components (radios, cameras, etc) to ensure they work both in isolation
and with each other
3. Once you’ve got an idea of your equipments capabilities, start the coding
4. Test as much as possible, in a variety of conditions. The vast majority of the teams that dropped
out in 2012 were due to not reaching the 5 hours of AUTO flight requirement (actually a lot harder than
it sounds. We averaged ~1 hour of AUTO flight per week, the rest was spent debugging, coding and
testing).
Another tip is to always, always have backups of all equipment. In the 6 months before the competition,
waiting 2 weeks for a replacement part to arrive cuts way too much into the flight testing schedule. One
team in 2012 OBC had a complete crash the week before the competition and had to pull out because
they didn't have a backup UAV.
Hope this helps!
-Stephen
On 6 May 2013 02:00, Thomas, Michael (RTIO) <Michael.Thomas at riotinto.com>
wrote:
Hi Stephen, I’m writing from the Perth UAV Team, H2Joe.
For our autopilot system we will be using the Ardupilot and we are planning to implement
specific additional functions to meet the requirements for the OBC:
1. Hard GeoFence
2. Loss of GPS
3. Loss of Datalink
4. Loss of GPS & datalink
5. Command bottle drop
6. Command Flight Termination mode
7. Mission Logic
We also plan to implement a way to track the status, and control these functions in
the Mission Planner utility.
We have set up the Arduino IDE and VS C# IDE, as well as the HIL simulator to test
out the progress. Our current plan of attack is to:
1. Understand how the code for the ArduPilot and Mission Planner works, and
identify the inbuilt variables and functions that we will need to modify
2. Implement desired modifications
3. Test in HIL and in full test I was wondering if you have any documents that describe
in detail how the code for the ArduPilot and the Mission Planner work? And any
tips you may have for implementing these desired functions, from your own
experience?
Also, I’ve attached the first newsletter for Team H2Joe. Regards,
Michael This email (including all attachments) is the sole property of Rio Tinto Limited and
may be confidential. If you are not the intended recipient, you must not use or forward the
information contained in it. This message may not be reproduced or otherwise republished
without the written consent of the sender. If you have received this message in error, please
delete the e-mail and notify the sender.
Copyright 2013 http://canberrauav.org.au/