Jonathan Challinger

Jonathan Challinger's Friends

  • RoboBill
  • Will
  • Chad Frazer
  • Umer
  • Andrew Tridgell

Jonathan Challinger's Groups

Jonathan Challinger's Discussions

Questions about X8 wing

Started this discussion. Last reply by Jeff Taylor Apr 11, 2012. 8 Replies

I'm writing a proposal for a $2000 summer stipend from my university, for development on an APM UAV.For the project, I'm looking at the X8 wing. However, I foresee a couple issues:Most layouts I see…Continue

Anyone use QGroundControl?

Started this discussion. Last reply by Jonathan Challinger Dec 25, 2011. 2 Replies

I can't get qgroundcontrol to connect. I built it from the v1.0 branch and it is getting data but it isn't displaying anything.Does anyone here use it? I'm trying to ditch mission planner because…Continue

Is there a more active forum or email list to discuss APM?

Started this discussion. Last reply by Jonathan Challinger Dec 21, 2011. 2 Replies

I watch posts on this forum go for days with no responses. Is there a forum or email list with more activity?Especially looking for a developer email list or forum because I'm interested in improving…Continue

Tuning nav pitch airspeed, nav energy/alt, and pitch to throttle

Started this discussion. Last reply by spagoziak Dec 22, 2011. 1 Reply

What's a good strategy to tune these params?I'm having trouble getting it to hold target airspeed (it seems to stay below it), and I can also hear it changing the throttle quite a bit, even though…Continue


Jonathan Challinger's Page

Profile Information

About Me:
Hobbyist from California
Please tell us a bit about your UAV interest
Did robotics for a while, now into RC airplanes and wanted to fuse the 2.

Comment Wall (6 comments)

At 12:02am on July 23, 2011, George Tarrant said…


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.

At 12:58pm on July 25, 2011, George Tarrant said…

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?


At 1:20am on July 26, 2011, George Tarrant said…


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.

At 12:43pm on July 26, 2011, George Tarrant said…


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.

At 2:21pm on July 27, 2011, George Tarrant said…


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.


At 1:37pm on August 1, 2011, George Tarrant said…


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.

You need to be a member of DIY Drones to add comments!

Join DIY Drones


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service