For the next version of APM (the fixed-wing codebase), we're thinking about adding an acrobatic scripting language, so you can program your UAV to do awesome robotic stunts. APM already suppports inverted flight, and adding other maneuvers is technically easy once we decide on how to program them.
As a comparison, the UAVDevBoard uses LOGO as its scripting language and also supports inverted flight and harrier/hovering. APM does its scripting with MAVLink via the Mission Planner or HK-GCS, which is a more visual way to plan a mission.
One option is that we could add MAVLink commands that took the following form:
- Roll (rotations/distance, rate)
- Knife-edge (duration/distance)
- Loop (radius, degrees)
- Harrier/hover (duration)
Acrobatic commands would be executed in parallel with waypoint commands, so you could script the position, too.
What do you think? What's the best way to script acrobatics?
Comments
Hyon, yes, you can control a copter using MAVLink, and that is in fact what you are doing if you use a joystick connected to the planner to fly a copter.
Right now it doesn't have much in the way of safety checking though. If you lose the link from the GCS then your copter will probably crash badly. The problem is that in ACM if you stop updating the RC overrides sent over MAVLink then the last values you sent will just stay there. Nothing you do on the transmitter will allow you to take full control again. In APM there is a timer that starts when you send a RC override over MAVLink, and if you don't send updates for a couple of seconds then the RC override is cleared, giving the transmitter control again.
darn, my posting was truncated, here is the rest:
------------
If you switch to another switch position then RC override would not be active
and you'd have TX control.
Note that this logic would need to read the real value of the mode
switch channel, which means we'd need a new function in the RC library
to ask for the real RC input, ignoring any current override.
This would still allow the script to control flight modes. It can use
the RC override to set the flight mode switch to anything it likes,
allowing maneuvers which involve any of our flight modes. It would
only be when the pilot uses the real TX to change to a switch position
where RC override is disabled that the RC override control would be
disabled.
I imagine most people would choose one switch position that they use
for manual control when a script goes bad. On a copter that may be
SIMPLE mode or LOITER, and for a plane it would probably be STABILISE
or FBWA mode.
script feedback
---------------
I think the pilot needs to know what the script is doing without
looking at the screen of the GCS. The way I do this in mavproxy is via
a say() method, which goes to a text to speech library. For example, I
have code which does this:
say("%u meters" % altitude)
and it reads out the altitude. I trigger this on changes of more than
10m in altitude at the moment. I read out battery levels and mode
changes in the same way.
If we have that method in the scripting language in the GCS then the
aerobatic scripts could add things like say("barrel roll").
My newphew (who also uses mavproxy) recently added an extra parameter
to say() which gives the priority of the message. This is needed to
ensure that important things in the speech output override less
important ones. For example, it reads out mode changes at a higher
priority to altitude changes, so if you are climbing fast you still
get audible feedback on mode changes.
All of the above requires very few changes to APM, but would give us a
very advanced scripting system. There is still a question of what
scripting language we use in the GCS. I'd vote for python, but it
could really be just about any eeasy to use scripting language. We are
not constrained by small memory limits on the GCS.
I'd also like to see the ability to have the scripts run externally to
the planner. I think the best way to do that is to add the same
mavlink forwarding ability that I currently have in mavproxy to the
planner. The planner already can do mavlink over UDP, what it needs to
do is accept mavlink slaves over UDP, so the planner has control of
the serial port, but it allows for other mavlink-enabled programs to
access the UAV by accepting UDP mavlink packets and forwarding them
(and forwarding replies). If that were added then users could write
scripts in any external language that supports mavlink (python is the
obvious choice).
Cheers, Tridge
This is the full post I made in private email, I thought others might like to see how I'm thinking this could be implemented
--------------
I agree that acrobatic scripting is a cool idea, but I'm not sure that
the best way to implement it is via scripts running on the APM
itself. I've previously suggested that a scripting language on the APM
would be great, but given the amount of free memory we have, now I'm
not so sure.
If instead we ran the scripts on the GCS then I think things become
much easier, and we could do much more sophisticated scripts. We may
need some additional command types in APM for maneuvers that need high
rate control (perhaps 'barrel-roll'), but the high level logical
control of the script would be located in the GCS.
Via the RC override that we're already using for joysticks (and I'm
using for keyboard control), we already have everything we need to do
GCS control of the MAV. A GCS could easily do some pretty fancy
maneuvers using existing MAVLink commands to APM right
now.
The only thing we really need is a few extras to make it safer. We
need:
- a way for the pilot to trigger the script using the transmitter, so
you don't need to look away from the plane to the GCS to start a
script
- a way for the pilot to take control again, getting the plane back
into transmitter control in whatever mode the pilot wants, again
without having to touch the GCS keyboard or look away from the plane
- a way for the pilot to know what the script is doing without
looking at the GCS screen
Each of these is easy to solve with very little code.
script triggering
-----------------
For triggering the script, I'd suggest the GCS label each script with
a logical statement based on the MAVLink stream. When that logical
statement is true the script will start executing. For example:
script1: RC_CHANNELS_RAW.chan6_raw >= 1600
then the user would setup their transmitter so they have switches to
enable particular scripts. Note that this requires no code changes to
APM. It just requires the GCS have the ability to evaluate logical
conditions based on the MAVLink stream.
I'm already doing this in mavproxy for our UAV project. For example, I
have code in the GCS that triggers a ground checklist like this:
if (m.chan7_raw > 1700 and status.mode_string == "MANUAL"):
system_check()
this allows me to trigger a ground check list (checking all sorts of
things about the UAV) when I flick the trainer switch on my TX while
in manual mode.
taking back control
-------------------
I think it is vital that the pilot be able to take back control very
quickly, and this can't just be by putting it in 328 manual mode (we
want this to work for copters too!).
We already have this to a limited degree with the RC override timeout
logic in APM, where it removes the RC overrides if it doesn't hear
from the GCS after a couple of seconds, but I think we need something
more immediate for control of scripting via the TX. If the
plane/copter is diving into the crowd you want to grab control fast
and you don't want to rely on good Xbee comms to do it.
So I think we need a parameter that controls when RC override is
enabled, based on a RC input. There are lots of ways to do this, but I
think the most flexible is to have a 6 bit bitmask EEPROM parameter
that says which control switch positions allow for RC override. This
could be called OVERRIDE_MASK and if you (for example) set it to 7
then switch positions 1, 2 and 3 would allow for RC override. If you
switch to another switch position then RC
We're probably going to implement this on the ground side. The best solution may be a Python interpreter running a script that communicates (via the GCSs) with APM in MAVlink. We already have a joystick mode working in APM, which allows ground computers to completely control it, so it makes sense to run the scripts on the ground where we have all the memory and processing power to do any sort of fancy calculations we want. So you can just switch to a mode where the ground stations flies the UAV via fly-by-wire while the script executes.
Here's an example from the AR.Drone. It works the same way: the script runs on the ground station:
I like the idea of hovering commands, could lend it self to some simple VTOL setups
@Chris, Sounds good to me. And of course if you put a Gumstix or other micro Linux controller (Beagle?) in the plane, then you can run your python in the plane as well. (Tridge also has Linux computer on board).
All the GCS has to do is call a standard Python interpreter and then pass through the MAVLink commands via the UDP port that the Mission Planner and HK GCS already support.
We're practically already there!
Pete,
That sounds like a really cool capability - it is similar to how the people at UPenn control their quadrotor that can do crazy maneuvering around various objects.
I would like to propose a slightly different approach, which may have some pros and cons compare to the idea of following a pre-recorded flight path, and maybe some combination of the two could work.
I think a couple difficulties with the recorded flight control path may be 1) being able to sense the aircrafts position and velocity accurately enough to follow a potentially intricate pre-recorded flight path, and 2) that the recorded path may be interesting, but it may not be considered all that autonomous, since it can't react in any way to its surroundings.
I would propose defining aerobatic manuevers, or possibly elements of aerobatic maneuvers, in terms of how a pilot would approach the manuever. For example, when a pilot flies a loop, they are not following an exact flight path, the are doing something like this: before starting the manuever, they verify they have the appropriate initial airspeed, attitude, and altitude. The maneuver would then be defined generally as increasing pitch attitude and throttle to attempt to keep a constant radius around a loop axis point, until an exit condition is reached (either the top of the loop or back to the bottom of the loop).
So, to make a comparison to computer graphics, I think this approach would be more like vector graphics, in that general task elements are defined - such as rolling, flying at a specific 3-d vector, or flying in a radius around some 3-d axis vector, or combinations of those. This could allow for more flexibility in adjusting the flight path in-flight, and scaling a set of commands for different types of aircraft. This approach would also have to know something about the aircraft performance, since an arbitrary 3-d vector (for example, straight up) can't be flown forever, but depends on the aircraft performance. This approach could also potentially allow for the UAV to change maneuver elements in-flight to react to its surrounding, say if a tree is in the way, it could find an element that would result in it not heading toward the tree. This would obviously need some prior knowledge regarding aircraft capability to know how much of an element can be flown given a certain initial flight condition.
Pete's approach sounds like it would be a little bit more like rastor graphics, like an image from a camera where each pixel is defined - which would allow for a much more exact recreationg of a flight path. If you want an aircraft to fly an exact, arbitrarily curving path, then this would allow for much more flexibility than a path consisting of rigidly defined maneuver elements, just as a jpeg can express a more complex and realistic image than can be described in something like postscript.
I think each approach could have strengths and weaknesses, but I just wanted to throw in a possible alternate approach.
Many thanks for the great comments and smart analysis. Do you think we can set up a collaboration to come up with some algorithms and a common framework that can work with MAVLink, which both APM and UDB (soon) support?
Maybe we can set up a task force of APM and UDB developers to work on this.
Once again, my post was cut short (by a couple of paragraphs). But that should do for now. I'll wait to see if I have stimulated any further comments and discussion. Best wishes, Pete
-
1
-
2
-
3
-
4
of 4 Next