Happy new year!
I've put together a proof of concept autopilot based on the Lyapunov Vector Field path following stuff documented in various UAV research papers of the last many years. It is here:
http://i.dslr.net/vectorfield/autopilot.html
It is written in javascript can can operate in one of two modes. It is only tested on Chrome.
a) it can fly JSBSim, using a local python connector that you run on your PC (but the web page is still remote). In this mode it uses a websocket to communicate with JSBSim. I use this mode the most as obviously the flight reactions are closer to reality.
b) it can run entirely in the webpage using a very un-aerodynamically correct flight model (I hesitate to even call it that). but at least one can still see how the navigation works without installing JSBSim. In this mode, there is no need for turn coordination, lift is very directly a function of elevator position, there is no stall possible, etc.
The dumb local world aircraft is a sort of Rascal-like UAV, and there is no point trying to select faster speeds or other planes even though there is a drop-down for that.
Wind can be simulated (in both modes). In the JSBSim mode, JSBSim generates the wind. The program modifies the wind speed and direction constantly if you want a "gusty" mode. In local mode, wind just moves the plane around as soon as it leaves the ground. On the ground, wind magically gets turned off lest the plane get pushed sideways etc etc.
It has other features
* A google earth plugin view from the simulated UAV. Press Down arrow in that sub-window to get a straight down ground view, left and right to look over each wing. Etc. If your PC is not fast enough, do not press the 3D button to enable the plugin. Move the plane to UAV to sydney, then plot a course and watch.
* Flight plan entry and editing from takeoff to Landing. Way points can be moved, deleted, or edited (using the right button on the marker). Given the performance of the plane, hit radius rings show goal satisfaction boundaries.
* Landing works in JSBSim, I can put in a pattern with a leg to final etc and if the altitudes are not unrealistic, it will hold wings level glide then flare. Takeoff is done by holding ground track with rudder and wings level till entered altitude AGL is attained.
* You can save and load flight plans (uses browser "localstorage")
* All the various autopilot and navigational goals and targets are viewable and you can drag the plan around in flight, or pause/start. You can also pause and move the plane then go again
* The vector field for any segment can be plotted, and there is also a mode where a click shows the surface from that point to the destination. (The surface is what the navigation autopilot tries to lock into by manipulation of the signal to the heading hold autopilot).
* The navigation autopilot has a critical parameter (Alpha) regarding the underlying heading hold autopilot lag. For fast responsive planes, this goes higher. For slow ponderous planes, this goes lower. At least in testing this number is always "ok" at 1.0, and once tuned for a particular UAV, insensitive to wind & speed variations. There is an easy way to find it, it could even be automated.
* During the simulated flight, when the UAV gets locked onto the surface, a green line shows the rest of that surface. You can vary how aggressive these vector fields go towards tracking.
* There are PID controllers "below" the navigation autopilot, however only the aileron, elevator and rudder are PI loops (the I is there to reveal trims when trims are incorrect or unknown), the rest are straight P (proportional control).
The arc following features, with approach, set entry and exit points, means it is possible to define how a UAV might execute a "corner" of a plan. Should it cut the corner? should it fly over the waypoint and do a wide turn? With a more advanced flight plan editor all this is possible if you match up the likely exit path from one track to the entry of the next. An arc can become a spiral as well: just vary the radius slowly as it is being flown.
The world data for both JSBSim and "local dumb physics" mode is 100hz. This is unrealistic with a GPS at 10hz. However the navigation level autopilot does not need a rate of 100hz, it needs accurate ground position and ground speed matched with current airframe orientation and motion. Therefore one could run the higher level loop at 10hz and the lower level heading/altitude/attitude/speed holds at 100hz, or one could dead reckon the GPS data and run at whatever rate.
I've done some testing with the math, the nice thing about this is that the config values are real world based: set speeds, roll rates, attitudes etc. The remarkable (at least to me) part was when I switched from the JSBSim Rascal, which is a small very powerful (for its size) UAV, to a Cessna 172, without changing any parameters except for V1 rotate speed, cruise speed and maximum desired roll rate, the flying and track following was still satisfactory out of the box, and became perfect when tuning the Alpha value to account for the slower nature of the Cessna control surfaces. Both would track a 200m radius circle in a prevailing or changing wind. All other settings were the same.
In the picture above the fake plane has tracked the curve accurately, then attained the surface to the next goal ("Surface Error: -1.3deg"). with a pronounced sideways attitude due to the wind from the right.
Also shown is that at 100hz, it needs 1800 trig operations per second, and about double that in flops.
The field is the Canberra model aero club.
Comments
I second Andrews idea, it would be extremely cool and help develop the platform if the nav function is a modularized drop-in sort of thing. Being able to try multiple approaches for any particular form of aircraft and/or mission combination would be great! Dang, I gotta get building this year!
Hello Justin,
you are right, this is only a high level guidance algorithm. Actually, I wrote an algorithm based on TVFG (when I am inside the circumference, I put a "mirror" of the vehicle outside to compute the "tangent" point).
I applied it sucessfully in small scale boats, where the slip is zero and the turns are really "instant". But I faced what are you saying with fixed-wing aircrafts, the closer the point, the more difficult to acquire the tangent.
About the sideslip, well, if the vehicle has "high inertias", it should not be neglected in any guidance algorithm.
About the paper, I liked the coverage area section, but in my opinion, an "IF THEN ELSE THEN" is not a "hybrid" or fusion algorithm.
Cheers, and many thanks for sharing your application :P
When they talk about the UAV heading, they do not mean the way it is facing, they always mean the way it is moving. It is up to the autopilot to make sure the plane crabs as required to keep the ground track going in the direction. Then the math keeps working out just fine if you do that.
Wind just requires larger safety margins on plan roll angle lest maximum turn required taps out in a wind, perhaps due to a tail wind for example. Therefore I have not found wind any issue. The more variable the wind, the more the plane points left and right on the track while flying straight along it.
Obviously they write these papers with an eye to the defense department funding, it is all about navigating with obstacle avoidance (read: urban areas), target tracking (read: following a terrorist) and the ways to make things swarm without hitting each other (read: little flying autonomous armies). I keep thinking of the film minority report.
In the case of the TVFG paper above, they present LVFG+TVFG as a combo. Because inside a loiter circle, there is no path to a tangent as you say, so LVFG must be implemented to curl outward.
My simulation is just LVFG, it doesn't matter where the plane is, inside, outside, it will seek the track and attain it. Ok there is just one spot: right bang in the center of the loiter circle. Then there is no solution :). Luckily one just has to move a fraction of an inch and the solution starts.
The small expense of LVFG is that the track to a loiter has a bit of a swirl to it. To make a bee-line, hit a circle on a tangent, then lock into a curve, as TVFG presents is impossible in practice: you cannot go from level wings to 45 degree bank in an instant, and that is what it requires. TVFG is more efficient for a long approach to a loiter, but it is not a perfect solution. You can even just simulate "TVFG+LVFG" by joining a straight track to an arc in a plan: hand over control at intersection point and you have TVFG.
By the way, all the simulations are without perturbations. What would happen if the vehicle goes within the circunference?
I did a similar algorithm that resolves that case, actually the algorithm is very similar and I explained with simpler maths. If you can download from the IEEE, the name is: Path planning combined with Fuzzy control for autonomous ships.
Hello Tero,
In many many research papers, I always wonder why they refer an UAV something that it is NOT clearly an air vehicle (check out the equation 2 u_U). For instance, they add wind but they do not care about the sideslip angle in the control. Obviously, they put the word UAV because is cool :P, and I really hate that xD.
Nevertheless it does not mean that it is not a guidance algorithm, but the kinematics have to be reviewed depending on the vehicle.
the big criticism that paper has for vanilla lfvg do not apply to this implementation as it synthesizes the control signal so that autopilot lag is countered and arc tracking achieved, unlike example figure 5 which shows orbit way outside the arc (which would definitely be a problem).
the rest of the paper seems to be on the advantages for tracking moving targets in wind which I think is military stuff.
Is your implementation only now LVFG not TVFG or combination?
http://seor.gmu.edu/projects/SEOR-Fall09/UCATS/documents/Tangent-pl...
I have added or fixed the following
* you can move the plane while it is flying, you can also move the H home spot
* you can insert a new waypoint by clicking on a segment
* google elevation service is used to get ground elevation for (H)ome, from which the flightplan is relative..
* fixed the keyboard focus issues with the pop-up google earth plugin by turning off keyboard control of the google map
The plan next is to show stats (mean, std-dev) on tracking error after a flight plan is completed.
To test it against a more realistic flight model the JSB connector can be found in a small tar file:
http://i.dslr.net/vectorfield/autopilot.tar
along with a README and a RUNME.csh
I've only run it on OSX, RUNME.csh on windows can just be replaced by inspecting and executing the two python services manually that it does, from a dos prompt.
Needed, on any platform:
* stock python with modules pexpect probably pyserial as well even though it isn't used here
* Tridges ardupilot autotest branch from git as it provides the JSBSim/Flightgear connector modules
* Tridges pymavlink package, I think it is here https://github.com/tridge/pymavlink
* The google mod_pywebsocket python package, it provides a standalone websocket server http://code.google.com/p/pywebsocket/
* jsbsim.. compiled from CVS snapshot, not the official release 1.0
-
1
-
2
of 2 Next