Every now and then a new blog post or forum thread pops up something along the lines of "Be careful, I got cut by the propeller ..." with ugly images attached.

UAVs are complex solutions and can be dangerous. The technology itself can help prevent accidents but eventually in most cases it boils down to human errors. I have fond memories sitting in a cockpit while going through checklists. We should learn from the real aviation and adopt checklists to make flying UAVs safer. I am always going through my checklist on paper before a flight. This is a proven approach to keep risks low.

In our situation we could take the idea of paper checklists even one step further: interactive checklists. It would be even nicer if the groundstation software would aid the operator going through the checks. The GCS could help by displaying relevant values which need to be checked and allow user input where needed in a structured ways, step by step.

The Image above shows a mockup of a tablet base UI which could be used as checklist in the field. If such a feature would be implemented in DroidPlanner orAndropilot it could also offer GUI components to switch mode or read settings while going through the checks.

Below is my checklist for an electric plane. It might look different depending on vehicle (even for fixed wing planes). I think it would be important to make such checklists configurable. The user should be able to re-order and add/remove items. 

From preparation to launch, during the mission and while landing different checklists are required. The checklists could be organized in tabs.

 

My checklists:

 

Preflight check
[  ] Check payload battery
[  ] Check payload on
[ ] Check UAV battery
[ ] Check airspeed sensor clear
[ ] Turn on transmitter
[ ] Mode manual
[ ] Power idle
[ ] check prop clear
[ ] Power up UAV
[ ] block airspeed sensor
[ ] don't move UAV until elevator flicks 3 times
[ ] Connect telemetry
[ ] Check 3D GPS fix
[ ] Check altitude
[ ] Check airspeed
[ ] Check Home Location
[ ] Check cruise speed
[ ] Set home altitude to realtive alt.
[ ] Check moving surfaces [Manual]
[ ] Check moving surfaces [Stabilize]

 

Mission planning
[  ] Wind direction and speed?
[  ] Auto take off? Angle ___, Altitude ___
[  ] Check default altitude ___
[  ] Check altitude graph
[  ] Check distance
[  ] Upload mission
[  ] Download mission again and check

Take off
[  ] Check prop thrust?
[  ] Wind direction and speed
[  ] Takeoff flight path clear of obstacles?
[  ] Mode auto
[  ] Check elevator (auto takeoff only)
     launch against wind

Landing
[  ] Check home altitude
[  ] Check cruise speed
[  ] Check wind direction and speed

Shutdown
[  ] Power idle
[  ] Mode manual
[  ] Disconnect Telemetry
[  ] Power off

 

Views: 3977


Developer
Comment by Kevin Hester on October 5, 2013 at 11:20pm

Hi Joshua,

I think so too.  I don't know of any groups particularly related to this idea of collaborative lesson plans - it has just been an informal discussion a few of us have had by email.  It would be awesome if you want to coordinate a lesson plan effort - by Thursdayish, I should have some placeholder checklists / lesson plans in Andropilot - but I've been careful to write it as a module so we can get it into other GCSes without too much work (for droidplanner most of java stuff will just work, for mission planner the javascript layer could go in - someone would still need to write the micro REST web server this depends on).

Here's an edited email that summarizes the primitives you'd have to build / extend your scripts:

So last night (while sleeping - so YMMV) I ended up thinking about how to implement the 'GCS config' file idea.  ...
I'd propose the following (and I'm happy to implement as a module so it it is pretty portable to other Javaish GCSes):
  • GCS config files are really nothing more than Javascript inside a slightly special web page.  The suffix for the page must be .gcs.html.  (This double nesting is important to make it easy to register the GCS app as the preferred handler for URLs of this form)
  • When opened inside a GCS software magic will provide a special global named GAPI will be available to any Javascript on that page.  This embedded API will support a small number of operations to facilitate vehicle config and (here's the cool part) scripting.
  • If the GCS detects that a page is trying to reference this special scripting API the user will be shown a warning (see below)
  • Example methods in this Javscript shell (provided from GAPI and a small GAPI-support.js file):
    • vehicle.mode.get
    • vehicle.mode.set
    • vehicle.location // lat, long alt etc... - useful input to future 'advanced' javascripts
    • vehicle.heartbeat.foo // information from the heartbeat
    • vehicle.params.get("foo")
    • vehicle.params.set("foo", 56)
    • vehicle.params.set("RC9_FUNCTION", "aileron")  // The GCS already knows these names for param enums, because it uses pdef.xml.
    • vehicle.wp.add(...)
    • vehicle.rcchan.get
    • vehicle.servo.get
    • gcs.menuEnable("foo", true)
    • gcs.buttonEnable("foo", true)
    • gcs.guidedTo(lat, long, alt)
    • id = gcs.startTlog("name")
    • gcs.stopTlog(id)
    • gcs.dshare.upload(id)
    • gcs.compassCal()
    • gcs.location // return lat long alt of GCS
  • Multiple vehicles could be exposed through the same API (so one javascript could do swarmish things with a bunch of copters)
  • If viewed in a regular web browser the HTML can contain anything we want and it will be shown to the user.    
Use cases:
  • ...
  • A much more powerful application: ... can make a lesson plan, with one page per lesson.  That page will be shown in a (dockable) window inside the GCS and it can walk the user through 'preflight', 'intro to stabilize' (script can auto shrink the fence to be tiny)
What is nice about this idea:
  • Users can quickly start editing these existing lesson pages (as a starting point) and begin to share their own GCS script pages.  They just need to know javascript - or be willing to pick it up by chosing 'view source' in their web browser.
  • Most of this slick Javascript to GCS hookup comes for free on Android (I presume iOS has something similar - PhoneGap certainly does).  For desktop Java apps both Swing and SWT provide similar glue.  
  • All of the example methods I listed above are already in Andropilot (and to some extent all other GCSes) - so this is mostly very easy 'glue' engineering.
  • In fact this whole approach is quite a bit easier than the original Lua idea I've worked on.  It is also super accessible because anyone who knows basic javascript can script GCS lesson plans or even do complex (but alas GCS dependant) vehicle behaviors in Javascript.  Alas, of course it would be not portable to on-vehicle.  Such is life.
  • Because the page is regular javascript/HTML youtube videos, slick Flot based plotting and web analytics reporting libraries are all easy to use.
  • The full power of javascript is available - so I bet folks could make some really slick apps.  We could eventually have a whole set of tools built upon this 'click here to send upload your tlog/param file to droneshare and post to facebook etc...'
  • The javascript on the page can check for the GAPI object, if not found the jQuery can tweak the page content depending on what makes sense.  Examples:
    • Show a little info box at the top that says for instance "This tutorial is mean't to be run with a vehicle, but feel free to read the instructions and watch the videos now..."
    • Just show a box (remove all other content) that says "This is an Iris vehicle config file, please open this page on your Android device and click yes when asked if you want to open it in Andropilot/Droidplanner."
Comments/Questions?  I wanted to get this idea out while I was thinking of it.  Unless there are objections I'll probably go this way rather than the xml file I previously proposed.
Comment by Simon Wunderlin on October 5, 2013 at 11:38pm

Happy to see that more people seem to have this need. I am an absolute Android n00b but would really like to see it implemented for phones and tablets. Before submitting this proposal I have been thinking about a standalone app but it became apparent that GCS integration would make so much sense. 

@Joshua @Kevin @Arthur: My post was really just a very minimal proposal, haven't had time to do it more detailed. Shall we head over to Arthur's Issue and do a little bit more serious specification of what we want to achieve? https://github.com/arthurbenemann/droidplanner/issues/330 Everybody's input is welcome.

I am currently working on two projects that require my full attention until december. I might have some time until then, but not much. From december I'd be happy to dive into mobile development.

Comment by Simon Wunderlin on October 5, 2013 at 11:40pm

@Gary @Stone1295 I think a logbook function would be very nice. I first wanted to add this to the proposal but then I thought that telemetry logs are much better information that a manually written log. Telemetry logs log all your action, the actions of the uav and all parameters including mission plan. I think what is mission is a piece of software that generates a logbook from these data. No need to do it yourself, or am i missing something ?

Comment by Joshua Johnson on October 6, 2013 at 12:22am

I made my way over to my github account and reset the password and wiped off the cobwebs :)  After I get finished with this homework I'll be ready to start contributing!! :) 


Developer
Comment by Kevin Hester on October 6, 2013 at 12:40am

@Joshua - yay!


T3
Comment by Thorsten on October 6, 2013 at 1:54am

@Simon, for sure we have the telemetry, but the checklist should be documented/saved as well in a separate file. So in case of some problem/crash/accident you can show that you planned everything carefully (The problem however is that it is digital so it can be manipulated afterwards.)

Comment by Simon Wunderlin on October 6, 2013 at 1:54am

@Gary Mortimer what flights standard group are you talking about?

Comment by Simon Wunderlin on October 6, 2013 at 1:55am

@Joshua great!

@Thorsten I think saving the checklists contents shouldn't be too complicated. 


T3
Comment by Thorsten on October 6, 2013 at 1:57am

@Simon, sure! This would then be the "logbook".


Developer
Comment by Arthur Benemann on October 6, 2013 at 6:24am

Anyone that want's to elaborate on the logbook function please drop a comment on:

https://github.com/arthurbenemann/droidplanner/issues/331

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service