Comment by Archangel06 on January 26, 2012 at 4:47pm

@Justin

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

Comment by Justin on January 26, 2012 at 6: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

Comment by Justin on January 26, 2012 at 6: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.

Comment by Justin on January 26, 2012 at 6: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)

Comment by Michael Pursifull on January 26, 2012 at 7:42pm

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

Comment by Justin on January 26, 2012 at 8:49pm

I don't want to release an image, only to update it 60 minutes later with an improvement. For example later today I'll get the bixler x-plane model I'd like to test it against that.

Hopefully in the next two days I'll post either the firmware images, or the git branch, or both.. sorry for the delay.

Comment by Justin on January 27, 2012 at 12:42am

here is a video of the Bixler X-plane model, which cruises very slowly, in wind with turbulence as well. There is no setting in X-plane for wind from a constantly changing direction but its turbulence setting causes variable wind as well as gusts up and down etc.

http://www.youtube.com/watch?v=UPZWA74z72E

for the middle part of the video I forgot to move the camera and map around to give a more interesting view, sorry, but the last minute shows the landing approach ok.

You can clearly see the constant attitude changes to keep on track.

The turbulence setting of X-plane is quite tough for tiny models, unrealistically bumpy and gusty for a setting of "1".

The autopilot bixler config ran actually on the same settings I had for flying the X-Plane Cessna. I bumped aileron and elevator gains because it is a slow plane, with a lot of stability, and changed the cruise speed and it flew the circuit.

Comment by Justin on January 30, 2012 at 5:28am

UPDATE: Here are a couple of firmware images

one for APM2 hardware and also the Oilpan

the other for APM1

I'm working on my git clone, so anyone wanting SITL or actually to fly this firmware for real has to wait for that to be up

Anyway here are the HIL firmware images:

http://i.dslr.net/vectorfield/firmwares/

and the readme

http://i.dslr.net/vectorfield/firmwares/readme.txt

If have an existing X-plane/HIL setup you should be working in minutes.

Download

Flash the hex file

Connect

Change UAV_PRESET depending on the type of plane you want to fly in HIL.

See readme.txt for details.

That's it. You can experiment with varying wind, the LAND and TAKEOFF commands etc

Comment by Justin on January 31, 2012 at 7:28am

The git clone is available

http://code.google.com/r/justinbeech-navi/source/browse/ArduPlane/?...

As it stands it is setup to build HIL firmware, or JSBSim SITL desktop version (from autotest)

To build actual flying firmware for APM2 (which I do not recommend you do until I've had a flight or three)

you would edit APM_Config.h a little, to define or not define APM_HARDWARE_APM2

and to comment out the XPLANE definition, turn back on logging etc.

the stuff above in readme.txt. on the config values, also applies.

Comment by Recmaster on March 17, 2012 at 11:30am

Hi Justin!

Do u have some positive results with your wind-resistand code testing? 

Comment

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page