Wind capable ArduPlane and vector field navigator - demo video - Blogs

Michael Pursifull January 26, 2012 at 6:42pm

Justin, I like the work, even if I don't understand it yet. How might I get a copy?

Justin January 26, 2012 at 5:31pm

wow sorry mangle city. I really don't like the ning comment system :(

The effect of this parameter shows up best in loiters where too much gain and the plane loiters inside the circle, too little and it loiters outside the circle. If it is roughly right then sliding mode control does the rest.

(the last paragraph was not mangled)

Justin January 26, 2012 at 5:29pm

(contd) .. rather than lagging a moving target. The effect of this parameter shows up best in loiters: the plant is not being led enough) or loiter inside the circle (it is being led too much). If it is roughly right, t_mode_control does the rest.g/wiki/Slidingg

By the way the navigation does not implement turn anticipation, but that could be easily added. (turn antici to a waypoint such that it rounds the corner on the inside). There are other waypoint options one might wanlity on how to define an approach to a particular waypoint in the list.

Justin January 26, 2012 at 5:14pm

A few answers.
Regarding wind variability. Since this firmware does not guess the wind and then output a fixed compensation it does not matter if the wind is variable. GPS is providing the position 4 to 10 times a second so the reactions to the prevailing wind are limited by that speed, along with the roll response and inertia of the airframe itself. A gusty or variable wind will cause small track deviations that are corrected with a compensating roll back to track as soon they appear in GPS. Of course the more gusty and variable the wind the more the larger the std-deviation of track error on straight segments, but it would do the best it can. Probably better than a human pilot could do.

The better the GPS module the faster the wind corrections would be applied.

Regarding SITL versus HIL. The X-plane HIL simulation outputs attitude-only data to the hardware, no acceleration or rate of change information is provided. The data rates for attitude information and altitude are also slow, much slower than real life where the barometer outputs a continuous altitude and the gyros output their best guess at continuous attitude and roll/pitch/yaw rates are available as well. In addition HIL output GPS coordinates as floats, but in real life (or in SITL) the GPS numbers are in longs at longer precision. The lack of GPS precision and slow altitude update rate in HIL is something that the firmware must step around, because it might be calculating small differences at 50hz.
The lack of acceleration data means the plane is flying with only minimal rudder coordination in turns. X-plane HIL originally had a SENSORS mode but this is currently not working. If SENSORS mode worked *and* the update rate was increased to 50+ hz, then it would be similar to SITL.

The code for flying in HIL is effectively done as a special case. The code for SITL is closest to real life (except there is still one current problem in SITL - with some of the gyro data).

The difference from the current ArduPlane.

Unlike the current ArduPlane which mainly concentrates on aircraft pitch, this firmware calculates angle of attack and flight path angle. If AoA is zero then Pitch == Flight path angle but usually AoA is not zero. Knowing AoA allows for stall protection without arbitrary max/min pitch figures. Flight path angle, which is really just vertical speed, is important for steady state ascents or descents and vital for a landing approach.

I tried to eliminate the PID loop cascade problem. This is not a full physics model there are still disguised PID loops: The aileron response is a dynamic balance between roll error and current roll rate, the elevator is a dynamic balance between the flight path angle error and pitch rate, with an integrator, and a feed-in for the current roll attitude. The throttle is a dynamic balance between air speed error and current acceleration/deceleration. In all these cases the movement of the control (aileron, elevator, rudder, throttle) goes to zero when both the error goes to zero _and_ the currently sensed movement rate reaches zero.

I found this worked well verus treating each system as a black box and asking a PID controller work out what throttle position zeros airspeed error, or what aileron position zeros roll attitude error, or breaking down each problem into two steps, and then chaining two PID controllers together.

To further avoid the cascade problem, and to allow for winds, the navigation vector field is then setup to be kinematically feasible for a less manoeuvrable aircraft. This means even if roll hold is not tuned up, the plane will still follow the vector field for each segment of the flight plan without exceeding max roll attitude, and over-shooting (and oscillating).

A single gain value in the navigation autopilot controls how much to lead the bearing hold autopilot so the plane tends to be where it really wants it to be, rather than lagging a mov

Archangel06 January 26, 2012 at 3:47pm

@Justin

*please* I would love to test the HIL version for APM2 Xplane. thanks.

Moderator

Michael Pursifull January 26, 2012 at 12:35pm

Software-In-The-Loop

His project, unless I misunderstand, is a modified version of the firmware to handle tracking differently, as well as several other modifications/features, which he lists in the original post.

The HiL (hardware in the loop) is used to make development of these features faster and less expensive (when you crash your plane, you don't have to rebuild it, you just reload it...and you can create predicable flight conditions on demand, and not wait three days for the rain and wind to pass)

The SITL is mentioned because of the difference in experience he's had between HiL and SitL. When you are simulating the sensors, pushing the data across your X-Plane, your operating system, in and out of the APM.... these things take time. Time is sensor lag, basically, and can dramatically change the flight experience. That being said, it remains an invaluable tool for development and for training.

Itay Guy January 26, 2012 at 12:28pm

Hi , what is SITL?

and in what this project is different then the one that shows you how to connect the APM to the X-Plane

Moderator

Michael Pursifull January 26, 2012 at 11:12am

One item that has concerned me, between my HiL and real-world flights, is that where I fly, the winds are not 8.75 at 159.8 degrees, but rather they vary from 0-8 knots, average around 4-5, and change direction slightly from second to second (though generally from the same 5-10 degree source.) Maybe I need to fly higher? I am curious about your thoughts on this.

Moderator

Michael Pursifull January 26, 2012 at 11:03am

Justin - would't this look even nicer with a Bixler/EasyStar X-Plane model?

http://diydrones.com/forum/topics/x-plane-arduplane-bixler-easystar...

Justin January 25, 2012 at 11:42pm

For SITL tests right now all I have is an OSX .elf, so unless you are on Mac I can't post that.

I'll post an APM1 and APM2 .hex file shortly, then upload the code so anyone can pull it down and build it.

Comments