Re: [UDB-dev] Re: Incorporating a sonar and logo related functions for accurate soft landing

[Peter Hollands]

Daniel,

I started down this route a little. I have a maxsonar fitted to my Alpha Axion, and every flight, I have collected telemetry from the Sonar for about 6 months.  The telemetry is recording the sonar 4 times / second.

My C code, for interfacing to the Max Sonar was definitely an initial "quick fix". So I have not shared it more widely.

I think that having a good understanding of the "Transfer Function" of the plane with regard to elevator control is important.

Best wishes, Pete

On Sat, Sep 1, 2012 at 4:14 PM, DB <dber...@gmail.com> wrote:

Greetings.

Just wondering if there's been any initiative along these directions:

1.  adding a sonar sensor e.g.,  SFE's SEN-11309 or RTL-10427; OR a barometric sensor (not sure which is more  accurate)
2.  enhancing logo to include:
       2.1.  sonar detected altitude systems value for conditionals, e.g., IF_LE(ALT_ZNR, 0.5)  m or cm
       2.2.  flare pitch up function to be used in conjunction, e.g.,  PITCH_UP(10)... SET_SPEED(x)... FLAG_ON(F_LAND)
       2.3.  a take-off position (USE_TAKEOFF_POS similar to USE_CURRENT_POS) and take-off angle (USE_TAKEOFF_ANGLE...)

..all for the purpose of enabling real precision landing within logo waypoints (perhaps, eventually MAVLINK).

I'd like to do these myself and can use some help and directions on the roadmap to take on what codes and classes (functions/data/identifiers/variables) are involved..

It'll be a bit of an uphill climb for myself and maybe a bit ambitious as haven't used c for quite a while for the past 20 yrs.. Some design materials on the WIKI might give me a good start, in addition to any directions from the group. 

Best wishes.
Daniel

[DB]

Thanks Pete for response.

 

If you don't mind sharing the code, that would be greatly appreciated as it'll give me some good headstart. Also am curious on what type of connection is recommended as it supports serial, analogue and pwm...

 

Would you also do me the great favor of quickly browsing over and checking SEN-09494 from SFE to see if it suits the purpose.. I'll order it as soon as I get your nod.

 

All the best.

Daniel

[DB]

Pete. Just letting you know that I've already ordered the item from SFE.. Could you just point me to any documentation that focuses on "Transfer Function"?

Best regards. Daniel

[DB]

As prep,  I just want to bounce off my intent to use the latest trunk revision, 1692 as baseline for my development.. Thoughts or concerns?
Kindest regards.
Daniel

[Peter Hollands]

I tested the latest trunk on Friday (yesterday) with 3 flights. With SERIAL_UDB_EXTRA (2 flights), the IMU worked the best that I've ever seen it. The flights were flawless and my plane followed it's fairly conservative flight plan beautifully. So all OK.

I did run a quick test of the SUE over MAVLink in the morning, and that failed. But the reason may have been an OpenLog fault (e.g. baud rate setup). I did not have time to look into it, so reverted to SERIAL_UDB_EXTRA.

My sonar is XL-MaxSonar from the EZ/AE range, and is the MB1230 model( link to datasheet). I currently have interfaced it to channel 7 input, and I measure the PWM values. I had to change the PWM timer mechanisms for channel 7 in order to get sensible values. (PWM values form the sonar have a vastly different range from PWM values for the radio inputs).

You will see that ranging of the device goes from around 0.2m (minimum) to about 7.5 meters (maximum) in ideal conditions.
The update rate is stated as being at around 10Hz.  I already know that the data is not always clean. There can be anomolies. So some filtering will be required of the incoming data.

I already to hard landings automatically, just by letting my plane come down a glide slope. So my objective was simply for the plane to detect the ground at the end, and try to stay say at around 0.7 meters above the ground for the final glide, while drag of the plane slows it down, eventually the plane will stall, gently onto the ground. I have no wheels, so my plane then stops within 1 second. (A small light foamy at the moment).

I can the following challenges:-

• Clean data from the ultrasound
• revise range data to account for bank and roll (fairly easy) (i.e. determine vertical range to ground).
• The system, with no "look ahead", is only really suitable for flat landing fields.
  
• Feedforward control, understanding the characterstics of the plane close to stall, along with drag characterstics, may be vital.
• Good landing may require a good understanding of the "transfer function" of the plane for pitch control, but since we are operating close to the stall, the mathematical model may be invalid.

More on transfer functions later.

Best wishes, Pete

[Peter Hollands]

Daniel,

I enclose the patch that I made to my version of trunk, in one evening in April 2012, for collecting Sonar information.
I have to say that it was a quick patch, and a rough piece of coding, and it is certainly not code for general release.
It was an initial quick experiment. I have left that code in my version of trunk, and so I can verify that it has been safe to use in practice as I have flown with it since April.

For the UDB4, I am using a spare timer, Timer 3, with different settings, to measure the PWM pulse from the Sonar, on channel 7, which I do not generally use for anything else. It's hard coded, and not setup for any changes in options.h .

I enclose the patch file for your interest. I'm not sure if you familiar with patch files, and the use of Tortoise Subversion ? If you want any help with applying the patch and using Tortoise SVN, then please let me know.

Best wishes, Pete

[DB]

Pete.
Thanks very much for sharing the patch. Just quickly looking at it (SVN), it'll definitely give me a jump start...

I had a chance to do some flying yesterday and this afternoon comparing the latest 1692 with 1667, the one I've been using and found very stable/predictable. Probably trivial but I'll be rolling back to 1667 as my baseline, based on some flight observations and some compile errors with 1692 particularly with it's UDB4 OSD flash..

To speed things up a bit, I also managed to reverse engineer the rev1667 into class models (with some bi-directional RAD tools I used to use) just to have some initial understanding of what might be in scope of the new functions related to the use of the sonar sensor.. I'll  keep you posted continuous advice and feedback.

...really appreciate the help.
All the best.
Daniel

[Peter Hollands]

Daniel,

Sounds like you are all setup to make changes.

BTW: Between 1667 and 1692 there is only one change to trunk. That is the addition of CRC (Cyclic Redundancy Checks) to messages arriving from the EM406A GPS.

All the other changes are to MatrixPilot_Quad, MatrixPilot_fbw (Fly By Wire), and MatrixPilot_NMEA (A special branch for testing Guilio's NMEA GPS parser).

Best wishes, Pete

[DB]

It's good to know about the delta bet. 1667 and 1692.. Thanks Pete.  

 

This prompted me to further look into the compile error and as it turn out, was really my bad and was caused by def. device selection (dspic30..1411) that needed to be changed to dspic33--710A.. Any rate, I'm switching back to 1692 as base line as pointed out, support new GPS enhancements.

 

Kindest regards.

Daniel

[Peter Hollands]

Daniel,

I can see that we still need to establish, from experiments, that the Sonar will provide a sufficiently reliable indication of height.

It seems to me that there are a number of challenges ahead on the Sonar Landing Flare feature:-

• Ensure we have frequent and accurate trustworthy data from the Sonar Height Above Ground sensor.
• We may need an "observer" style Kalman Filter, in order to get quality data.
• Raw data is only fed 10 times / second from Sonar.
• At 10.0 m/s and 20 degree pitch down, the plane is descending at least at 3.4 m/s. If the beam is working at up to 7 meters from ground, then that provides a valid return from 7.0 * cos(20), which is 6.5 meters above ground. In other words, the flare must occur within about 1 second of flight, in order to flare safely, 1 second before hitting the ground ! Not much room for an error margin. Of course those figures improve if the intial descent rate is less thatn 20 degrees.
• The entire concept of downward looking Sonar implies the landing site is flat, or gently sloping. Sudden changes in slope will not be detected in time.
  
• We probably need our plane's to be optimally set up for control of height by the AutoPilot. The best way to do that, is to learn how Bill has extracted the control Transfer Functions for Pitch and Roll from his Quad, and apply that type of technology to pitch control, and height control of the plane. Then, with transfer function in hand, we can model the entire flare control algorithm in a mathematical simulator like the Open Source Xcos (similar to Simulink for MatLab).
• Only once we have successfully modelled the landing in Xcos, with typical noise to the Sonar, would I really want to embark on coding up the solution. I enclose a sample (made up), options.h entry for Sonar Flare and Landing.

////////////////////////////////////////////////////////////////////////////////
// MAXBOTIX SONAR TERRAIN FOLLOWING AND LANDING FLARE
// Designed for use with the following device:-
// http://www.maxbotix.com/Ultrasonic_Sensors/MB1230.htm
// Can be used on INPUT 8 of the UDB4 if that is not used for other purposes.
// Will compensate for roll / pitch, subject to receiving a returned sonar signal.
//
// This option is for UDB4 only
// Height is returned 4 times / second in centimers in SERIAL_UDB_EXTRA PWM channel 8.
//

// NOTE: Requires Auto Pitch PID adjustment to be enabled.
// Auto Pitch PID will auto adjust your plane for the best possible PID control of height.

#define AUTO_ADJUST_PITCH_PID                    1

// SONAR_STABILIZED_TERRAIN_FOLLOWING
// In stabilized mode, the plane will attempt to stay above a minimum sonar height from ground
// using Throttle and Pitch. If Throttle is cut to zero, the plane will glide in.
#define SONAR_STABILIZED_TERRAIN_FOLLOWING         1
#define SONAR_STABILIZED_MINIMUM_HEIGHT            2.0  // Meters. Minimum 1.0, Maximum 6.0

// SONAR LANDING FLARE
#define SONAR_LANDING_FLARE             0
#define SONAR_FLARE_DESCENT_RATE        0.3    // Meters / Second. 0.3 is default value.
#define SONAR_FLARE_START_HEIGHT        4.0 // Meters. Minimum 1.0, Maximum 6.0. Start High !

Best wishes, Pete

[Peter Hollands]

I spent some time this afternoon, trying to work out the mathematics and trigonometery to allow for the angle of roll and pitch of the aircraft to adjust the sonar distance to object into a height above ground of the plane.

I took the dot product of the Z axis of Rmat (rmat6,rmat7,rmat 8 ) with the Z axis (RMAX, 0, 0) to get the cosine of the angle subtended between vertical and the vector of the path of the sonar beam with reference to the earth axis. I think I got that right.

For anyone following this I welcome any comments on the code below.

Best wishes, Pete

#elif ( SERIAL_OUTPUT_FORMAT == SERIAL_SONAR )

extern int udb_pwm_sonar ;
#define UDB_SONAR_PWM_UNITS_TO_CENTIMETERS     4451  // 64536.0 / 14.5
fractional z_vector[] = {0 , 0 , RMAX} ;
fractional cos_pitch_roll ;


void serial_output_8hz( void )
{
    union longbbbb accum ;
    int sonar_distance ; // distance to object regardless of orientation
    int sonar_height_to_ground ; // distance to object in Earth's Z Plane
    accum.WW = __builtin_mulss( udb_pwm_sonar, UDB_SONAR_PWM_UNITS_TO_CENTIMETERS ) + 32768 ;
    sonar_distance = accum._.W1 ;
    serial_output("S%i\r\n", sonar_distance) ;
   
    cos_pitch_roll = VectorDotProduct( 3 , &rmat[6] , z_vector )<<1    ;
    if ( cos_pitch_roll > 16383 )
    {
        cos_pitch_roll = 16383 ;
    }
    serial_output("C%i\r\n", cos_pitch_roll) ;

    cos_pitch_roll = cos_pitch_roll << 1 ;
    accum.WW = __builtin_mulss(cos_pitch_roll, sonar_distance) ;
    sonar_height_to_ground = accum._.W1 << 1 ;
    serial_output("H%i\r\n", sonar_height_to_ground) ;
    return ;
}

[William Premerlani]

Hi Peter,

I am glad to see that you found yet another good use for the elements of the direction cosine matrix.

Your math is correct.

However, you could make the implementation a bit more efficient, since rmat[8] itself is the cosine of roll-pitch.

You can easily see that is the case, because the dot product of the vector starting at rmat[6] with your z_vector,  { 0 , 0 , RMAX } , is just going to pick out rmat[8]. So, there is no need to do the dot product. All you have to do to correct for roll-pitch is multiply the measured sonar distance by rmat[8].

Best regards,

Bill

[William Premerlani]

Peter,

One more way to look at it....rmat[8] is the dot product of the earth Z axis with the aircraft Z axis, so it is exactly what is needed to project a Z sonar measurement in the aircraft frame into Z value in the earth frame.

Best regards,

Bill

[William Premerlani]

Hi Peter,

One more thing...your math is sound, but I think it is based on an implicit assumptions you have made about the sonar device, and I think your assumption is only an approximation.

Your implicit assumption is that the sonar beam has zero beam width. But actually, the beam has quite a bit of spread. So, some energy goes straight down, bounces back up, and is detected, even when the aircraft is tilted.

There is some signal processing going on inside the sonar devices that will determine how the device responds to a horizontal surface while tilted. I would suppose that the designers might try to determine the shortest distance between the sensor and any object in its path, in which case no adjustments would be needed.

Personally, I have not dug into this subject, so I cannot tell you what the actual off-axis sensitivity curves look like for sonar range devices. You probably should take a look at the plots published by the manufacturer to see what the calibration versus tilt is. You might want to take a look at the discussions on the Ardu sites, I think those guys have been digging into this.

My guess is that there is a calibration plot that is a function of tilt, where tilt is the square root of the sum of the squares of rmat[6] and rmat[7].

Good luck to you.

Best regards,

Bill Premerlani

[Peter Hollands]

Hi Bill,

Thanks very much for the comments.

Yes, now you mention it, the dot product arithmetic is obvious, and all I need is Rmat 8.

I shall look into the beam aspects in more detail later.

I shall do some more flight tests now, to see if the sonar device works well on my local flying field.

Best wishes, Pete

[Peter Hollands]

Folks,

I enclose a spreadsheet and picture with the Sonar data from a test run today.
I simply was collecting data on how good the sonar is when flying close to the ground.

In general, the Sonar is marketed as having a range of 7.5 meters maximum. In practice, in my flight, over
a cut straw field (recently harvested; stubble 6 inches in length), shows that the Sonar is useful from around 18cm to
400 cm (4 meters) above the ground.

The product that I'm using is at this location.

The Sonar is embedded in the bottom of the right wing of my Alpha Axion 3 inches to the right of the fuselage.
In this position it hopefully does not get soiled on landing.

Best wishes, Pete

[Peter Hollands]

In my previous post, I missed the link to the Sonar product.

The product that I'm using is at this location.

Best wishes, Pete

[William Premerlani]

Hi Peter,

Very nice research on your part.

To what do you attribute the "roller coaster" effect?

The data looks pretty good over a certain range, but there could be some problems unless the sonar is ignored outside that range, particularly for example that one outlier as you landed. I suppose we could use GPS information to decide when the sonar is in a valid range.

Best regards,

Bill

[Peter Hollands]

Hi Bill,

You wrote:- "To what do you attribute the "roller coaster" effect?"
Are you impuning my piloting skills 
In the jpeg screenshot of the detail of the sonar for landing, the oscillations are induced by me.

I think that this Sonar device is on the borderline of being useful. i.e. it may not be.

An ideal ground detection device would overlap the GPS altitude error. To my mind GPS altitude error can be as bad as +/-30m. So Ideally ground detection would start to work at 60m of altitude. (e.g. LIDAR).

The Sonar on my plane seem absolutely reliable in flight (not on landing), for any measurement between 18cm and 250cm. Any such measurement in my data is true data. i.e. from 2.5 meters downwards.

If I assume a descent angle of 20 degrees for coming into landing, the plane is effectively flying blind down to 2.5m (because the GPS is not accurate). For a plane flying at 10m/s, the descent rate is 10*sin(20) which is 3.42 meters / second downwards. But we can only be sure of ground distance with the sonar at 2.5 meters. So we have less than 1 second to flare before hitting the ground. Which is too little.

In my own landing area, I would actually like to get to a point, where I can descend at 45 degrees (flaps, airbrakes, etc), and still do an auto-landing. So my conclusion really is that we need another device. The 7.5 meter range of that Sonar is really 2.5 meters in my experience.

Best wishes, Pete

[William Premerlani]

Hi Peter,

I agree with you, that sonar device is borderline useful. Certainly, the sonar range will have to be larger than the GPS error for it to be of any use.

That said, in those cases in which sonar is useful, I think it would be possible to do some clever fusing of sonar with dead-reckoning for the final landing.

Best regards,

Bill

[William Premerlani]

Peter,

I have never impugned your piloting skills. I was just wondering if the variations were related to tilt. It would be useful to see tilt (square root of sum of squares of rmat[6] and rmat[7]) on the same plot.

Best regards,

Bill

[Peter Hollands]

Folks,

To complete the record of this thread, I enclose a patch as a sample of how I did the sonar tests over the past couple of days.

Bill, I'm out of time for now to do the tilt plot. The cosine of the tilt is already in the second column of the spreadsheet. It is multiplied by 2. So instead of 16384, you will see 32768 when the tilt angle is zero. The third colum is the calculated height, allowing for tilt, in centimeters.

I'm back into my day job again for a while, so this project will be on hold for a while.

Best wishes, Pete

[DB]

Hi Pete, Bill.

 

Many thanks for the additional valuable insights, knowledge and sharing the patch. 

 

Sorry if I've not responded sooner, however, I'm still waiting for the sonar sensor shipment's arrival and its been almost 2 week since I ordered it..

 

I can't thank you, guys enough for the resources that you've taken the time to share. The more I get deeper into the MP system, the more I appreciate the high caliber expertice and dedication that the team have vested into this "project" - an understatement.. this is like a career pursuit in itself..

 

Faced with my lack of understanding and the complexity of the possible scope, my intent is to start with (hopefuly simple enough for me to feasibly begin with) baby steps by narrowing down the options to some intial-sandbox phase scope of functionalities:

  1.  with your patch, getting the sonar successfully working with it's data feed, and with some other data enhance its effectiveness, as suggested, to include tilt mgt. w/rmats, filtering of spikes, extapolation for a smoother averaged descend curves and some kind of projection curve to manage systems latency...

  2.  making the resultant altitude product data, available to the LOGO as added systems value to work with LOGO functions enhancements, such as PITCH/FLARE~, ROLL~ and THROTTLE/THRUST~ to work with conditionals, to try manage the dynamics of the final 7~4 to 0 m altitude descend of the landing

  3.  to include in LOGO, if possible, systems values such as TAKEOFF_POINT and TAKEOFF_ANGLE as point of reference for the LOGO program's final approach's geographic accuracy.

 

Also, I've simplified my test beds-planes to a "neutral" and stable airframe,  a Breeze box  (my moniker of the Deamon 2000, see attached image for aerodynamic characteristics estimates), that I found very neutral and stable with almost pattern plane like precision, sans, aerobatic capabilities. Downside is fragility as it has a fiberglass fuse.

 

In progress: In addition to reverse engineering the MP system into smart class models, on the practical side, I've managed to do a couple of flights a few days back, about 4 or 5, with repeated perfectly soft landings (see attached images)  analyzed for relevant patterns that I hope to "mimic" with the planned "sandbox" phase, scope of functionalities. 

 

Bill, would be much appreciated if you can possibly point me to the codes and any material that may lend me some good start on the "transfer function" subject area.

 

Pete, really appreciate very much everything. All the best on your day job.

 

Best regards.

Daniel

[DB]

Hi Pete, greetings all.

 

If you happen to glance at this post, here are some developments:

 

- Finally got the MaxSonar (same as Pete's, yesterday)  and in the process of wiring it.

   ...will soon try some flights as soon as the weather clears up, and replicate the results

   just for my own hands-on exposure/learning..

 

- got your patch incorporated and compiled and will go from here. Thanks again as this

  also helped me understand the codes' organization/decoupling..

 

- also have started sorting through the c and h's accross libUDB and MatrixPilot packages

   or libraries to get an idea of the gap: scope of code changes for the planned LOGO

   enhancements (use of sonar data for managing a fairly soft auto-landing approach). 

 

I'll soon post a nutshell scope/design for your feed back, recommendations and caveats.

 

Further, ..would certainly appreciate much needed help on:

 

-  Ben if you can just favor me with your thoughts on what might be involved for my planned 

   sonar-LOGO enhancements, esp. the c and h's scope.

 

-  Bill if you can just share anything on the "Transfer Function" as suggested by Pete.

 

With much appreciation, kindest regards.

Daniel

 

 

On Saturday, September 1, 2012 12:17:06 PM UTC-4, Pete wrote:

[William Premerlani]

Hi Dan,

Regarding the "elevator transfer function" that Peter mentioned, I am not sure what he means. If we could get him to clarify, I probably could give you some suggestions. Two possibilities come to mind:

1. Peter is referring to the role that the elevator plays in pitch/altitude/speed control. Basically, the dynamic model of the plane.

2. Peter is referring to the role that pitch plays in the response of the sonar.

By the way, with respect to the first item, the approach that I use in MatrixPilot for the "LAND" option is to use the target glide-slope line as a ceiling. When the plane is below the line, it elevator control is used to keep the plane level. When the plane is above the line, the elevator control is used to pitch down to descend to the glide slope. It works well enough without sonar, with sonar it might work quite nicely.

Bill

[Peter Hollands]

Hi Bill, Daniel

"Transfer Functions":  On further thought this may / may not be relevant to this discussion.

Here is my line of thinking:-

• Sonar only works over a limited range in my field (18cm to 400cm (4 meters or about 12 feet).
• Sonar only updates at 10Hz and some filtering may be required
• Hypothesis - We will need optimal height control to achieve a good landing. How can we do that ?
• Determine the mathematical function that describes pitch control of the aircraft (manual mode).
  
• Can we use Bill's techniques to determine the transfer function from telemetry ?
  
• Create a transfer function that describes the response of the auto-pilot.
• Put both transfer functions in to block diagram control model in Xcos to simulate the control system. (Xcos is opensource code that has some of the functionality of simulink. Xcos is part of Scilab. Scilab is open source softwarer with some of the funcitonality of Matlab (free but less capable).
• Use Xcos to optimise the PID's for pitch control and potentially throttle control.
  
• Potential flaws in the above bullet point ....
• Height Control requires both Throttle and pitch control. It is not SISO (Single Input, Single Output).  Throttle control is actually relatively slow to respond. Feed forward is important for precision
  
• Transfer functions require LTI (Linear Time Invariant) functions. The equations describing flight near a stall are probably not linear.
• We are probably more concerned with Descent Rate than Height Control in the final moments of landing. And that is what your "glide slop" solution already does. It may be that we simply want to change the glide slope when we arrive at 4 meter above the ground - and arrange for the plane to have a high drag ration at this time, so that it quickly loses speed, loses speed and meets the ground. The test plane should have  forgiving stall characteristics initially.  [KISS (Keep It Simple Stupid).]

So really, all we need for that would be:-

• Sanity Check the Sonar data during phase 1 glide descent. Keep the glide slope at less than 20 degrees so the rate of descent is not to quick.
  
• Spot the 4 meter mark above the ground reliable during phase 1 glide descent.
• Change the glide angle within 1/2 a second to be say 0 degrees, so that the plane is now gliding at 2 meters above the ground. With high drag, and forigiving stall, it should land.  You still need to be sure that pitch control is Optimal to achieve a 15 degree pitch change within at least 1/2 a second. So may be all the transfer function work will still be useful.
  

Best wishes, Pete

[ben levitt]

All it takes to make a MatrixPilot variable accessible from logo is to
add its name into the enum at the top of flightplan-logo.c, and then
add a case: for that value into logo_value_for_identifier(). See this
svn revision that added 2 values. (And ignore the switch from using
#defines to using an enum.)

http://code.google.com/p/gentlenav/source/detail?r=1558

Ben

[Peter Hollands]

Thanks Ben, that is helpful and timely.

Pete

[Peter Hollands]

OK here is my plan for flights tomorrow.

I enclose a patch for altitudeCntrl.c and telemetry.c, which should ensure that I get only good data from the sonar at my landing field.  I reject any sonar values above 4 meters. And I only accept values below 4 meters if there are at least 3 consecutive reading below 4 meters. From analysis of my previously captured samples, that should be fine. I shall do some flights tomorrow and analyze the telemetry to make sure that it is correct and that I only get good and valid sonar for height above ground.

Then ....
I hope to add the variable "sonar_height_to_ground" (an integer - see enclose patch ) into Logo.

Then ...
I shall go and re-use the DIY competition winning automatic take off and landing Logo scripts from last November.
During the landing glide of the Logo script, I shall set up an "Interrupt for final glide" using Ben's new Interrupt feature in Logo. The Interrupt will be triggered by sonar_height_to_ground being less than 4 meters. The Interrupt subroutine will then set a new waypoint, about 100 meters down the field, which is at the same height as the plane. So the plane will attempt to glide horizontally, with no glide slope. It will slow down, and in my case, my plane should gracefully stall / land.

Stay tuned ....

Best wishes, Pete

[William Premerlani]

Hi Peter and Daniel,

My suggestion is to not use sonar directly for any sort of control. Rather I suggest using it as an additional input to the dead-reckoning algorithm to improve accuracy. The dead-reckoning algorithm is running at 40 Hz, and is already being used for navigation and altitude/speed control, so I think the best bet is to simply leave the controls as is, and improve the accuracy of dead-reckoning.

Best regards,

Bill

[Peter Hollands]

Bill,

Thanks for making me re-consider.

I agree that updating the DR positiong is the pure and neat generic algorithm to use. But I think with current sonar we are boxed into a different solution. e.g. For Lidar, I think we can look at updating the DR.

With Maxbotix sonar the limitations are:-

•  there is not enough flight time / sonar range to effect a smooth alteration of the dead reckoning position, when effecting a landing flare.
• The relationship between Sonar height above ground, to GPS Height, requires an on board terrain altitude map.
  (or at least a model which could be that the ground is flat, has altitude H in a given defined rectangle of LAT,Long.).

In effect the algorithm that I plane to use today says "If you are landing, do not plough straight into the ground. When you see the ground, pitch up a little and glide".

The sonar range is only 4 meters. The GPS and therefore the dead reckoning can be out by up to + / - 30 meters. Even at + / 10 meters it is hard to see how we could smoothly change the dead reckoning position once we have sonar.

Lets take some numbers and assume that we landing near the Origin, and true ground altitude is origin altitude:-
Time: T=-3 seconds, Real Height of Plane:10meters, GPS: 20 meters, Sonar: Out of Range, DR 20 meters
Time: T=-2 seconds, Real Height of Plane: 7 meters, GPS: 17 meters, Sonar: Out of Range, DR 17 meters
Time: T=-1 seconds, Real Height of Plane: 4 meters, GPS:  14 meters, Sonar: 4 meters.    , DR  ???? Start to change ?
Time to Flare the plane immediately
We will not want to instantly change the DR as a very sudden change will cause an overshoot in the controls.
A gradual change is required to dead reckoning.. But then we will hit the ground.
Time T=0 seconds. Plane has to be flared and about to land. Airspeed bleeding off. Plane flying horizontally.

Best wishes, Pete

[DB]

Hi Pete.

 

What’s Lidar?

 

Hope you won't get tired of my dumb questions and requests.

 

Bill, from another viewpoint, the use of sonar in a LOGO control way can provide for a quick and easy testing opportunity  ..through the landing scenarios, like Pete mentioned,  with real-world results, e.g., probing the sonar device’s data feed integrity and consistency,  the different approaches to best effect consistently soft  auto-landing during its demanding stages, and so on. Thereafter,  the component can be added to the DR algorithm as suggested, as well as in whatever alternative uses discovered during the testing.

 

Pete, you’ve got me holding my breath now. I’m also trying to rush my glider (adding the sonar sensor) for tomorrow,  hoping for a favorable weather.

 

Progress: So far, I’ve applied the patches across all the codes down to my LOGO flight plan, incl. Ben’s suggestions. Everything compiled smoothly and looks promisingly good.  As bonus this has helped me gain a bit more understanding of the structure of MP and how to go about adding simple enhancements. Thanks for the opportunity.

 

BTW, the scope model as promised is attached. Side note: It’s largely UML nomenclature based and it’s a “smart” model with drill down to code detail  and bi-directional synch.  Not as powerful as Scilab’s but this helps me quickly simplify things to a high level of abstraction, understand the big picture without losing sight of the critical details (in keeping with KISS;o).

 

Happy flying and have a great weekend.

 

All the best.

[Peter Hollands]

Daniel

From Wikipedia:-

LIDAR (Light Detection And Ranging, also LADAR) is an optical remote sensing technology that can measure the distance to, or other properties of a target by illuminating the target with light, often using pulses from a laser.

It seems to be too epensive or too large for our use at the moment.

Best wishes, Pete

[Peter Hollands]

Daniel

There is a  bug in my latest patch which I will fix later today.
The bug does not effect flight worthiness. It is still safe to fly.
But it does mean that the code does not wait for 3 complete and good samples
before recognising and passing through the good samples the main sonar ground height variable.

The PWM code for the Sonar should be receiving new PWM updates at 10Hz (as specd by Maxbotix). (I have not verified that directly). That code is in radio_in_udb4.c and is running at a high interrupt priority of 6. So I do as little as possible to just capture the value of the PWM sonar timer and store it away. I need to let that code return from interrupt, so all the other high value priority interrupts ( radio transmitter channel inputs), remain unaffected and non-blocked.

The altitudeCntrl.c code is running at 40Hz. That is where I turn a PWM UDB timer value into centimeter to target.
I do the addional work in this thread of code, to keep the PWM input in radio_in_udb4.c to a minimum. The altitude control code is running as part of the main stack of code that is controlling the plane. See here for the call out to the main routines.

But at the moment there is not link or flag between the radio_in_udb code and the altitude_control code, to say that a new and different sonar reading has just been read. I shall fix that this morning and run another flight test.

FYI: The interrupt table, interrupt frequencies, and their priorities are recorded in this document, accessible via this page on the Wiki.

Best wishes, Pete

[Peter Hollands]

Daniel,

I fixed the bug. And then flight tested, and verified that the logic is working correctly. I am now getting a good signal from the sonar when and only when the ground is less than 4 meters away. This is true for my airfield which is a freshly cut barley field with straw stubble sticking up 6 inches from a muddy field. The ground is dry.

Its the weekend, and I am probably 5-8 hours hours ahead of you in timezone. I wanted you be able to access my code in case you also have time experiment today / tomorrow.
I have now created a branch for MatrixPilot_sonar and it is now at the point where it has (theoretically) got Logo support.

I have not yet written or tried any Logo automated landings.

The basic idea it to interrupt a normal F_LAND sequence when the ( SONAR_HEIGHT < 400 cm ) at which point the flightplan should make a note of the current position, and create a waypoint about say 100m further on at the same height and proceed there with F_LAND still enabled. If that further waypoint is reached, I planned to program in a "Go Around" flight plan, as in my case the plane will be running out of airfield to land.

Best wishes, Pete

[Peter Hollands]

Wish me luck ....

Best wishes, Pete

// Simple Example of using LOGO to fly an OVAL pattern and try to land, but
// go around again, when sonar detects ground 4 meters away. Untested !

#define RIGHT_180            1
#define GO_AROUND            2

const struct logoInstructionDef instructions[] = {
SET_ALT(20)                    // Set Altitude at 20m
FD(100)
REPEAT_FOREVER                    // Embark on a an oval shape. Forward 100m
    DO(RIGHT_180)                // Turn around by 180 degrees of a circle
    FD(100)                      // Go back 100m
    DO(RIGHT_180)                // Do another graceful 180 degrees of a circle to finish Oval.
    FLAG_ON(F_LAND)             // Engine Off, and don't ever go up
    SET_INTERRUPT(GO_AROUND)    // Standby with the interrupt routine, to go around when ground detected
    SET_ALT(-32)                   // In the mean time set altitude 32m under ground and
    FD(100)                        // Aim for that point 100 meters away.
    CLEAR_INTERRUPT                // If you get to that point (you should not), forget the go around, repeat this plan.
    END
END

TO (RIGHT_180)                // A subroutine for executing a nice 180 degree turn around a circle
    REPEAT(18)                // Do this 18 times (turning 10 degrees for 180 degrees)
        FD(10)                // Go forward 10 m
        RT(10)                // Right Turn 10 m
    END
END

TO (GO_AROUND)                    // Interrupt routine for Going Around
    IF_LT(SONAR_HEIGHT, 400)      // If ground is less than 400 centimeter (4 meters away)
        FLAG_OFF(F_LAND)          // Switch the motor back on.
        SET_ALT(20)               // Set desire altitude to be 20m above ground level
    END                           
END

} ;

[Peter Hollands]

Daniel,

The basic mechanisms are working after doing 1 test flight. The Sonar worked correctly and detected the ground. The Interrupt Subroutine of Logo was immediately then run. Unfortunately I then reached my end waypoint anyway, and also I was about to hit trees in my landing area. So I could not let my plane go around and around testing itself. I will need to find another test site, for this low level work which does not have trees in the middle of the airfield.

I'm done for this weekend. Everything that I have done is now in the sonar_branch repository, including my flight plan.
You may want to review the change log.

I've added some additional test sonar telemetry to the end of SERIAL_UDB_EXTRA, so that I have everything to analyze in one file for these test runs. That probably requires the 57600 telemetry baud rate (that I've been using) for the system not to lose characters when sending to the OpenLog. 57600 baud operations require OpenLog to be using the 3.x firmware not the old 2.x firmware which did not support 57600 baud rates correctly.

Best wishes and happy flying, Pete

[MIG-29]

Hello,

What do you think about actually integrating a homemade radio
altimeter instead of using the sonar?

We could go to something along the lines: http://lea.hamradio.si/~s53mv/avnr/adesign.html

This would give a much better altitude reference than the sonar and at
way longer ranges...

Best regards!

> >>> 1.  adding a sonar sensor e.g.,  SFE's SEN-11309 or RTL-10427<https://www.sparkfun.com/products/10427>;

> >>> OR a barometric sensor (not sure which is more  accurate)
> >>> 2.  enhancing logo to include:
> >>>        2.1.  sonar detected altitude systems value for conditionals,
> >>> e.g., IF_LE(ALT_ZNR, 0.5)  m or cm
> >>>        2.2.  flare pitch up function to be used in conjunction, e.g.,
> >>> PITCH_UP(10)... SET_SPEED(x)... FLAG_ON(F_LAND)
> >>>        2.3.  a take-off position (USE_TAKEOFF_POS similar to
> >>> USE_CURRENT_POS) and take-off angle (USE_TAKEOFF_ANGLE...)
>
> >>> ..all for the purpose of enabling real precision landing within logo
> >>> waypoints (perhaps, eventually MAVLINK).
>
> >>> I'd like to do these myself and can use some help and directions on the

> >>> roadmap to take on what codes and classes (functions/data/identifiers/**variables)

> >>> are involved..
>
> >>> It'll be a bit of an uphill climb for myself and maybe a bit ambitious
> >>> as haven't used c for quite a while for the past 20 yrs.. Some design
> >>> materials on the WIKI might give me a good start, in addition to any
> >>> directions from the group.
>
> >>> Best wishes.
> >>> Daniel
>

> >>>  <http://www.sparkfun.com/static/rohs/>

[DB]

Hi Pete.

 

Glad to hear about your one test flight... sounds fantastic, very promising and encouraging.  Congrats!

 

Here in our area, weather has been too windy with occassional rains, past 2 days. So I'm still hoping for the weather to settle down a bit.

 

Again, many thanks for sharing so much and so generously. 

 

In between my typical weekend family matters, I had some chance to fully apply the patches, upgrad to r1711 (I think this is the baseline I'll be using) work out minor fix to a compile error with

propagation of the condition #if ( USE_SONAR_ON_PWM_INPUT_8 == 1 )~~ in telemetry.c, radio_in.c etc., FYI the compile error occurs whenever the USE_SONAR_ON_PWM_INPUT_8 is set to 0. 

 

After which, I also did some ground pre-flight and by all indication, everything is set to go!

 

FYI and for your comments,  the LOGO flightplan. auto-land excerpts I intent to test is as ff.:

~~

   IF_LT(LOGO_B_CHANNEL,3100)   //3100 do wider circles 2 x and then AUTOLAND

~~~

    DO_ARG(CM_AUTOLAND,200) 

   ~~

 

~~

 

 TO (CM_AUTOLAND)       // Landing final approach

  FLAG_ON(F_ALTITUDE_GOAL)

  IF_LT_PARAM(190)         //  190m is minimum landing strip length

   PARAM_SET(190)

  END

  FLAG_ON(F_LAND)

  PEN_UP

   USE_CURRENT_POS         // aim for the current flightplan x,y position target, SHOULD/WILL BE REPLACED BY TAKE_OFF_POS

   USE_ANGLE_TO_GOAL       // aim for the current flightplan angle target, SHOULD/WILL BE REPLACED BY TAKE_OFF_ANGLE

   //USE_CURRENT_ANGLE

   BK_PARAM           // use parm to move back from target position as routine's landing span limit

   PARAM_DIV(8)

   PARAM_SUB(5)

   SET_ALT_PARAM      // At 200 param, this is 20 m alt

   FLAG_ON(F_LAND)

   PARAM_DIV(2) 

   PARAM_SUB(2)      // At 200 param, this is 8 m alt DOWN

   ALT_DOWN_PARAM

   PARAM_MUL(8)      // At 200 param, this forward by 64 m

   FD_PARAM

   PARAM_DIV(6)

   PARAM_SUB(3)      // At 200 param, this is 8 m alt DOWN

   ALT_DOWN_PARAM

   PARAM_MUL(8)      // At 200 param, this forward by 64 m

   FD_PARAM

  PEN_DOWN

  IF_LT(ALT_SNR, 400)       // After 128 m distance and cont. descend, check altitude using sonar data and if less than 4m

   FLAG_OFF(F_LAND)      //     throttle up for some flare trajectory to moderate descend,

   SET_ALT(5)        //      SHOULD/WILL BE REPLACED BY PITCH_UP/DOWN_(X ANGLE)

  END

  FLAG_ON(F_LAND)       // Throttle off and continue powerless glide, SHOULD/WILL BE REPLACED BY THROTTLE_UP/DOWN_(X%)

  DO_PARAM(CM_LAND_SNR)

 END

 

 TO (CM_LAND_SNR)       // Manage soft landing

  PARAM_ADD(16)       //     allocate about 80 meters

  PEN_UP

   USE_CURRENT_POS         // aim for the current flightplan x,y position target, TO BE REPLACED BY TAKE_OFF_POS

   USE_ANGLE_TO_GOAL       // aim for the current flightplan angle target, TO BE REPLACED BY TAKE_OFF_ANGLE

   //USE_CURRENT_ANGLE

   BK_PARAM        //  start exec. of script 80 meters from goal

   PARAM_DIV(3)

   FD_PARAM

   IF_LT(ALT_SNR, 270)      // After 130 m If altitude from sonar is less than 2.7 m

    FLAG_OFF(F_LAND)     //     throttle up, flare and

    SET_ALT(4)       //     moderately level the descend slope

   ELSE

    SET_ALT(3)

   END

  PEN_DOWN

  FLAG_ON(F_LAND)

  FD_PARAM

  IF_LT(ALT_SNR, 138) 

   //FLAG_OFF(F_LAND)  

   SET_ALT(2)

  ELSE

   SET_ALT(2) 

  END

  FD_PARAM

  IF_LT(ALT_SNR, 50)

   FLAG_OFF(F_LAND)

   SET_ALT(2)

  END

  FLAG_ON(F_LAND)

 END

 

Best of luck to both us.

 

Kindest regards.

Daniel

[Peter Hollands]

Hi Daniel,

Thanks for sharing that. I think you are well ahead of me on sophisticated Logo.

I see you are using a very different approach to the flight plan. You relying on GPS being accurate to within 1 meter for landing and sonar is used to confirm height at 1.38 m and 0.5m .

If GPS in your area is really that accurate, then Bill's comment about fusing sonar data into IMU position may be a neater solution in the long term.

I recomend using a fixed origin. That is highly recommend for consistency of position and altitude.

My flightplan was very different and assumed poor GPS altitude accuracy, and circumvented occasional false "out of range" readings on sonar on landing. I used sonar to just create a single state change to final flare.

I am really enjoying working with you on this. Thanks for pointing out the potential compile bug
I'll test the sonar branch for that.

I will change my Logo noun from SONAR_HEIGHT TO ALT_SNR to keep compatibility of scripts.

Ben, please confirm your view on that as we are adding to the Logo API.

Best wishes Pete

[Peter Hollands]

Daniel,

 

For the completeness of this thread, I enclose a picture of my Maxbotix Sonar fitted to the underside of the right wing on my Alpha Axion plane.

 

Best wishes, Pete

[ben levitt]

On Mon, Sep 24, 2012 at 1:11 AM, Peter Hollands
<peter.h...@gmail.com> wrote:
> I will change my Logo noun from SONAR_HEIGHT TO ALT_SNR to keep
> compatibility of scripts.
>
> Ben, please confirm your view on that as we are adding to the Logo API.

I think I like starting with ALT_ and then adding the modifier after
it. I think it might be more clear with SONAR spelled out, as
ALT_SONAR.

Also Pete, I think your installation looks great! If it ends up
working well for you, I think I'll add sonar to one of my planes too!

Ben

[Peter Hollands]

Daniel, Ben,

I have made a few more changes in the sonar branch tonight

• Ensured SERIAL_UDB_EXTRA compiles correctly when sonar not enabled.
• Ensure flight plans with ALT_SONAR statements fail to compile if sonar not enabled.
• Ensure code cannot be used (for now) with non UDB4 boards. The UDB4 had the extra timer that I needed for the sonar's PWM. I'm not sure the UDB3 has any spare timers.

Ben the ALT_SONAR code in logo_flightplan.c uses conditional compiler directives in the ENUM and CASE statements. (see excertpt from patch below). I hope that is OK. (That is one of the advantages of using ENUM).

Best wishes, Pete

==============================

=========
--- /branches/MatrixPilot_sonar/MatrixPilot/flightplan-logo.c   Sat Sep 22 06:59:43 2012
+++ /branches/MatrixPilot_sonar/MatrixPilot/flightplan-logo.c   Mon Sep 24 11:07:34 2012
@@ -51,7 +51,9 @@
        DIST_TO_HOME = 16,
        DIST_TO_GOAL,
        ALT,
-       SONAR_HEIGHT,
+#if ( USE_SONAR_ON_PWM_INPUT_8 == 1 )
+       ALT_SONAR,
+#endif
        CURRENT_ANGLE,
        ANGLE_TO_HOME,
        ANGLE_TO_GOAL,
@@ -564,8 +566,10 @@
                case ALT: // in m
                        return IMUlocationz._.W1 ;

-               case SONAR_HEIGHT: // in centimeters
+#if ( USE_SONAR_ON_PWM_INPUT_8 == 1 )
+               case ALT_SONAR: // in centimeters
                        return sonar_height_to_ground ;
+#endif

                case CURRENT_ANGLE: // in degrees. 0-359 (clockwise, 0=North)
                        return get_current_angle() ;

[DB]

Thanks Pete.

 

So far:

 

I've update to MP r1612, applied all your patches to my prev. mods, however with exception of config_test and flightplan_logo. As I would like to re-use same logo plan accross 5 planes (simple maintenance) the added modifications:

 

flightplan-logo.c:

enum {

 ~~~

 ALT_SONAR,

 ~~~

};

~~~

int logo_value_for_identifier(char ident)

~~~

  case ALT_SONAR: // in cm

   #if ( USE_SONAR_ON_PWM_INPUT_8 == 1 )

   {

    return sonar_height_to_ground ;

   }

   #else

   {

    int sonar_height_to_ground = 0;           // arbitrary value to test presence of  sonar

   }

   #endif

~~~

Therfore in my flightplan-logo.h

 -  with auto take off

 

~~~

  IF_LT(LOGO_B_CHANNEL,3100)         // Less than middle position

     IF_GT(ALT_SONAR, 0)                       //  use sonar if present

       IF_LT(ALT_SONAR, 300)                  // if less than 300cm do autotakeoff

         DO_ARG(CM_CC_TAKEOFFRECT, 135)

       END

    ELSE    

       IF_LT(ALT, 3)   

         DO_ARG(CM_CC_TAKEOFFRECT, 135)

       END

    END

~~~

-  auto landing now includes

 ~~~~

  IF_GT(ALT_SONAR, 0)              //  Sonar attached

    IF_LT(ALT_SONAR, 400)         //  After 128 m distance and cont. descend, check altitude using sonar data and if less than 4m

        FLAG_OFF(F_LAND)           //     throttle up for some flare trajectory to moderate descend, apply a bit of brake as well,

        SET_ALT(4)                          //      SHOULD/WILL BE REPLACED BY PITCH_UP/DOWN_(X ANGLE) and THRUST/THROTTLE..

    END

  ELSE

    IF_LT(ALT, 4)                          //  Use ALT if no sonar is attched,  pray and cross your fingers

        FLAG_OFF(F_LAND)  

        SET_ALT(4)   

    END

  END

~~~~

Thoughts?

[DB]

Hi Pete.

Thanks very much for sharing... Looks excellent!  

 

Mine is  at the belly bottom, right before the UDB4, recessed a bit below and protected by a ply balsa (covering a hole where the retracts used to be) and by 2 landing skids.  It is also nearest the CG and center of plane's axis, theroretically.  This way, hopefully the magnitude and effects of tilt will be minimized.  It is also angled 2-3 deg. forward to help compensate for any systems latency.

 

Downside: This location is not as protected from being soiled and may be exposed to hard impact incase of a crash land, as in the way yours is, mounted under the wing. 

 

All the best.

Daniel

[Peter Hollands]

With regard to my sonar positoning, I should add that my magnetometer is in the left wing to keep it clear of the motor magnetics and other major wires. The magnetometer is further away from the C of G, but it is lighter than the sonar, which is in the right wing. So the two devices balance each other out by their respective moments around the C of G.

Best wishes, Pete

[DB]

Hi Pete.

 

My magnetometer is directly attached via header pins and connector and half an  inch (1/2") from the servo wires going into the out pins of the board.  What are your thoughts on this? Should I need to move it away?

 

Further enthused by your mention of LIDAR, I've looked around and they're quite expensive, from 200 to a couple k's. I found one (emitter and sensor) from this site (through-beam laser type, specs attached). Its industrial grade, cost is around $100 for the emitter and sensor, weight is prob. 100 gm (I suspect if hacked without cables and connectors), 50 m range (accuracy is within 1 mm), 1khz switching. 

 

Is this something we can use as well, to increase range and accuracy, complementing the sonar?

 

All the best.

 

Daniel

[DB]

Sorry, forgot the specs.

[Peter Hollands]

Daniel,

The best way to assess your own installation of the magnetometer, is to switch on the magnetometer vectors in Google Earth. If they all point North for the entire flight, then your magnetometer is fine. It rarely does point perfectly North.

I enclose a typical Google Earth Magnetic Vectors view from my most recent flight.

Best wishes, Pete

P.S. if we want to carry on discussing magnetic vectors we should really start a new thread.

[DB]

Really appreciate the accomodations, I'm learning a lot everyday, from your inputs. I agree, to avoid digressing from the subject and important an issue as it is. I'm openning one as suggested. All the best. Daniel

[DB]

Hi Pete, greetings all.

 

As mentioned in the other post, looking at my collection of flight log, Google earth analysis reports, there seem to be a consistent variance between IMU, GPS and Google earth (ground), indicated altitude relative to the sea level.

 

At times, GPS goes underground if not above by a few meters, hardly dependable and reassuring, to control a landing trajectory.

 

As Bill suggested, adding the sonar altitude to the dead reckoning algorithm will probably solve the altitude variance and make the ALT_~ controls in LOGO dependable to invoke an accurate plane pitch/speed/thrust while managing an auto landing trajectory. In this scenario, giving sonar altitude priority over GPS and IMU also makes sense.

 

I'd like to help, volunteer sometime do some of the code changes, and learn in the process, if possible. I've been looking at the UDB DCM libraries and found the codes details and structure mind-boggling, even with the smart models and class diagrams I've reversed engineered.

 

Perhaps you can give me some hint on where to start (..time travel back to high school days and pay more serious attention to trigonometry, instead of looking at the pretty..., might be a good start ;o)?

Wish you good flights and a great weekend!

 

Kindest regards.

 

Daniel

[Peter Hollands]

Daniel,

 

You could start with some of Bill's older explanatory papers that are in the download section. (Have you seen those ?).

e.g. DCMDraft2.pdf is a good first read to get an idea of the original IMU concepts. I had to learn about Matrix Operations,

and their use in a 3D environment. I bought a book on that, and it has been well worth the read.

 

Bbear in mind that Bill has improved the DCM agorithm swith

• Anti -Dizzy logic. Or "How to make an IMU still work correctly when it's put on a spinning record player".
• Automatic Gyro gain calibration.
• HIgh Bandwidth Dead Reckoning.

The concepts behind these latter improvements are usually documented by Bill on his DIY Drones Blog.

 

With regard to the actual software, I recommend starting with the interrupt design.

 

Another approach all together is to choose an area of the software initially which is simpler to get your head around.

I originally started with the telemetry, and then moved onto Camera Targetting, which then taught me a lot abou the wonders of DCM and the Coordinate systems.

 

Personally, I think that improving the altitude estimation of the IMU is going to require a different sensor than our current 4m range (in practice) sonar devices.

We could discuss barometers, radio altimeters (thanks Florin), and laser measurements.  I am however hopeful that sonar can be used to reliably trigger a final flare at an altitude of 1 to 3m  before landing for planes with docile stall characterstics.

 

Best wishes, Pete

[DB]

Hi Pete.

 

Thanks very much for all the valuable information. This oughto keep me very busy for a while.

 

I was prepping to go out to the field and did first some ground test at my front yard to check on the sonar and also the magnetometer.  I had to pospond my field trip as the sonar was giving me 0 alt and magnetometer was going wild (see attachments)

 

Let me check with you on the sonar, are you using pin 2 (purlse width, current connection) or 3 (analog, I'll try this one) for the signal wire?  Regarding the magnetometer, I might just fly with it turned off as Bill has recommended, once I go some data from the sonar.

 

The GPS (using MTEK) seem really out to lunch as well..

 

Cheers.

Daniel

[DB]

Hi Pete.

 

Herewith are some additional information, just in case this makes any difference:

 

1.  a ppm encoder is connected to input (pwm channel) 1

2.  the sonar is connected to input (pwm channel) 8

 

Also just tried pin 3 of sonar and still same results. Wonder what gives. Any idea?

 

Cheers.

Daniel

[Peter Hollands]

Daniel,

Originally, I only coded for PWM not PPM. Kempo has also asked for PPM and I have now added that capability to the sonar branch. As in this set of changes .....

If you are using subversion, you will only have to do a "SVN Update" of MatrixPilot_sonar, and you your code will be updated to work with PPM as well as PWM.

If you use PPM with my initial code, then the Sonar will only return "0" cm, which is exactly the symptoms that you describe.

Please Note: It may be that initialisation of the sonar is important. In my case, my plane is always booted up on a wooden stand which prevents the plane from moving if the engine were to switch on,  keeps the plane off of wet grass, and also helps to keep it level on bootup. This means that my sonar is always at least 18cm from the ground on bootup, and so it can easily calibrate.

For Kemp's sonar, which is an older Maxbotix and a different model number, he has discovered that booting up with zero distance between the wing and the ground is a bad idea. I have never seen that because of the typical way that I operate with my wooden stand. He gets much better bootup results when the Sonar can initially calibrate with a distance between sonar and the ground.

Magnetometer you can live without. Poor or mal-functioning GPS needs to be fixed.

Best wishes, Pete

[DB]

Hi Pete.

 

Quick update: ground (my basement actually) tests are ok and I'm set to go, many thanks to your new changes and recommendation. Really appreciate your help and accommodations.

 

Couldn't have come at a perfect time as I've grown tired of goofin around with radionIn, after figuring out (checking the ref. mats,  re-checking the connections, looking at the UDB radionIn code's gap for sonar under ppm section) that my problem was a sw issue.  So I've been cutting and pasting some of your original sonar code modifications, into the ppm true section of radionIn~, somewhat close to your changes but still lacking some. As a result after so many compiles and tests, I was getting wierd log data that looked liked radio channel frequency numbers.

 

Just as reference, attached are the logs from testing your changes.

 

Hope this weekend will be favored with good weather, and shall circle back with results.

[DB]

Hi Pete, greetings all!

 

Good news!

 

Managed to have 3 flights this afternoon, just before it got too dark, with very promising, encouraging positive results.  One challenge was the presence of northern cross winds, gusty, 14 to 22km.

 

- 1st flight, was basic functional test of different LOGO flightplans variations and characteristics triggered from my TX as well as testing the effectiveness of the magnetometer, under the wing as new location (picture attached).

   Results (screen capture image attached):

 

      -    all LOGO flightplans permutations and functions worked as per 4 switches (incl. knob) conditions, 

      -    the actual variance-error of the flight path and the LOGO fllight plan cut down to less than half, i.e., over compesation was about ave. 60m  and

            undercompensation (direction of the cross wind) 30m,  and 

      -    it appears that the new magetometer location (isolated under the wing) has completely eliminated previous wild erratic magnetic vectors behavior.

 

- 2nd flignt: with some confidence gathered from the 1st flight, I had the nerve to try the auto land LOGO program that uses sonar data on my fragile glider.

     It sort of worked!!! (I'll let the screen shot image tell the story). 

 

-3rd flight: further encouraged, I further had the gut to test auto takeoff LOGO program (also uses sonar data) and by all accounts this worked as well, with exception of the intial quirky turn (again let the image speak for itself)..

 

(On board cam video is available and will soon be posted.)

 

On a side note, perhaps the auto landing was a bit "blessed" as my LOGO program essentialy used GPS altitude data which is often +- several meters off, to control the final landing trajectory (oddly enough, 3 instances of flares was observable, as programed), using sonar data as conditional.  

 

Going forward, I intend to do some more flight tests to replicate these results (repeatability test) while working to:

-  see, enhancing LOGO to include TAKE_OFF_POS(x,y), TAKE_OFF_ANGLE(n), PITCH_UP(n), PITCH_DOWN(n) and THROTTLE_ON(n)~OFF

-  also with your continued help, see if the sonar data can be fused with the dead rekoning algorithm as Bill recommended (in liu of the PITCH~ enhancements).  Bill, if you happen to drop in, I now fully appreciate this, your recommedation.

 

Thanks again Pete, et al,  for making things possible!

 

All the best.

[DB]

Hi Pete.

Just want to share some further optimizing modifications I've done regarding the sonar:

 

1.  introduced a sort of funnel sound collector-concentrator (picture attached) and removed the mesh.  I figure that this should maximize the angle of receptivity, sound distortion and range distance

2.  in anticipation, I modified the altitudeCntrl.c to increase useable distance to 600 , decrease threshold to 2.  

 

Initial backyard ground tests results were very positive.. I'll do some test flights and will keep you posted on the results.

[Peter Hollands]

I just thought I would share a little lesson for me on Logo Interrupts.

Here is a bad snippet of my Interrupt Logo code for "Go Around" when sonar detects the ground ....

#define LANDING_ALT_DIFF     20

TO (GO_AROUND)                          // Interrupt routine for Going Around

    IF_LT( ALT_SONAR, 400)              // If ground is less than 400 centimeter (4 meters away)

        FLAG_OFF(F_LAND)              // Switch the motor back on.

        ALT_UP(LANDING_ALT_DIFF - 1)  // Set desire altitude to be 29 meters further up.
    END                           
END

And if you look at the enclose Jpeg picture of the Logo flight plan in Google Earth, you will see what happened.
The Spike going up 940 meters into the sky is the result when the Sonar saw the ground. Nice to see the Sonar working,
but the Logo is not what I wanted.

The reason for the fault was my understanding of Logo Interrupts. Once the condition for an interrupt is "True", then the interrupt routine will execute on every "frame" of MatrixPilot. i.e. The Interrupt will execute at 40Hz. In my case, that will mean the phrase:-

ALT_UP(LANDING_ALT_DIFF - 1)
will execute 40 times / second. Or if you like 10 times for each telemetry line. or ALT_UP(19) * 10 for each telemetry reading. i.e. going up at 190m every 1/4 of a second.

So the moral of this story is, Logo Interrupts execute continually at 40Hz when the evalutation of their conditional is True.
So usually you will not use Relative Waypoitns or Altitude in an Interrtupt.

In my case Relative altitude is definitely what I wanted (see the full Logo below). Should I clear the Interrupt routine in the Interrupt routine to get the correct behaviour ?  e.g.

#define LANDING_ALT_DIFF     20

TO (GO_AROUND)                          // Interrupt routine for Going Around

    IF_LT( ALT_SONAR, 400)              // If ground is less than 400 centimeter (4 meters away)

        FLAG_OFF(F_LAND)              // Switch the motor back on.

        ALT_UP(LANDING_ALT_DIFF - 1)  // Set desire altitude to be 29 meters further up.
        CLEAR_INTERRUPT
    END                           
END

Best wishes, Pete

Full Logo from that flight shown for reference below:-

#define RIGHT_180            1
#define GO_AROUND            2

#define STRAIGHT_LENGTH      50
#define LANDING_ALT_DIFF     20

const struct logoInstructionDef instructions[] = {

LOAD_TO_PARAM(ALT)                // Remember our Altitude from when we went into Autonomouse Mode
FD(STRAIGHT_LENGTH)

REPEAT_FOREVER                    // Embark on a an oval shape. Forward 100m
    DO(RIGHT_180)                // Turn around by 180 degrees of a circle

    FD(STRAIGHT_LENGTH)            // Go back 100m

    DO(RIGHT_180)                // Do another graceful 180 degrees of a circle to finish Oval.
    FLAG_ON(F_LAND)                // Engine Off, and don't ever go up
    SET_INTERRUPT(GO_AROUND)    // Standby with the interrupt routine, to go around when ground detected

    ALT_DOWN(LANDING_ALT_DIFF)    // In the mean time set altitude 30m further down (may be underground).
    FD(STRAIGHT_LENGTH)            // Aim for that point 100 meters away.
    CLEAR_INTERRUPT                // If you get to that point repeat this plan.
    FLAG_OFF(F_LAND)            // Re-enable the motor, and allow upward flight
    SET_ALT_PARAM                // Set our desired Altitude back to the height at which we entered autonomous mode originally.

    END
END

TO (RIGHT_180)                // A subroutine for executing a nice 180 degree turn around a circle
    REPEAT(18)                // Do this 18 times (turning 10 degrees for 180 degrees)

        FD(8)                // Go forward 8 m

        RT(10)                // Right Turn 10 m
    END
END

TO (GO_AROUND)                          // Interrupt routine for Going Around

    IF_LT( ALT_SONAR, 400)              // If ground is less than 400 centimeter (4 meters away)

        FLAG_OFF(F_LAND)              // Switch the motor back on.

        ALT_UP(LANDING_ALT_DIFF - 1)  // Set desire altitude to be 29 meters further up.
    END                           
END
 
} ;

[ben levitt]

Hi Pete,

That's a great point. Thanks for bringing it up. In this case, I
think just clearing the interrupt after the ALT_SONAR<400 case is
triggered is good enough. Another way I like to handle this kind of
scenario is with a state machine of interrupts that include some
hysteresis/debouncing. Something like this:

Ben



#define CIRCLE_DOWN 1
#define LAND 2
#define TRY_LANDING 3
#define TRY_CIRCLING 4

const struct logoInstructionDef instructions[] = {

TO(CIRCLE_DOWN)
SET_INTERRUPT(TRY_LANDING)
FLAG_OFF(F_LAND) // Engine On
REPEAT_FOREVER
FD(10) // Go forward 10 m

RT(10) // Right Turn 10 m

ALT_DOWN(1) // Drop 1 meter, or 36m per circle
END
END

TO(LAND)
SET_INTERRUPT(TRY_CIRCLING)

FLAG_ON(F_LAND) // Engine Off, and don't ever go up

FD(200) // Should land way before
200m, gliding from just 2m up
EXEC(CIRCLE_DOWN) // Shouldn't get here. If we do,
switch back to circling
END

// Interrupt routine to use during circling
// If we get low enough, try to land
TO (TRY_LANDING)
IF_LT( ALT_SONAR, 200)
EXEC(LAND)
END
END

// Interrupt routine to use during landing
// If we get too high, stop trying to land, and return to circling
// (Not sure why this would happen, but just illustrating the point.)
TO (TRY_CIRCLING)
IF_GT( ALT_SONAR, 400) // Note the hysteresis, as compared to the
<200 in TRY_LANDING
EXEC(CIRCLE_DOWN)
END
END

[DB]

Hi Pete.

 

CLEAR INTERRUPT will probably work in combination with an FD(x), giving the ALT a forward/distance dimension.

 

One of the challenges I have is that the local club where I often fly (except the glider's club where there's virtually no limit..), have  tight takeoff, flying and landing constraints.  Like those governing landing space/distance/trajectory, (e.g.,  flight path shouldn't cross beyond the flight line, and flight path should always be in front, etc...), shape, orientation of the landing strip, and flight direction depending on the wind direction. 

 

Given these one of my goal is to have my LOGO  auto-takeoff, auto-land and the very flight plan/path itself need to be within bounds, yet flexible enough to adopt to different flying fields and situations, in a sort of continuum.. I.e., the launch direction is the condition to

 

This is where I really have fallen for LOGO as one of MP's significant differentiator from the rest of the popular UAV platforms, if I may boldly say.

 

I had 3 test flights today, sort of repeatability tests, of the good flights I had the other day, with some enhancements.  The good news is that the quirky (unplanned flight behaviors) auto takeoff observed has now been resolved, with some LOGO script-corrected-revised use of PEN_UP/DOWN "sneak" script. What a powerful tool!  As the magnetometer new location (thanks Pete!) has lend very consistent accurate performance, the auto takeoff is probably now production state in staging the rest of the flight continuum: varying main flight plan and ending auto land, to be within same orientation bounds.  Some repeated low  fly-bys also produced excellent sonar data...

 

I'll share the script in the next post.. and end this  as it's getting too late (gees past 1 am here).  Again thank you all for the thoughtfull sharing and making these developments possible!

 

I'll let the attachments tell the story for now.

[DB]

Speaking of continuum, sorry, but my fingers can't catch up to thought process to complete: "I.e., the launch direction is the condition to " stage the orientation and direction of the main flight plan down to auto landing..

[DB]

Hi Pete, greetings all.

Just quickly sharing the autoland LOGO function, as promised.

This auto land seem to work as far as managing soft trajectory and maintaining launch orientation are concerned, but is subject to significant drift errors (+- 40 to 66 m, requiring a minimum landing field width of 140 m ).  Per cited constraints, that include 167 x 66 m landing field, any thoughts on how to minimized drift and keep my landing within the field?

All the best.

Daniel

 

////////////////////////////////////////////////////////////////////////////////

// Main Flight Plan

// //////  FUNCTIONS  //////

#define RP_SWITCH                                                       1

~~~~

#define CM_SET_ALT                                                    10

#define CM_CW_AUTOTAKEOFF                             11

~~~

#define CM_CW_RECTANGLE                                    14

#define CM_SET_SPEED                                                               15

#define CM_RTSR_90                                                    16

~~~

#define CM_AUTOLAND                                              19

#define CM_LAND_SONAR                                         20

// //////  PARAMETERS  //////

#define PM_SHORT_RTGLLEG                                   120  // m

#define PM_LONG_RTGLLEG                                     140  // m

#define PM_TKOFF_SNRALT                                      300  // cm, takeoff sonar low alt. threshold

#define PM_TKOFF_GPSALT                                      3       // m, takeoff GPS low alt. threshold

#define PM_SRNDTURN_FD                                      10     // m

//  LANDING

#define PM_LANDG_SPAN                                         200  // m, landing, approach to sonar managed soft touch-down

#define PM_LANDG_APRCH_GPSALT                    4    // m, start of landing field LT/min. alt. threshold

#define PM_LANDG_APRCH_SNRALT                    320  // cm, start of landing field sonar LT/min. alt. threshold

#define PM_LANDG_FSTSEG_SNRALT                   280  // cm, FIRST SEGMENT landing sonar alt. threshold

#define PM_LANDG_SECSEG_SNRALT                                  180  // cm, SECOND SEGMENT landing sonar alt. threshold

#define PM_LANDG_TRDSEG_SNRALT                                  80   // cm, THIRD SEGMENT landing sonar alt. threshold

#define PM_LANDG_FSTSEG_GPSALT                   3   // m, FIRST SEGMENT landing sonar alt. threshold

#define PM_LANDG_SECSEG_GPSALT                                  2   // m, SECOND SEGMENT landing sonar alt. threshold

#define PM_LANDG_TRDSEG_GPSALT                 1   // m, THIRD SEGMENT landing sonar alt. threshold

#define PM_LANDG_APCHSEG_FD                         2   // m, END OF LANDING APPROACH FD FLARE distance

#define PM_LANDG_FSTSEG_FD                             3   // m, FIRST SEGMENT landing FD FLARE distance

#define PM_LANDG_SECSEG_FD                             2    // m, SECOND SEGMENT landing FD FLARE distance

#define PM_LANDG_TRDSEG_FD                            1    // m, THIRD SEGMENT landing FD FLARE distance

//  SPEED control 9 32.4kph, 10 36kph, 11 39.6kph, 12 43.2kph, 13 46.8kph

#define PM_SPEED_LOWTRH                                    9    // m/sec, speed LT/min. alt. threshold

#define PM_SPEED_HIGHTRH                                   11   // m/sec, speed LT/min. alt. threshold

#define PM_TXTOGGLE_LOWTRH                           2800 // TX 3pos-switch control LT/low threshold

#define PM_TXTOGGLE_MIDTRH                            3400 // TX 3pos-switch control LT/mid-GT/high threshold

#define PM_TXKNOB_FSTQTL                                   2800 // TX knob/slider control LT/1st quartile threshold

#define PM_TXKNOB_SECQTL                                   3100 // TX knob/slider control LT/2nd quartile threshold

#define PM_TXKNOB_TRDQTL                                  3450 // TX knob/slider control LT/3rd-GT/4th quartile threshold

#define PM_DISTTO_HOME                                       160  // m min distance threshold to trigger auto RTH and land

#define PM_LANDRTGL_REPEATS                           2               // number of semi-rounded rectangles before landing

 

SET_INTERRUPT(CM_SET_ALT)                                                 // SET ALT PER THROTTLE POSITION

~~~~

IF_LT(LOGO_B_CHANNEL,PM_TXKNOB_TRDQTL)  //PARAM do wider circles PARAM ,  AUTOLAND

                IF_GE(ALT_SONAR, 0)

                                IF_LT(ALT_SONAR,PM_TKOFF_SNRALT)               // if less than 300cm do autotakeoff

                                                DO_ARG(CM_CW_AUTOTAKEOFF,PM_LONG_RTGLLEG)

                                END

                ELSE                      

                                IF_LT(ALT,PM_TKOFF_GPSALT)                                // if less than 3m do autotakeoff

                                                DO_ARG(CM_CW_AUTOTAKEOFF,PM_LONG_RTGLLEG)

                                END

                END

                REPEAT(PM_LANDRTGL_REPEATS)

                                DO(CM_SET_SPEED)

                                DO_ARG(CM_CW_RECTANGLE,PM_LONG_RTGLLEG)

                END

                CLEAR_INTERRUPT

                DO_ARG(CM_AUTOLAND,PM_LANDG_SPAN)

ELSE                                                                                       //_GT PARAM last quartile do TIGHT CIRCLES FOREVER

                REPEAT_FOREVER

                                DO(CM_SET_SPEED)

                                DO_ARG(CM_CW_RECTANGLE,PM_SHORT_RTGLLEG)

                END

                CLEAR_INTERRUPT

END

~~~

                TO (CM_CW_AUTOTAKEOFF)                                    // Clockwise autonomous takeoff

                                IF_GT(LOGO_C_CHANNEL,PM_TXTOGGLE_MIDTRH) 

                                                FLAG_ON(F_TAKEOFF)                 // Agressive takeoff at higher speed

                                END

                                PEN_UP

                                                USE_CURRENT_ANGLE                                 // needs to be tested for RP orientation

                                                USE_CURRENT_POS

                                                PARAM_DIV(4)

                                                BK_PARAM                                        // use parm to move back from target position

                                                PARAM_SUB(7)

                                                SET_ALT_PARAM                             // at 110 param, ALT 20.5 m

                                                PARAM_ADD(7)

                                                PARAM_MUL(4)

                                                FD_PARAM                                        // FD 110

                                PEN_DOWN

                                DO(CM_SET_SPEED)

                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                PARAM_DIV(4)

                                PARAM_SUB(2)

                                SET_ALT_PARAM                                             // at 110 param, ALT 25.5 m

                                PARAM_ADD(2)

                                PARAM_MUL(4)

                                PARAM_DIV(3)

                                PARAM_ADD(5)

                                FD_PARAM                                                        // at 110 param, FD 41.66 m

                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                PARAM_ADD(5)

                                SET_ALT_PARAM                                             // at 110 param, ALT 46.66

                                PARAM_SUB(10)

                                PARAM_MUL(3)

                                FD_PARAM                                                        // FD 110

                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                PARAM_DIV(2)

                                PARAM_SUB(4)

                                SET_ALT_PARAM                                             // at 110 param, ALT 51

                                PARAM_ADD(4)

                                PARAM_MUL(2)

                                PARAM_DIV(3)

                                PARAM_ADD(5)

                                FD_PARAM                                                        // at 110 param, FD 41.66 m

                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                PARAM_SUB(5)

                                PARAM_MUL(3)

                                IF_GT(LOGO_C_CHANNEL,PM_TXTOGGLE_MIDTRH) 

                                                FLAG_OFF(F_TAKEOFF)                                               

                                END

                END

~~~

                //  CLOCKWISE RECTANGLE ( matches CM_CW_AUTOTAKEOFF dimensions):

                TO (CM_CW_RECTANGLE)

                                SET_INTERRUPT(CM_SET_ALT)                                 // SET ALT PER THROTTLE POSITION

                                REPEAT(2)

                                                FD_PARAM

                                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                                PARAM_DIV(3)

                                                PARAM_ADD(5)

                                                FD_PARAM

                                                DO_ARG(CM_RTSR_90,PM_SRNDTURN_FD)

                                                PARAM_SUB(5)

                                                PARAM_MUL(3)

                                END

                                CLEAR_INTERRUPT         

                END

~~~

                TO(CM_SET_SPEED)                                                                      

                                IF_LT(LOGO_C_CHANNEL,PM_TXTOGGLE_MIDTRH) 

                                                SET_SPEED(PM_SPEED_LOWTRH)                            // Light payload and wingloading cruising speed

                                ELSE                                                                                                                       //_GT PARAM

                                                SET_SPEED(PM_SPEED_HIGHTRH)                           // Added payload and wingloading speed

                                END

                END

~~~

                TO(CM_SET_ALT)                            //  Altitude control

                                LOAD_TO_PARAM(THROTTLE_INPUT_CHANNEL)

                                PARAM_SUB(2250)         //  Baseline throttle input: c. 1/4 throttle, 90m mid optimized for DX8

                                PARAM_DIV(4)                 //  Scale: 5 eq. to 340m 1,115.49ft; 4 to 425m 1394.36ft; 3 to 566.66m 1859.12ft

                                IF_LT_PARAM(50)           //  Min. altitude 50 m

                                                SET_ALT(50)                                                      

                                ELSE

                                                SET_ALT_PARAM  //  Proportional to channel pos.

                                END

                END

~~~

                //    //////    AUTONOMOUS SOFT LANDING PROGRAM    ///////

                TO (CM_AUTOLAND)                     // Landing final approach

                                FLAG_ON(F_LAND)        // Start powerless landing glide

                                PEN_UP               // CONTINUUM OF LAST LEG, ENFORCES SAME ORIENTATION OF AUTO-TAKEOFF

                                                USE_CURRENT_POS       // aim for the current flightplan

                                                USE_ANGLE_TO_GOAL                 // aim for the current flightplan angle target,

                                                BK_PARAM                        // use parm to move back from target position as routine's landing span

                                                PARAM_DIV(10)

                                                SET_ALT_PARAM             // At 200 param, this is eq. to 20 m alt

                                                PARAM_MUL(2)

                                                FD_PARAM                        // At 200 param, this is eq. to 40 m

                                                PARAM_DIV(4)

                                                PARAM_ADD(2)

                                                SET_ALT_PARAM             // At 200 param, this is eq. to 12 m alt

                                                PARAM_MUL(3)

                                                PARAM_ADD(4)

                                                FD_PARAM                        // At 200 param, this is eq. to 40 m

                                                PARAM_DIV(10)

                                                IF_GE(ALT_SONAR, 0)   // Chk for a sonar attached, if none, value would be -1

                                                                IF_LT(ALT_SONAR,PM_LANDG_APRCH_SNRALT)

                                                                                FLAG_OFF(F_LAND)                       //     throttle up for some flar,

                                                                                SET_ALT(PM_LANDG_APRCH_GPSALT)

                                                                                FD(PM_LANDG_APCHSEG_FD)

                                                                                FLAG_ON(F_LAND)        // Throttle off

                                                                ELSE

                                                                                SET_ALT(PM_LANDG_APRCH_GPSALT)

                                                                END

                                                ELSE

                                                                IF_LT(ALT,PM_LANDG_APRCH_GPSALT)  // Use ALT if no sonar cross your fingers

                                                                                FLAG_OFF(F_LAND)      

                                                                                SET_ALT(PM_LANDG_APRCH_GPSALT)

                                                                                FD(PM_LANDG_APCHSEG_FD)

                                                                                FLAG_ON(F_LAND)        // Throttle off and continue powerless glide      

                                                                END

                                                END

                                                PARAM_MUL(10)

                                                FD_PARAM        // At 200 param, this is eq. to 40 m

                                PEN_DOWN

                                DO_PARAM(CM_LAND_SONAR)

                END

                TO (CM_LAND_SONAR)                                // Manage soft landing

                                PARAM_ADD(14)             // about 75 meters landing stretch from goal

                                PEN_UP                               // ESTABLISH CONTINUUM WITH ABOVE

                                                USE_CURRENT_POS    // aim for the current flightplan x,y position target                                             

                                                USE_ANGLE_TO_GOAL                 // aim for the current flightplan angle target,     

                                                BK_PARAM                                                                        // start exec. of script 80 meters from goal

                                                PARAM_DIV(3)                                                                 // Define three landing segments

                                                IF_GE(ALT_SONAR, 0)                                                   // FST (first) landing segment

                                                                IF_LT(ALT_SONAR,PM_LANDG_FSTSEG_SNRALT) 

                                                                                FLAG_OFF(F_LAND)                       // throttle up, flare and

                                                                                SET_ALT(PM_LANDG_FSTSEG_GPSALT) // moderately level the descend slope

                                                                                FD(PM_LANDG_FSTSEG_FD)     // flare dist PARAM

                                                                                FLAG_ON(F_LAND)                        // Throttle off and continue powerless glide

                                                                ELSE

                                                                                SET_ALT(PM_LANDG_FSTSEG_GPSALT)

                                                                END

                                                ELSE

                                                                SET_ALT(PM_LANDG_FSTSEG_GPSALT)

                                                END

                                                FD_PARAM

                                PEN_DOWN

                                IF_GE(ALT_SONAR, 0)   // SEC (second) landing segment

                                                IF_LT(ALT_SONAR,PM_LANDG_SECSEG_SNRALT) 

                                                                FLAG_OFF(F_LAND)

                                                                SET_ALT(PM_LANDG_SECSEG_GPSALT)

                                                                FD(PM_LANDG_SECSEG_FD)  // flare dist PARAM

                                                                FLAG_ON(F_LAND)                                       

                                                ELSE

                                                                SET_ALT(PM_LANDG_SECSEG_GPSALT)

                                                END

                                ELSE

                                                SET_ALT(PM_LANDG_SECSEG_GPSALT)

                                END       // If conditions not true, maintain the landing trajectory

                                FD_PARAM

                                IF_GE(ALT_SONAR, 0)   //  TRD (third) landing segment

                                                IF_LT(ALT_SONAR,PM_LANDG_TRDSEG_SNRALT)

                                                                FLAG_OFF(F_LAND)

                                                                SET_ALT(PM_LANDG_TRDSEG_GPSALT)

                                                                FD(PM_LANDG_TRDSEG_FD)    // flare dist PARAM

                                                                FLAG_ON(F_LAND)       

                                                ELSE

                                                                SET_ALT(PM_LANDG_TRDSEG_GPSALT)

                                                END

                                ELSE

                                                SET_ALT(PM_LANDG_TRDSEG_GPSALT)             

                                END

                                FD_PARAM

                END

On Saturday, September 1, 2012 12:17:06 PM UTC-4, Pete wrote:

[DB]

Hi Pete, greetings all.

 

In regards to the issue of drift (pls. see the images attached in recent posts) I just want add some information that may be relevant:

 

1.  in option.h

 AIRFRAME_TYPE      AIRFRAME_VTAIL

 ~~~

 WIND_GAIN_ADJUSTMENT    0

 ~~~

 ALTITUDEHOLD_STABILIZED    AH_PITCH_ONLY

 ALTITUDEHOLD_WAYPOINT    AH_FULL

 ~~~

#define ROLLKP        0.25

#define ROLLKD        0.08

#define YAWKP_AILERON      0.08

#define YAWKD_AILERON      0.03

#define AILERON_BOOST      1.00

~~~

#define PITCHGAIN       0.12

#define PITCHKD        0.07

#define RUDDER_ELEV_MIX      0.05   // reduced for breeze's vtail configuration

#define ROLL_ELEV_MIX      0.05

#define ELEVATOR_BOOST      0.50

~~~

#define YAWKP_RUDDER      0.08

#define YAWKD_RUDDER      0.12 //  0.12

#define ROLLKP_RUDDER      0.06

#define ROLLKD_RUDDER      0.05

#define MANUAL_AILERON_RUDDER_MIX   0.03

#define RUDDER_BOOST      1.00

(I'm wondering if any of these is fighting navigation and might be causing the drift?)

 

2.  in my flighplan-logo.h, complementing the recent posted LOGO program, are the left and right turn functions:

 

                TO(CM_LTSR_90)                                                                             // Right turn 90 degrees, semi round

                    REPEAT(9)      

                        FD_PARAM                // uses PM_SRNDTURN_FD defined param eq. to 10

                        LT(10)   

                    END    

                END 

                TO(CM_RTSR_90)                                                                            // Right turn 90 degrees, semi round

                    REPEAT(9)      

                        FD_PARAM

                        RT(10)   

                     END    

                END

 

Any suggestions (how to minimize drift) will be greatly appreciated.

 

All the best.

Daniel

[William Premerlani]

Hi Ben,

I just want to thank you again for developing MP's LOGO capability. It is one of the top features of MP, and I am really glad you decided to implement it. And I also thank LOGO users for finding interesting ways to use the LOGO feature.

Best regards,

Bill

[Peter Hollands]

Hi Daniel,

With regard to preventing "drift" during your landings ....

I think there are two areas to work on:-

• Improving the control gains of your aircraft
• Trying to get "Cross Tracking" working well for you.
  

Improving Control Gains:-

I notice from your Google Earth flights, with Logo waypoints shown alongside the flight track, that your plane is not really following the Logo path well. It is understeering all the time, by significant amounts. Here are some throughts about that ...

When tuning MatrixPilot control gains, it is vital to remember that there can be up to 3 Pilots flying the plane at the same time. Here is how the 3 Pilot dynamics work ...

In Manual:- Just you, the real human pilot is in charge of the plane.

In Stabilized (AH_NONE is true [Alittude Hold is off] :- The stabilization pilot tries to keep the plane level in pitch and roll. The manual pilot can also "mix in their controls". If the manual pilot turns right, the stabilization pilot tries to level the plane. But the mixing in the ailerons or elevator leaves a residual error, which means the plane settles in a bank or ascent/descent pitch.
Stabilization works against the manual pilot. Lot's of high gains for stabilization will make the plane difficult to turn. Low gains for stabilization are best. So the plane is still easy for the manual pilot to fly, but so the plane remains stable at all normal flight speeds. Lot's of new users turn the stabilisation gains upt to high. The plane should be easy to turn with stabilisation on.

In Autonomous Mode: There are three pilots. Autonomous Navigation Pilot, that tries to turn the plane against the wishes of the Stabilisation Pilot. And potentially the Manual Pilot can also "mix in commands" alongside those of the Autonomous Navigation Pilot. If the plane is easy to turn for the manual pilot in stabilized mode, then the plane will also be easy to turn for the Autonomouse Navigation Pilot (against the Stabilization Pilot) in Autonomouse Mode.  Make sure the plane is not over-stabilized, otherwise the the Navigation Pilot will have a hard job turning the plane.

So the key to creating nice autonomous turns in MatrixPilot is to: a) Keep stabilisation gains reasonably low - test that in Stabilized mode using manual flight b) once stabilisation gains are correct, then adjust the navigation gains upwards make the plane turn more forcibly onto new navigation routes and directions when in Autonomous mode.

So which are the stabilisation gains, and which are the navigation gains ?  The main navigation gain on my plane is YAWKP (I'm flying with ailerons.)

(A note in passing. Many classical RC planes are naturally stable by design. By careful about using "KD" gains where they are not really needed. I set quite a few of my KD turns to zero for my Alpha Axion (similar to an easystar) and for my Twinstar 2.)

Tuning up Control Gains used to be a laborious technique .... until MAVLink was implemented. I think that few people have used that yet, so it is still rather experimental, and best tested on cheaper / more disposable air frames.
With an Xbee connected to your plane, you can change the main gains of the plane, while it is in flight. It requires two people. One flying, the other using a PC with QgroundControl running, to change the gains in flight. The knowledeable pilot flies, and keeps their eyes on the plane,and verbally requests Gain changes. The second person makes the changes on the PC, transmits them to the plane, and confirms verbally the change. In one flight, you can tune up a plane perfectly. I first did this with Riccardo Kuebler in Switzerland last January (Thanks Ric !).

I enclose a comparison screenshot of my plane following an Oval Logo pattern where the straights of the oval are 100m, to show how I would hopet your plane could follow the Logo paths.

Improving Cross Tracking:-

I'm not sure if you are using the Cross Track Flag yet at all ?  People have had mixed results over the years with cross tracking. But potentially, for landing on a runway, we should be using cross-tracking enabled navigation. This is specifically meant to stop the plane from drifiting to one side. I do not have much experience of either the code, algorithms, or usage of cross tracking, so I will leave it for others to comment on this area.

Best wishes, Pete

[DB]

Hi Pete.

 

Thanks very much for the very clear guidelines and valuable insights.  I'm truly learning so much from your feedbacks, literally, eveytime you respond.

 

The definitive information on the kp and kd, navigation and stabilization, has now led me to make modifications on my LOGO program and will try it on the field today.  It makes perfect sense and I'm sure it'll make a lot of difference in eliminating if not minimizing the drift just like your very impressive flight as attached (makes me wish for the opportunity to visit Switzerland...;o).

 

Regarding, XBee, I do have it but haven't had the chance to work on it the way you and Ric had.  That will be on my knock off list and thanks very much for the suggestion. 

 

I use to use F_CROSS_TRACK before in LOGO and for some strange reason, it has caused my glider's v-tail (also other test planes)  to wildly vibrate/flutter during turns (also observed in HILSIM X-Plane 10 simulation, as cited in another post).  I really don't know if it's a SW issue, as I suspect, or the way I had used it in my LOGO program that's causing the turning related flutter ...checked all the control links, servo, etc., for slop and they're tight as can be. When I took it off the LOGO program, the flutter completely disappeared. 

 

Recently, I also observed (cited in this post) some "quirky" behavior invoked using F_ALTITUDE_GOAL to help manage ALT_~ related calls. But in effect, F_ALTITUDE_GOAL,  converts the gentle rounded turns programs, e.g., TO(CM_RTSR_90),  into RT(90), causing the "quirky" turns (way off flight plan in my auto takeoff and auto land programs).  My having removed the  F_ALTITUDE_GOAL solved the problem.

 

Let me ask you (a dumb question ;o) as  I probably need to make the auto land "flare" script conditioned on headwind. Is it WIND_SPEED, ~_SPEED_X, ~_SPEED_Z (or none) that gives a headwind measurement? Follow-up q.: is the measurement in cm/sec or m/sec?

 

Therefore, flare script:

Existing

~~~~                                                               

IF_LT(ALT_SONAR,PM_LANDG_APRCH_SNRALT)

FLAG_OFF(F_LAND) // throttle up for some flar,

SET_ALT(PM_LANDG_APRCH_GPSALT)

FD(PM_LANDG_APCHSEG_FD)

FLAG_ON(F_LAND) // Throttle off

ELSE

SET_ALT(PM_LANDG_APRCH_GPSALT)

END

To-be

 

 IF_LT(ALT_SONAR,PM_LANDG_APRCH_SNRALT)

IF_GE(WIND_SPEED_Z, PM_HEAD_WINDTRH)  // HEAD WIND (?) THRESHOLD TO TURN ON THROTTLE

         FLAG_OFF(F_LAND)// Throttle ON

END

SET_ALT(PM_LANDG_APRCH_GPSALT)

FD(PM_LANDG_APCHSEG_FD)

 

IF_GE(WIND_SPEED_Z, PM_HEAD_WINDTRH)

         FLAG_ONF_LAND)          // Throttle off

END

ELSE

SET_ALT(PM_LANDG_APRCH_GPSALT)

END

As always, any advice is greatly appreciated.

 

All the best.

Daniel

[DB]

Hi Pete.

Just as a thought and with a bit of enthusiasm, since the sonar does works in providing accurate low altitude data, and its probably just a matter of time and fine-tuning and will be very effective in managing a soft landing for fix wing (probably more so useful for the quads and helis), as test flights are starting to show, would it now be worth considering to be included in the dead-reckoning algo, UDB3, and release it in the trunk as well?

Some suplementary observation:

1. accurate consistent measurements as the airplane enters the landing field that has low cut grass

2. stops to work (as indicated by initial flights but would like to test this futher, under different sonar location) when the plane is at certain faster speeds across bushy or areas with high growth (trees and tall bushes)

3. works (tested in my back yard held up from my house's 2nd flr, 410+ cm with tilt as 390+cm is as high as I can held it up, see attached log) accurately if stationary or slow moving even over bushy areas.

Hope this helps.

All the best.

Daniel

[DB]

Sorry but need to correct myself: ".. modifications on my LOGO program .." should be "modifications on my options.h..."

[Peter Hollands]

The sonar has very limited useability at the moment. I want to test it much more.

My hypothesis that I'm testing for our current sonar device MB1230 from maxbotix:-

If the Plane is Higher than 4.00 meters and flying at approx  no more than 10m / s over short straw on  a dry day in reasonably temperatures of between 5-20 degeres C:-
     Sonar will reliably indicate when the plane flys down through the 4 meter contour above ground altitude.
     Sonar will provide no information at all about heights above 4.00 meters

Once the sonar is below 4:00 meters
      Sonar may still intermittmentally go "Out of Range", even though it should be well within range.
             So at the moment, one could nor terrain follow using  the primary sonar information. It will need some type of filtering.
      On landing, Sonar will nearly always go "out of range" for a short period (1/10 of a second) on my field. I do not yet know why.

So in summary, at the moment, I have only one reliable piece of information from sonar to use. "We were high, and on descent, Sonar just detected the ground. It is really there."

I look forward to analyzing your raw logs, and graphing your raw sonar and ALT_SONAR when I have time in the near future, to see if your own data is better or worse.

Best wishes, Pete

[William Premerlani]

Hi Peter,

I agree with you, I think the sonar will need to be filtered. Since the usual landing fields are fairly level and flat, I suggest that the sonar information be fused with the IMU "dead reckoning" estimate. The high-frequency response of dead reckoning is accurate, so sonar could be used to remove bias only.

Best regards,

Bill

[DB]

Hi Pete, greetings all.

 

First of all, I just want to thank you and all so much for all the fantastic work/codes/mods,  incisive information and thoughtfulness you've continue to lend this initiative of using the Maxbotix sonar sensor.

 

These efforts and other contributions are certainly the building blocks, including those from MP's helmsmen Bill and LOGO's guru Ben, that has made all these progress possible.  I've learned so much from these though quite frankly, I have barely scratch the surface of what I need to and would like to learn and productively use. 

 

Pete, Bill, I basically concur on all your observations and having done so far 6 test flights and 2 ground tests: 4 fllights using the default filtering thresholds, 2 with mods: USABLE~ 500 (from 400) and ~SAMPLE~ 2 (plus adding a physical "sound" funnel) then 1 (from 3), and based on the logs, would like to offer, hopefully without offense and belaboring on the subject, the following further empirical observations:

 

1.  from at least 300 cm height, landing speeds of roughly (airspeed "guesstimate" ave. est of selective range as logs indicate wide deviations from flight to flight and from leg to leg) < 5-4m/s,  low cut grass fields, level of sonar altitude accuracy/consistency is at least a 99.99 (I think this greater than 3-sigma).

 

2.  reducing ~SAMPLE~ threshold to 1, apparently minimized occurance of reading latency, and this seems to make some sense per MB1230 data sheet, quote "Readings can occur up to every 100mS, (10-Hz rate)" hence I assume the 3 sampling filter increases the latency to 3 tenths of a sec.

 

3.  GPS est. altitude vs. sonar and actual above ground, deviation ranges from: at best 1 to 6 m and worst, 3 to more than 12 m. (I wonder why this is?)

 

My thoughts going forward therefore includes:

 

A.  as beta test,  LOGO auto land program (target total span of about 200m, starting altitude range of 20 to 25 m) to constitute 2 main sections:

     1)  the landing approach section with 3 segments to manage 110 and descend to 3m alt (300cm sonar alt). 

     2)  the final landing section (from 3m alt to touchdown) will have 3 to 4 sonar alt. dependent segments, to manage "gentle or soft descend trajectory with conditional flares, from 300cm sonar altitude,  est. time span of 2 seconds to touch down and a distance of 80 to 90 m (incl. margin for any flares that may be triggered)

 

B.  given, the wide deviation range of GPS based altitude, I'm thinking now of using barometer based altitude data (actually just ordered  from SFE, Barometric Pressure Sensor - BMP085) to manage the landing approach section (descend trajectory from about 20m) , hoping for a less than half a meter deviation.

 

C.  ..also thinking of reducing the USABLE~ and ~SAMPLE~ filters-thresholds:  350 and 1 respectively

 

D.  inclusion of said sensors based altitude data in re-calibrating (GPS deviation) altitude (at said ranges) for navigation and LOGO ALT control related calls. I haven't yet have a clue on how to pursue this and will certainly beg for, absolutely can use and will greatly appreciate any possible guidance and help from involved subject matter experts..

 

Bottom line, with these changes I hope to look forward to flying fairly accurate and soft autonomous soft landings, consistently (without the risk of plowing the ground, cracking my fuselage, or tearing off my landing gears ;o).

 

Thoughts?

 

All the best.

Daniel

[Peter Hollands]

Daniel,

I enclose a link to a very short video shot on Saturday morning when we had a break in the weather here. (South of the UK).

Here is the interpretation of the video which I have analysed carefully using the SERIAL_UDB_EXTRA telemetry.

1. The plane is in Autonomous mode as it approaches on a powered decent to a waypoint X below ground level. (Yes it would normally have ploughed into the ground).
2. The Sonar detects the ground during descent at 4 meters, and immediately tells the plane to climb to 11m while heading for the same waypoint X. (An Interrupt; with Clear Interrupt) In practice it flew about 1 meter above and parallel to the ground. (My plane has poor climb performance).
3. The plane reached it's waypoint X at the end of the runway, and now was supposed to change altitude to 12m (turtle / target altitude moves from 11 to 12  meters up), and then start a graceful 180 degrees. But instead the motor went briefly off, the plane descended at pitch -9 degrees briefly (about 1/2 a second), landed (all with 1/2 a second) and then went to full throttle. But now the plane had landed and was not going to move.

The video looks like a great landing.

In Truth .... The Sonar worked well, but something happened when the waypoint changes, and caused the plane to dip for a moment, instead of climbing up and away, so it landed when it was not meant to. 

So Sonar is working for me, but I now need better and more accurate low level flying from Logo / waypoints, so I can fly an automatic "Go Around", for multiple landing circuits.

Investigation and analysis is to be continued .....

Best wishes, Pete

P.S. Be very careful in changing the variable:-

#define SONAR_SAMPLE_THRESHOLD                        3 // Number of readings before code deems "certain" of a true reading.

That threshold is there to prevent false "Ground is near" readings, when the plane is more than 4 meters high. In my data set, if the plane is more than 4 meters high, it generally only ever has 1 false ground reading at any one time. So I insist on getting 3 good "ground is near" readings, before accepting that the ground is really near.  I can see that the result is a delay of 3/10ths of a second before accepting readings of less than 4 meters as being "True". But as you can see from my video, the plane changes pitch very quickly once the sonar detects "True" ground readings.

[Peter Hollands]

OK, looking through the code, flight plan, telemetry and video carefully, here is my hypothesis on what happened....

Essentially, I forgot that MatrixPilot is usually flying on a "Desired Altitude Goal Line", between the last waypoint, and the next waypoint. And if you change the height, with an interrupt of the Logo Turtle, it is only going to change the next waypoint's height, not the last waypoint's height.

That can get you into trouble, if you don't think about the nuances.

If you have watched the short landing video, take a good look at this diagram of what actually happened.....

During Descent, the initial altitude goal line was altitude goal line no. 1 (Green).
Then the sonar saw the ground, Logo was interrupted and the Turtle was moved from -28m to 11m.
So now the plane should have followed altitude goal line number 2 (red), which is a flat horizontal line.(which it did pretty much).
Then the plane reached the desired waypoint. The next altitude goal line was calculated. BUT .... the original from goal line is still going to be -28m. So the new Altitude goal line no. 3 goes from -28, to 11m. (blue line) So at the beginning of the line, our plane, tries to dive and also cuts throttle to get back onto the altitude goal line, but ends up landing.

The only thing that is not yet explained, is why the throttle started to come on again, after the landing.
I will think some more on that.

And also, I need now to consider the best way to program the Logo for a go around. Possibly I should have use the Take Off flag.

Best wishes, Pete

P.S. Actual Logo shown below:-

#define RIGHT_180            1
#define GO_AROUND            2

#define STRAIGHT_LENGTH      100
#define LANDING_ALT_DIFF     40

const struct logoInstructionDef instructions[] = {
LOAD_TO_PARAM(ALT)                // Remember our Altitude from when we went into Autonomouse Mode
FD(STRAIGHT_LENGTH)
REPEAT_FOREVER                    // Embark on a an oval shape. Forward 100m
    DO(RIGHT_180)                // Turn around by 180 degrees of a circle
    FD(STRAIGHT_LENGTH)            // Go back 100m
    DO(RIGHT_180)                // Do another graceful 180 degrees of a circle to finish Oval.

    //FLAG_ON(F_LAND)                // Engine Off, and don't ever go up

    SET_INTERRUPT(GO_AROUND)    // Standby with the interrupt routine, to go around when ground detected
    ALT_DOWN(LANDING_ALT_DIFF)    // In the mean time set altitude 30m further down (may be underground).
    FD(STRAIGHT_LENGTH)            // Aim for that point 100 meters away.
    CLEAR_INTERRUPT                // If you get to that point repeat this plan.

    //FLAG_OFF(F_LAND)            // Re-enable the motor, and allow upward flight

    SET_ALT_PARAM                // Set our desired Altitude back to the height at which we entered autonomous mode originally.
    END
END

TO (RIGHT_180)                // A subroutine for executing a nice 180 degree turn around a circle
    REPEAT(18)                // Do this 18 times (turning 10 degrees for 180 degrees)
        FD(8)                // Go forward 8 m
        RT(10)                // Right Turn 10 m
    END
END

TO (GO_AROUND)                          // Interrupt routine for Going Around
    IF_LT( ALT_SONAR, 400)              // If ground is less than 400 centimeter (4 meters away)

        //FLAG_OFF(F_LAND)              // Switch the motor back on.

        ALT_UP(LANDING_ALT_DIFF - 1)  // Set desire altitude to be 29 meters further up.
        CLEAR_INTERRUPT
    END                           
END
 

} ;

[Peter Hollands]

Folks,

Please take my previous post and diagram as being a Hypothesis, rather than fact, until we have reached agreement between the core developers on the detail of what is happening in the code.

Best wishes, Pete

[William Premerlani]

Hi Peter,

I am not familiar with the nuances of the LOGO execution, so I will leave that to Ben.

Regarding the throttle, I speculate that unless you were using the landing option (which shuts off the throttle), then speed control would have turned the throttle on after landing, in an attempt to regain speed.

I notice that you have commented out the lines that would have controlled the F_LAND option.

Best regards,

Bill

[DB]

Hi Pete, Bill.

 

WOW, that does looks like as perfect an auto landing as it could ever be! 

 

What quickly comes to mind as suspect is the deviation on the resultant altitude which, I'm assuming, our LOGO  ALT~ (UP, DOWN, SET_~ and like) calls, use for navigating.

 

As mention earlier (based on my test flights), the deviation range varies around an ave. of roughly at best 1 to 6 m and at worst, 3 to more than 12 m. from flight to flight... So this may account for your actual landing trajectory, further looking at your script, video (BTW, thanks for sharing) and analysis. 

 

I.e., the landing trajectory or flight dotted line on attached (yours ...modified a bit to illustrate my thoughts) analysis, may actually be the resulting altitude net of the deviation (difference between the goal red lined atl. and the acual flight line), which the LOGO ALT_DOWN(LANDING_ALT_DIFF) and ALT_UP(LANDING_ALT_DIFF-1) calls used.

 

This may be a very strong case for including sonar altitude data at it's useful range, for recalibrating apparently pervasive IMU and GPS altitude deviations.

 

Regarding the throttle behavior, I think Bill's comments make perfect sense.  I noticed the controls have been commented off  (//FLAG_OFF(F_LAND)~ // FLAG_ON(F_LAND).  My take on this is that the throttle "energy" or thrust (?) will be managed by navigation based on altitude, actual monitored, vs. goal going forward at the end of the waypoint.  In this case the actual (landed) alt. was lower than the (dotted line) deviant alt goal...

 

Thanks also for the caution on bringing down the threshold on sampling.. It may be a toss in the air, bet. timing and max. accuracy.  I haven't had any opportunity to test but will post back on who wins, as soon opportunity presents itself.

 

(BTW, I saw some sonar sensor, like the MB1260, at MaxBotix with stated 10m range, better sensitivity, just a tad more in cost compared to what we have, with same interface profile. Would this be worth trying?)

 

All the best.

Daniel

On Saturday, September 1, 2012 12:17:06 PM UTC-4, Pete wrote:

[Peter Hollands]

Hi Bill,

Thanks for thinking about Speed Control. I had speed control turned off (Apologies for not including options.h).

I now understand why the engine came on after landing. I have tidied up my diagram, and added explanations for every segment of the landing. It all makes sense now. (Please see diagram).  (link to video for convenience).

 The key point was that the final waypoint in the diagram was only 8 meters further on in Logo, not 100m. (which was how I originally drew the diagram). Logo was executing the 180 degree turn which repeats lots of small steps. So the altitude goal line was from -28 meters to +11 meters over a distance of 8 meters i.e. it was a very steep altitude goal line rising up fast.!

The plane dived for the altitude goal line. Hit the ground (landed), slid a little on the ground, and met the rapidly rising altitude goal line. So it switched on the throttle and tried to climb. But the plane was now firmly stuck.

There is an issue about the Logo Altitude Goal Line as to whether it shoudl have adjusted the goal.fromHeight as well as goal.Height  when the Logo Sonar Interrupt moved the Logo Turtle altitude from -28m to +11m. I  think  Logo should change the previous waypoint height, and  I'm gong to try that in my version of Logo.

Ben,

Thanks for confirming by email that we shoudl probably change the Goal.fromHeight as well as Goal.height when the Logo Turtle changes height during an interrupt. I highlight in green below the new line that I propose.

 void update_goal_alt( int z )
{
    goal.fromHeight = goal.height ;
    goal.height = z ;
    return ;
}

Daniel

Thanks for thinking a lot about the landing, and for editing up a fresh diagram. I appreciate your thoughts. I checked my trim for that flight, and you were right, that the plane was flying approx 10 meters below target altitudes. So that is why it flew at 1 meter above the ground when asked to be at 11 meters.

Looking forward to some more test flights  with appropriate fixes for all the above. I am now hopeful that  a Sonar based landing is going to work quite well.

Best wishes, Pete

[Nikolay Arsov]

Hi guys,
Do you know how the plane speed and sonar angle ( relative to ground surface ) affect the accuracy/sonar behavior?
Best regards
Nick

[Peter Hollands]

Nick,

I only have my own empirical data, which is rather limited still.

Instead, here is some theory:-
My sonar points straight down, at right angles to the velocity vector of the plane.
The plane travels at 11m / second through the air.
The speed of sound is about 340m/s in dry at at 20 degrees C.
So at altitude 10m above the ground,  the time taken for the soundwave to travel from the plane to the ground and back to the sonar is say ((10+10) / 340) seconds. i.e. 0.05 of a second. 
If the plane is travelling at 11m/s then it will have travelled 11 * 0.05 m in that time. i.e. 0.55 meters. or half a meter in round terms.

It is an interesting question, because if the plane flies at 20m / second at an altitude of 10 meters, then the plane will have moved on more than 1 meter before the sound echoes back off the ground back up to the plane.

One could consider the idea of  the acoustic sound transmitter being in the nose of the plane, and multiple sound receivers at various locations down the fuselage !

Best wishes, Pete

[William Premerlani]

Hi Peter,

The role of aircraft velocity is rather interesting, because the transmitted and reflected sound energy is not in a "pencil thin" beam. Its not spherical radiation either. Rather, its somewhere in between. In any case, the transmitted beam spreads out, and the reflected beam does as well.

So, the transmitted beam "illuminates" the ground, somewhat the way a floodlight would do. So, there is energy directed both forward and backward, and there is significant spreading by the time it hits the ground, that will be a function of height. The higher the plane, the more spreading there will be.

Then, there is even more spreading of the beam when it is reflected off the ground. So, by the time the beam gets back to the plane, it is spread over a fairly large area.

The net effect, as far as a fast moving plane is concerned, is that the area containing the reflected beam shifts by the amount that you have computed, but since the beam has spread out quite a bit, the effect should not be too bad.

Interestingly, both the beam spread and the beam shift are proportional to altitude, so the net effect of velocity should not be a strong function of altitude.

Best regards,

Bill

[William Premerlani]

Hi Nick and Peter,

I worked out the math for the effect of the speed of the plane on estimated height. It is negligible for typical model airplane speeds.

A little bit of physics, geometry, and math reveals that the estimated height is related to the actual height by:

Hest = Hactual/sqrt(1-(Vair/Vsound)*(Vair/Vsound))

In the example that Peter considers, Vair = 11 meter/second, Vsound = 340 meter/second, then:

Hest/Hactual = 1.0005

Note that when the plane is flying at the speed of sound, the estimated height will go to infinity.

Best regards,

Bill

On Mon, Oct 8, 2012 at 8:26 AM, Peter Hollands <peter.h...@gmail.com> wrote:

[Nikolay Arsov]

Hi Bill and Pete,
That's O.K., the plane speed do not affect the sonar, but what about the angle. While landing, the plane is pitched a bit or more and if the sonar axis is perpendicular to the plane axis, it could lead to echo signal pointing outside the plane/sonar.....just some thoughts.
Best regards
Nick

[Peter Hollands]

Hi Nick,

Pitch and Roll (which I call tilt) are calculated and allowed for in MatrixPilot firmware using the Direction Cosine matrix.

Provided there is still a return echo signal for the sonar, it can calculated the vertical height to ground, even though the plane is rolling or pitching.

It might be advisable for me to limit the validity of sonar returns to a given angle e.g. 30 degrees of roll / tilt. I have not done that yet.

Best wishes, Pete

[DB]

Hi Nick.

 

If I'm not mistaken and not to pre-empt Pete's response,  pitch and roll already have been factored in, in the altitudeCntrl.c :

~~~

    // RMAT 8 is the cosine of the tilt of the plane in pitch and roll ;
    cos_pitch_roll = rmat[8] ;
    if ( cos_pitch_roll > 16383 )
    {
     cos_pitch_roll = 16383 ;
    }

~~~

as in previous post.

 

Best regards.

Daniel

[Nikolay Arsov]

Thanks Pete,
It's perfect clear now.
Best regards
Nick

[DB]

Nick. Just curious and digressing a bit, what's happening with arsov2 (udb5). ...looked at the UDB5 branch and seems very active. Is it comming out soon? Perhaps you can open another post on the latest update on it's progress (or kindly point me to it if I'm just missing it)? Thanks. Cheers. Daniel

[Nikolay Arsov]

Hi Daniel,
Yes there's a lot of progress, but I'm a bit uneasy for announcing the AUAV2(tiny UDB5) as there are 2 unfinished parts:
1. Firmware;
2. Release candidate of the IMU board.
The baseboard is ready and I think there will be no modifications over it. The IMU has a slight modifications, but I need some time for the IMU RC1 ( rev.7 ) to be manufactured.
Attached are some pictures of the AUAV2_Alpha1 ( the RC1 pictures will be ready soon ).
Many thanks to the team - Mark Whitehorn,Robert Dickenson,Ben levitt,Peter Hollands,Riccardo Kuebler,Matthew Coleman and Bill Premerlani ! They all help the AUAV2 to have it's soul.
Best regards
Nick

[William Premerlani]

Hi Peter,

According to the physics, the sonar should be measuring the shortest distance between the sensor and the nearest reflecting surface (ground), which should be independent of tilt. In other words, there should not be any need to account for tilt.

The only thing that tilt should impact is the intensity of the returned echo, but it should not impact the time for the echo to return.

That is because the sound going out is not in a pencil beam. So, even when the plane is tilted, there is some sound going vertically downward, which will create an echo that will return sooner than any other part of the beam.

Best regards,

Bill

[William Premerlani]

Peter,
Some more thoughts about accounting for tilt. My previous comments
were a simplification, its actually a bit more complicated than that.
First, lets take a couple of limiting, ideal cases.
First case, suppose the beam is a well focused, "pencil beam". In that
case, the measured distance is directed along the z axis of the plane,
and to convert it to earth frame you multiply by rmat[8].
Second case, suppose the beam is not focused at all, and spreads out
evenly in all directions. In that case, the sensor measures the earth
z distance directly, no need to convert it.
But the real case is somewhere between the first and second case. The
beam is not perfectly focused, and it is not perfectly unfocused
either.
So, what you really should do is measure the error as a function of
tilt angle, and use a lookup table to correct.
Best regards,
Bill

On Oct 8, 2:11 pm, William Premerlani <wpremerl...@gmail.com> wrote:
> Hi Peter,
> According to the physics, the sonar should be measuring the shortest
> distance between the sensor and the nearest reflecting surface (ground),
> which should be independent of tilt. In other words, there should not be
> any need to account for tilt.
> The only thing that tilt should impact is the intensity of the returned
> echo, but it should not impact the time for the echo to return.
> That is because the sound going out is not in a pencil beam. So, even when
> the plane is tilted, there is some sound going vertically downward, which
> will create an echo that will return sooner than any other part of the beam.
> Best regards,
> Bill
>
>
>
> On Monday, October 8, 2012 12:28:11 PM UTC-4, Pete wrote:
> > Hi Nick,
>
> > Pitch and Roll (which I call tilt) are calculated and allowed for in

> > MatrixPilot firmwar<http://code.google.com/p/gentlenav/source/browse/branches/MatrixPilot...>e

> > using the Direction Cosine matrix.
>
> > Provided there is still a return echo signal for the sonar, it can
> > calculated the vertical height to ground, even though the plane is rolling
> > or pitching.
>
> > It might be advisable for me to limit the validity of sonar returns to a
> > given angle e.g. 30 degrees of roll / tilt. I have not done that yet.
>
> > Best wishes, Pete
>

> > On Mon, Oct 8, 2012 at 5:20 PM, Nikolay Arsov <nick...@gmail.com<javascript:>

> > > wrote:
>
> >> Hi Bill and Pete,
> >> That's O.K., the plane speed do not affect the sonar, but what about the
> >> angle. While landing, the plane is pitched a bit or more and if the sonar
> >> axis is perpendicular to the plane axis, it could lead to echo signal
> >> pointing outside the plane/sonar.....just some thoughts.
> >> Best regards

> >> Nick- Hide quoted text -
>
> - Show quoted text -

[DB]

Hi Nick.

Thanks very much for taking the time to respond-update. Looks IMPRESSIVE and promising!''

So as not to digress more than already have, I'll PM you later, if you don't mind,  to follow this up for further details.

 

All the best.

Daniel

[Nikolay Arsov]

Hi Daniel,
No problem, you are always welcome.
Best regards
Nick

[Peter Hollands]

Bill,

Thanks for your thoughts on the maths, and beam properties.

The datasheet for the Maxbotix MB1230 shows the beam properties in more detail.

On re-reading the maxbotix sonar datasheet, I see that it has an analog output, and they show typical analog patterns for targets that are returning sonar. One interesting aspect is the fact that the device can return multiple targets at multiple distances. This is interesting if one used an observer filter. Meaning, by using probability techniques (as taught by Sebastian Thrun for the Google Car courses), we could  fuse our IMU and GPS information along with Sonar;  could potentially work out which returned target pulse is a true pulse and much improve our range and filtering of the sonar. This would involve us using the Analogue input direct to the A/D on our own PIC. (Incidentally the PWM output of the MB1230 is produced by an on board PIC16F690.

For now, I'm happy with the quality of my own returned Sonar signal, and look for to auto-landing with it.

Best wishes, Pete


FYI: The full datasheet which includes beam details for the MB1230 is at this location.

[DB]

Hi Bill, Peter.

These are very interesting thoughts and recommendations (has made me glued to my computer longer, before heading out to the field for more testing :o) with apparent significant impact to our ongoing use/tests of sonar.

 

Let me just attached the specs of the sonar's beam and hope this can help provide some detailed info.

 

All the best.

Daniel

[Peter Hollands]

Hi Daniel,

Just to let you know I've reached a milestone of success. My plane has  done a "Go Around" on detecting the ground closer than 4 meters of 2 flights and 6 "Go Arounds".

I enclose a video of the "Go Arounds"

I was correct that Logo needed a fix. But my own suggested fix earlier in this thread was wrong. Ben Levitt mentored me on that and "This fix in the MatrixPilot_Sonar Branch" is OK, and is what I flew today. (The fix is now flight tested, and analysed in telemetry OK). The Logo that I used in my last published flights (enclosed in line below), I used today, which was fine.

I enclose a screenshot of some analysis of the sonar in my spreadsheet with comments.

 I'm happy that the sonar is working within the design limits that I have empirically measured.

Best wishes, Pete


// Example to fly an OVAL pattern attempt to land, and go around again when sonar sees ground.

#define RIGHT_180            1
#define GO_AROUND            2

#define STRAIGHT_LENGTH      100
#define LANDING_ALT_DIFF     40

const struct logoInstructionDef instructions[] = {
LOAD_TO_PARAM(ALT)                // Remember our Altitude from when we went into Autonomouse Mode
FD(STRAIGHT_LENGTH)
REPEAT_FOREVER                    // Embark on a an oval shape. Forward 100m
    DO(RIGHT_180)                // Turn around by 180 degrees of a circle
    FD(STRAIGHT_LENGTH)            // Go back 100m
    DO(RIGHT_180)                // Do another graceful 180 degrees of a circle to finish Oval.

    //FLAG_ON(F_LAND)            // Commented out during testing so Plane has pleny of energy to "Go Round"

    SET_INTERRUPT(GO_AROUND)    // Standby with the interrupt routine, to go around when ground detected

    ALT_DOWN(LANDING_ALT_DIFF)    // In the mean time set altitude 40m further down (may be underground).

    FD(STRAIGHT_LENGTH)            // Aim for that point 100 meters away.
    CLEAR_INTERRUPT                // If you get to that point repeat this plan.

    //FLAG_OFF(F_LAND)            // Commented out during testing. Re-enable the motor, and allow upward flight

    SET_ALT_PARAM                // Set our desired Altitude back to the height at which we entered autonomous mode originally.
    END
END

TO (RIGHT_180)                // A subroutine for executing a nice 180 degree turn around a circle
    REPEAT(18)                // Do this 18 times (turning 10 degrees for 180 degrees)
        FD(8)                // Go forward 8 m
        RT(10)                // Right Turn 10 m
    END
END

TO (GO_AROUND)                          // Interrupt routine for Going Around
    IF_LT( ALT_SONAR, 400)              // If ground is less than 400 centimeter (4 meters away)

        //FLAG_OFF(F_LAND)              // Commented out during testing, when F_LAND notused. (Usually will Switch the motor back on.)
        ALT_UP(LANDING_ALT_DIFF - 1)  // Set desire altitude to be 39 meters further up.
        CLEAR_INTERRUPT
    END                           
END
 
} ;

[Peter Hollands]

NOTE:  I'm sending this post again, to ensure it is in the correct thread of uavdevboard-dev (for continuity).

[William Premerlani]

Hi Peter,

Nice work. Thank you so much for coming up with a robust way to integrate sonar information. Also nice work on using LOGO. And thanks to Ben for his implementation of LOGO, it really is a cool thing.

Some day (when I retire again), I am going to ask you and Ben to help me write a few LOGO programs.

Best regards,

Bill

[DB]

Hi Pete.

 

Very happy to see your flight’s repeated go-arounds and log data show delightfully consistent, perhaps conclusive results well aligned with the anticipated (descend and ascend) trajectories.

 

Congratulations.. it works!  Well done!

 

All your efforts (including latest code modifications) have certainly covered a lot of positive ground in this initiative of including accurate soft landing capabilities in LOGO, using sonar.

 

I also would like to join Bill, in extending Ben well-deserved kudos, for LOGO, IMHO,  an outstandingly powerful flight plan scripting function of MP.

 

Must say that the more I deal with  (..gain understanding) LOGO, the more I appreciate the great mind behind it.  (Currently, I’m attempting, more accurately, fumbling around, to introduce codes to capture during takeoff and use for landing: TAKEOFF~  ~POS and ~ANGLE…)

 

Perhaps, it’s now time to fuse sonar with navigation (“accurize”/optimize LOGO ALT~  related functions), as Bill recommends?

 

I hope for a weather break and opportunity to join you, further testing landing with sonar using attached scripts (pls. see attached snippets for details).

 

Unfortunately, relatively calm weather has recently become fast fleeting and rare with the onset of falls.

 

All the best.

Daniel