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
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 would suggest a more primative language first. One in which you could describe attitude. That language could be used to build bigger maneuvers. I'll work on some examples.
I like the idea of hovering commands, could lend it self to some simple VTOL setups
@Chris
I have a question. Can I control copter by using MAVLink protocol now?
I'd like to control copter using Xbee.
And to do some acrobatic motion, I think AHRS and current control system should escape Euler angle paradigm.
I already changed AHRS code to quaternion to reduce normalization processes.
And also we should build some good controller based on quaternion for the stability.
By the way, how about start to build variable pitch quadrotor as standard? I'm in
@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).
Following on from Simon, and also having aerobatic experience on full size planes, the vertical dimension is important. Translates into attitude, speed and with the low margins available in aerobatics, tight control. An easy example of height, attitude, speed is a controlled side slip. More critical might be an 'initial & pitch'.
One question is what sort of aerobatics are in mind. Fullscale competition aerobatics are performed in a 3 dimensional box which require accurate 3 dimensional control and plane placement. The 'occasional' aerobatic manoeuvre not so much a problem if there is adequate height and speed. Also, serious aerobatics have slippage in the sky which varies with speed, attitude and must be allowed for quickly. Manoeuvres like a conic Lomcavok will be interesting since I see them as basically throwing the plane into an uncontrollable movement and then recovering. Final comment, aerobatics is very, very plane dependent! So 'tuning' software an issue at the bleeding edge of the aeros.
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.
-
1
-
2
-
3
-
4
-
5
of 5 Next