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
To continue my previous post which was cut short on submission ....
FLIGHT PATH CONTROL:-
Having discussed a generator that produces realistic flight paths (FEPG) for our particular plane, then we can turn our attention to flight path control.
Bill has started down this route, and I like his approach. The Autopilot has an understanding of the forces that can be exerted by all the flight surfaces, propulsion unit, and drag. So the Autopilot can potentially produce moments and acclerations to try to reach commanded for this moment of time in the flight. I would like to consider two states of the flight path control unit:
Solutions Exist. The point here is that there are potentially many solutions to converge current flight path to a commanded flight path. The difficulty initially is in creating an algoritm that describes the "Best Converged Solution", to generically use the forces availble to fly the airaft onto the commanded flight path.
To make this point easier to understand, please consider the following scenario. A World War 2 fighter pilot is flying straight and level, when he sees the enemy coming up behind him. He decides to turn around as fast a possible. What is his best solution ? In most films, you will see the pilot roll the plane over, and start to pull up on his elevator, as the plane becomes inverted, the plane pulls upwards relative to it's body frame, and downwards relative to the earth .... using gravity to increase it's speed and acclerate, and using the main lift of the wings to pull initially downwards (relative to the Earth) the pilot continues to pull up on the elevator, so that the plane is eventually flying straight and level in the opposite direction (he may climb up as well afterwards).
That is one "Converged Solution" for effecting a turn in the opposite direction.
Another Solution, is simply to do a normal coordinated turn, and turn the plane around keeping it at the same altitude on a level flight path.
There are potentially hundreds of solutions, to converge the existing flight path on to a commanded flight path. And all are potentially validid.
How does the Autopilot choose the "Best Solution" ? And how does one describe the "Best Solution", mathematically to the plane ? The plane has a "Flight Dynamics Envelope", choosing which portion of that envelope is part of this issue. To my mind the issue of how to describe "Best", is at the core of creating a good Mathematical Algorithm.
Solutions do not Exist: In this case, I suppose that the flight path should have sections. If a given sections (say "loop the loop" section) has no solution, the autopilot would move on to the next section (Say that was "Return to Home"). On should always ensure that the the final flight path section is easy to fly, so that a solution exists.
RESPONDING TO YOUR COMMENTS:-
With those frameworks in place, we can now start to understand how
" to handle the interactions between the low-level commands like SetThrottleValue(50), mid-level commands like SetRollRateInDegPerSec(45) or SetRollTargetAngle(90), and the high level commands like SetGoalLocationXYZ(100,200,100)."
When a user adds into the the flight a command for SetThrottleValue(50), what they have really done is reduce the number of available converged solutions for the Flight Path Control, to converge with the Commanded Flight Path. It's as simple as that. (Solutions may or may not exist as expalined above). The same is true of SetRollRateInDegPerSec(45). It simply reduced t
Sorry, folks, I have no idea why the second part of my post did not appear. I'm out of time for that just now, so it will have to wait for another day. Apologies. (Perhaps NING truncates comments over a certain length).
Ben,
The way I see this is that there are two distinct parts to the problem.
The two parts of the problem are linked by the "Flight Path". For this conversation, A Flight Path is defined as:-
(We could also consider Flight Paths defined where the angular velocity can also be defined with respect to the Body Frame, but that is for another discussion. Also flight paths relative to other planes !)
All of the above parameters are defined by the Flight Path Generator (in advance of the flight), for the duration of the flight (i.e. there are values for the above variables that are valid for any time of the flight plan).
Many of the potential problems of describing flight and then asking the plane to implement the flight, come from dealing with the Error Conditions that arise when the plane cannot physically do what has been commanded.
For example, the Flight Path Generator ( Flight Control Language) asks a rudder only plane (no ailerons) with dihedral on the main wings, to fly an inverted flight path in a circle !. The Flight Path Controller, (Autopilot) is going to have a tough time achieving that ! So what does it do instead ? That is a hard set of error conditions to handle.
FLIGHT PATH GENERATION:-
A vast number of error conditions are removed, if the Flight Path Generator understands the full dynamics of the plane. The Flight Path generator creates a path, which the plane shoud be able to achieve. That is actually what we arrange manually with most of our flights today.
For this conversation I am going to call such a flight path generator a "Flight Envelope ( Aware ) Path Generator".
(FEPG).
The simplest way to make a FEPG is to create a "Record" and "Play" feature for the Autopilot. (Chris, I think that Record and Play is an even bigger feature than Aerobatics). That is a truly "WOW" feature, and an excellent stepping stone towards aerobatics. Fly the plane, and record an Aerobatic display. Now you have a flight path, that the plane can definitely achieve. It just did it !sd The user interface is Simpolicity. One more switch on your transmitter for "Record" when it is one position and "Play" when it is another.
Once FEPG using record and play is running well, the development team can then turn their attention to a flight path generator that uses a simulator to achieve an FEPG without actually flying the plane for real. I suspect that the work that has been done with JBSIM (by James Goppert and team), will come in really handy at that point.
So I'm actually moving away from an Flight Control Language for Aerbatics. I'm not sure that is the way to go. I think we should explore another direction for now, and then come back to the Flight Control Language.
If we do go down the Flight Contola Language route, I have much more to say on the archictecture there, as I did quite a bit of reading and research on that last summer. (FLIPS and architectures for Domain Specific Languages). Using LOGO was a nice intermediate step as it's pretty easy for most people to understand.
FLIGHT PATH CONTROL:-
Having discussed a generator that produces realistic flight paths (FEPG) for our particular plane, then we can turn our attention to flight path control.
Bill has started down this route, and I like his appro
Sorry guys, this too me seems like a real waste of time and talent. I have to ask why would someone want this?
I think that the hardest part of coming up with a great scripting language for acrobatics and navigation is figuring out how to handle the interactions between the low-level commands like SetThrottleValue(50), mid-level commands like SetRollRateInDegPerSec(45) or SetRollTargetAngle(90), and the high level commands like SetGoalLocationXYZ(100,200,100).
Some combinations seem compatible, like continuous rolling while navigating. But some do not, like continuous looping while navigating, since you can't really progress towards your goal while performing circular loops.
Some people have also requested the ability to directly set the deflection of control surfaces. This is even lower-level, and seems to conflict even more directly with the higher-level commands. (Set the rudder to deflect hard left, while trying to navigate to a goal on the right?) But maybe the results of high and low level commands could be additive, so if you set the deflection a bit to the left, and then try to navigate right, they'll fight a bit, but navigation could eventually win out, just like how manual control can overpower automatic stabilization in MatrixPilot.
Right now, UDBLogo is based around the concept of setting up parameters, and then pausing script execution while we fly to a specific location. Then upon reaching the goal, the script resumes executing until we give it another location to fly to. I think that in order to make high and low level commands work well together, we'd need to be able to pause execution not just until reaching a new location, but alternately until other kinds of predicates are satisfied. Maybe allow pausing until we're at a certain altitude, or for a certain amount of time, or until the plane is rolled to a specific target angle, etc...
This way, you could start rolling, fly to a new location while rolling, stop rolling, start looping, fly until you've looped 3 times, then go into knife edge and circle for 1 minute. Or you could deflect the elevator up a bit and circle until reaching a specific altitude, then set the throttle to zero, and glide home.
I think this is all surmountable, but I also think it'll take a lot of work to think through how all the commands of different types should interact, in order to build something usable, fun, and intuitive.
As a side note, I think having a good quick and easy (not XPlane) desktop simulator for this language is important, since it should be easy to quickly test out a script before flying, to make sure it doesn't look like it'll end in disaster.
Ben
Hi Chris,
There is a tool for visualizing LOGO flight plans for the UAV Devboard. For more information, see the UDB LOGO Wiki. UDB LOGO is Ben Levitt's creation, it works rather nicely. I don't think Ben ever intended it for aerobatics.
For aerobatics, the UDB team did some work with the academic community to define a flight description language. I was not involved directly, I am hoping that Peter Hollands or Ben Levitt might comment on that. The idea was to develop a language that could describe at a high level pretty much anything that anyone might ever want to do, and then have a lower level language for execution. There was some really nice architectural work done by the academics, but it was never implemented.
Peter Hollands has done some work on a MavLINK interface for MatrixPilot. It has not yet been completed because there is not enough RAM on the UDB3. When the UDB4 goes into production in a month or 2, I expect that the team will continue work on the MavLINK interface, so that we will finally be able to load flight plans on the fly.
Anyway, I am going to see if I can put Peter or Ben in touch with you to see if you can get any use out of the work that was done on the flight planning language.
Best regards,
Bill
I also think that if you can program harriers on the APM then you are very close to program auto-landing ;) Keep it going!
maybe waypoints would have target attitude or rate, in addition to just location
-
1
-
2
-
3
-
4
of 4 Next