Now that we’ve returned to Canberra and taken a well-earned break, we have spent some time reviewing our performance at the OBC. The following article is a review of what we did and didn’t do well as a group at the OBC.
Winning the OBC, whilst an awesome achievement, has also provided us the chance to act out a search and rescue scenario as a team. Thus a review of our performance at the OBC provides some valuable information on how we can improve ourselves in future “real life” S&R scenarios, in addition to providing hints and tips for other likeminded UAV organisations.
Note that this review is from a generally non-technical perspective. Fellow team member Andrew Tridgell has written an excellent technical review of our performance at the OBC.
Things we did well:
The two radio systems (5.8 GHz Ubiquiti Rockets and 928MHz RFD900’s) used for telemetry and imagery worked quite well. The automatic failover between the two links worked flawlessly and enabled us to easily work outside of the range of the 5.8GHz datalinks for parts of the mission.
The Pixhawk/APM:Plane flight controller tracked the waypoints during the mission extremely well during periods of strong gusting winds.
Our image recognition hardware/software found the missing bushwalker easily and quickly displayed it on our screens. Repeated passes over Joe allowed us to get a high accuracy on our estimated position of him.
The wind correction algorithm for our bottle drop, whilst simple, worked extremely well. During testing, we’d used our data to develop an empirical formula for predicting the bottle drop location based on the aircraft’s position and speed and the direction/velocity of the wind.
Things we didn’t do so well:
Labelling of power ports – during setup, we accidentally killed the ethernet switch used in the Ground Control Station (GCS) network (as we had multiple GCS operators/laptops) by plugging the switch into a 12V plug instead of the 7.5V plug. Fortunately, we’d bought a spare switch with us!
Checklists and communications were definitely an item we’d not tested and developed enough. There was confusion about who was doing which check and when on the checklists. Some critical items were left out of the checklists.
Our takeoff and landing (done automatically by the APM) were marginal, far below our usual quality. The takeoff in particular raised some concerns from the OBC Judges, as the UAV was blown off course towards the GCS and Judge’s tents during takeoff. From an organisational perspective, several things did NOT happen:
- We did not take the wind into account during our takeoff preparations
- Lack of practice in taking off in windy conditions
- Lack of communication between the GCS and Pilot as to the wind conditions
- Lack of practice in aborting automated takeoffs
At the end of the day, we were very focussed on gaining the extra points in the OBC (for an automated takeoff and landing) and we never stopped to properly consider the circumstances under which the automated takeoff would not be appropriate.
During the mission itself, our antenna tracker required slight offsets to track the UAV properly. Part of this was due to a different magnetic environment at Kingaroy (compared to our home base in Canberra) degrading the compass accuracy. In addition, we’d never considered having to set up the antenna on non-flat ground!
As mentioned previously, the landing to Kingaroy airport also presented some issues. One again, the wind had its own ideas and carried the aircraft past our nominal landing point and it did not land until much further down the runway, finishing up very close to the geofence. As with the takeoff, we did not consider the effect of strong winds on our aircraft during this phase, nor did we have experience in landing in strong winds.
So, for other UAV operators out there, we offer the following advice:
- Don’t just have checklists – use them regularly and continuously improve them
- Practice flights in a variety of wind conditions. Know the limits of the airframe and of the automatic flight modes in these wind conditions
- Ensure that safety is always put first - have a safety management system. UAV’s do have the potential to hurt or severely injure people!
- If operating in a team, make sure that everyone clearly knows what their responsibilities are. Checklists and operations manuals work well for this. Following this, regular practice with a full UAV/GCS setup with the entire team is a must
A full review list is available at https://canberrauav.readthedocs.org/en/latest/lessons/OBC2014/review.html
We'd like to thank 3DRobotics for their very generous support of CanberraUAV for the 2014 UAV Outback Challenge. Thanks also go to all the individuals we've collaborated with, to further the field of S&R UAV platforms.
Comments
JB: Great comments! Good to know I wasn't the only one needing to wrangle my team into action :)
The large airframe we used was designed for the OBC - able to handle the wind in Kingaroy and have enough range to complete the mission. For general S&R situations, we would much prefer to use smaller aircraft.
Andrew you're right on the money. We did exactly that for PerthUAV, with each member using their own dedicated list and then giving an "all systems green" before launch, with checkpoints along the way etc. However once we had used it to setup the UAV and launched, the rest of the "checklist" for mission control and failovers was virtually disbanded (apart from what we had in our head still!) simply because it wasn't "dynamic" enough to deal with the multiple failures we experienced on the day.
The other issue we had was that we couldn't print out the last minute alterations on the paper checklists, plus as Stephen pointed out, it's just really hard to get everyone and everything there at the same time to run through checklists for testing! Typically there is some issue or another to resolve and that is what takes precedence and things always seem to progress sequentially at the limited flying meets where everyone participates, which means that some things just never get done in time. I remember spending 4 hours on hangouts(skype) a few weeks before going over and we only managed to get through 2 pages of the 6 page checklist! We were exhausted afterwards, and everyone hated my nicely color coded and ID'd checklists ever since! After the event though we realized just how important they were and wouldn't do another event without them and adding a lot more detail to them.
One thing we tried was to use iAuditor which is a Android app for checklists that can run on your phone or tab. The good thing is that it can be interactive in that certain events can unfold greater detail, for faultfinding or failovers etc. and once they are resolved the "normal" checklist would resume. It's quite a good app and can be edited and synced via an online browser. I wished I had persisted and used it more in the group, but hopefully soon we'll have our checklists integrated into our GCS app as well. It's just to easy to get distracted by all the technology "bling", but making decisions before an event, especially ones where you only have limited time to act, can mean the difference between failure and success.
--
Thx Stephen for the write up. It's good to see that I wasn't alone in trying to orchestrate "team behavior" and keeping everyone in their delegated area of responsibility! ;) There were a few role swaps because our primary nav guy couldn't make it last minute, which made things more challenging, but overall I was really happy with our performance at the event.
I also agree with the safety aspects of operating a UAV and this was a main consideration in selecting a platform that had low inertia, small and lightweight propulsion with slow spinning pusher prop, limited fire danger (no fuel - 2-3 litres of fuel is not a trivial amount when it crashes over people and ignites, that's one big molotov and it can come at speed which spreads it fast!), a soft squishy nose and wing, as little metal and structural timber as possible and a good payload to airframe weight ratio to keep the overall size to the absolute minimum. Another thing we opted for in the build was the use of a lot of velcro to attach things together and by mounting a lot of the weight on damping (good for imaging too), which meant that on impact things came loose and moved but didn't break. Even after tip stalls and flight termination the aircraft remained flyable that way without even needing repair in most cases after "bouncing" off the ground. It's one tough bird. Sure an X8 is a just foamie, but it also ticks all the right boxes for safety! I think safety starts all the way up the top of the decision making tree with UAV's, and that's where the solutions need to be introduced. Trying to manage the safety of a big airframe just makes it so much harder IMHO, finding the sweet spot between requirements and performance is key. With UAV's I think the smaller the better.
On practicing with the whole team and all systems in all conditions: You simply can never, ever, have enough of this!
I think it's probably the fastest way to fault find and make progress, as everything really starts going wrong all at once and everyone realizes just how much more work needs to be done to get over the line! ;)
Good job!
Regards.
Awesome effort guys. Very well done
Andrew - we had a basic command structure (pilot, backup pilot, GCS lead, GCS secondary, Imagery lead), but we weren't very experienced with it. We'd only done a handful of practice missions before the OBC.
Part of this was that our usual test flights were done by 2-3 team members. I suppose we didn't want to go to the trouble of setting up and tearing down our full GCS setup on a regular basis. Another factor was getting the entire team at the flying club at the same time!.
Interesting post Stephen. It almost sounds like you need to implement a mission command structure like NASA with a series of defined roles and a checklist tailored to each role, including a Supreme Being/Pilot-in-Command/Flight Controller.
Perhaps you already did this?