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.