John

Thanks for the feedback but can I ask a couple of supplementary questions to do with crosstrack error?

You use a quantity called "target_bearing" - is that relative to the plane "now" and based on GPS co-ordinates? If not, then what?

Your quantity "crosstrack_bearing" How is that calculated? Does it use GPS x,y velocities "now" which are inertial quantities and then perform some sort of transformation to make the bearing relative?

Things will go quiet this weekend because I'm taking a trip.

I'm asking these questions because the sketch I drew out based on my "guess" at what the two variables are suggested that a position bias could be built-in.

Hi Jonathan

Since my last post to you, I've done a bit more research and I found a very brief write-up on "Cross-track error correction" in the APM manual. I think I've reconciled it with the code you sent me but, in doing so, I've come up with more queries.

The key query has to do with your phrase "nav_bearing += constrain (crosstrack_error*g.crosstrack gain..etc....)". According to my book on 'C', "+=" means add to the last value and this seems to be saying that successive values of "nav_bearing" are added together ie. integration. How do you read that? If I'm correct then we do have an integrator in the Xtrack PID. Trouble is, there is also an implicit integrator between nav_bearing and crosstrack_error so that we have a Type 2 loop which will execute undamped simple harmonic motion unless a 'D' term is added. This appears to contradict your observation of the plane flying at a fixed offset from the runway.

Something is not joined up somewhere. Have you had any more thoughts?

Jonathan

Would seem strange to use "+=" and reset when a simple "=" would do.

Anyway, getting back to your original query, now I know the basic error correction algorithm, I'll do some experiments with my simulation and get back to you.

Jonathan

I've updated my mini-UAV simulation to look at your problem.

My simulation incorporates the following PIDs:-

• rudder from y-accelerometer
• aileron from roll
• roll from heading

and I added a proportional heading from Xtrack loop.

This full complement of PIDs drives Xtrack error to zero in the presence of a crosswind.. I then disconnected the rudder from y-accelerometer PID and, low and behold, got a steady Xtrack error although the magnitude of the error was much smaller than you have observed. I think I am confirming that what you have observed is what to expect.

Based on this, I think there are 3 possible ways forward:-

1. it might be possible to adjust the PID gains in the set-up you have to "tighten" the loops. In this connection, I think using throttle as a measure of speed (can't remember where I read that)  is not really on. My plane climbs at 25 deg at 15 m/sec under 12N thrust and dives at 5 deg at 20 m/sec under 0N thrust. There is just no reliable relationship between thrust and speed. You need a speed sensor (why not GPS?) and to use it to schedule PID gains
2. You could implement a rudder from y-accelerometer loop. However, this is quite tricky and requires the accelerometer to be in just the right place (ideally at the airframe centre of percussion which is usually a little forward of the CG)
3. You could add an integral term to the heading from Xtrack loop (making P+I). Since this is "just software" it might be the easiest option.

Hope you find this helpful, but get back if you have further queries.

Jonathan

With respect, I think you are opening up a can of worms by trying to estimate wind speed. (1) there will be wind gusts on top of the steady wind that will add noise in the 0-1 Hz freq band. (2) where the plane is instantaneously pointing depends on airframe dynamics and loops engaged. In my opinion - better to reject the wind as it arrives rather than measure it when it arrives and then try to reject it.

Don't underestimate the "trickiness" of setting up a rudder from y-acceleraometer loop.If the accelerometer is too far back, when you deflect the rudder, initially the accelerometer will read rudder sideforce which will be in one direction and then, as sideslip develops, the accelerometer will read body sideforce in the opposite direction. In control parlance this behaviour is called "non-minimum phase" and it complicates the process of producing a stable loop. Placing the y-accelerometer at the centre of percussion means that it doesn't see the rudder sideforce and only sees the body sideforce which is what you want because it makes things simpler.

Jonathan

Many thanks for your insightful comments - they are very useful.

I'm best-equipped to generate numbers for reasonably conventional aircraft - high-ish aspect ratio wings, reasonably slim fuselage. That said, I can deal with more "novel" airframes but the process will take a bit longer.

The info I would need about the airframe configuration is size/location of all control surfaces, wing size and planform (ideally also airfoil section but not essential) fuselage length and rough cross-section. I figured that most of this info could come from photos supported by info on fuselage length and wing span for scaling purposes. To round off the datapack I would need mass and cg position plus, ideally, inertias but unfortunately getting these may involve application of high school maths in garage experiments. I've often wondered whether aircraft manufacturers could supply a lot of this info but have never asked.

Finally, I'll need to know which loops you want set up and the likely range of flight speeds. Hope this package doesn't intimidate you too much. Let me know if you want to give the process a try.