I have two ArduCopters... One with the 850kv motors, 10x45 props and a MB1260 XL-MaxSonar-EZL0 sonar. The second one is a 880kv motors, 12x45 props and LV-MaxSonar-EZ4 sonar. Both on the latest firmware compiled in arduino-0022, 2.0.35 and uploaded to both from arduino-0022.


Something changed in 2.0.35 which causes the motors to gun instead of slowly ramp up to adjust altitude while in alt-hold/loiter. This of course happens on both of my quads.


The larger quad (880kv ez4 sonar) seems to alt-hold and loiter OK but there is an issue with altitude considering the engine gunning.


The 850 kv quad with the ezl0 sonar has worse problems. Alt hold may hold (considering the engine gunning) for a few moments but eventually rises and does not stop or it descends to the ground. Sometimes it will descend to the ground and then fly back up either to a random height OR it will just keep climbing until i recover manually.


The one issue is a code issue, the gunning, this was something chris had done to test some sensors and was going to move the alt-hold code back to where it belonged, this has not happened yet.


So my question is.. Is the ezl0 sensor different in some way that may be causing this behavior? (climbing and not stopping, i was having random problems with this one before).


Im going to disable sonar and give it another go. Attached is the log from the flight with all the alt-hold issues.

Views: 653


Reply to This

Replies to This Discussion

I have the EZ0 sonar and saw the exact same behaviour yesterday with my hexa when testing 2.0.35 : alt hold either climbs constantly or in 1 of my 6 attempts descended rather fast.  It starts to climb immediately after engaging alt hold and at constant speed.  I hear the motors throttle up a certain amount and they stay at that throttle setting.  Even when I set hoovering throttle by briefly (<1s) setting channel 7 high.  This is for engaging althold at more then 10m altitude.

At lower altitude I also get the aggressive motor corrections, as if someone is showing off a motorcycle : vroem, vroem, vroem.

Loiter holds altitude a little longer, but also starts climbing.


The attached log is from my second flight i just completed. This flight the EZL0 sonar was disabled and it performed much better. The motors to not gun as much (or maybe not at all when sonar is disabled) and it keeps an OK alt-hold and loiter.


So it must be something with the EZL0 sonar. I am unable to fly the EZ4 sonar equipped quad at the moment but my last test on 2.0.35 it performed OK except for the motor gunning.


Any ideas with the EZL0 sonar? Should i chuck this $55 sonar for the cheaper but working ones?


Per this thread




The sonar I am using is the MB1260 XL-MaxSonar-EZL0, it IS different than the sonar MB1200 EZ0.


Per the datasheet for the 1200 the scaling factor for the EZ0 is (Vcc/1024) per cm.


The 1260 EZL0 has a scaling factor of (Vcc/1024) / 2 cm.


The datasheets for the sonars can be found here





I do not see anywhere in code where the difference between these two sonars are handled. A mod was suggested which i will try tomorrow but i am certain this is the reason why i am seeing this strange behavior.


I suggest that the diydrones store update their product listing to point to the proper datasheet as well as maybe the developers add a switch in the config for this or other sonars (if one does not yet exist).


I will report back tomorrow.


have a look at this thread http://diydrones.com/forum/topics/understanding-sonar-data
Seems we have some similar issues

Thanks Andrew. I will check it out here in a second.


I just finished another test flight with the moded code that should theoretically take care of the different scaling factor for the MB1260 but something else is going on here....


If you graph the baro and sonar alt you will see that the sonar seems to flaps/is noisy as hell as described in Andrew's thread... It has a sonar reading, it doesn't have a reading, and on and on.


And no, the code mod made to accomodate the 1260 scaling factor had minimal impact. There is something else going on with these sonars.. As noisy as the baro is i trust the baro before i would sonar running any type of mission.

 I went to the trouble of dismantling my sonar mount etc and tested the sonar (MB1200) with the library test code on an Arduino Mega. It all worked fine.
 Jason is having another look at the sonar code today. 
I had a scan through the code but without Jasons master coder skills I could not find any issue
Don't junk your sonar hardware yet

Well i did manage to get a flight in earlier with 2.0.37 which was committed earlier. I did make the barometer mod ( int convert_raw_to_distance(int _raw_value) { return _raw_value \<\< 1; } ).


Here is the graph showing the sonar and barometer (red sonar, green baro)



The EZ4 which i use on my other quad requires you start it up with nothing blocking the sonar so i got into the habit of starting that quad on its side. For some reason this quad shows a sonar of max (what, 700) when it is on the ground. I do not know if this is because i started it on its side. I will start it flat on the gronud my next go.


The first thing to note is that the spikes are all but gone now, it actually looks like good sonar data.


The second thing to note is the barometer spikes, each one of those represents a point in the flight where the quad would climb on its own forever while in alt-hold. It may hold for a few seconds but eventually climb.


I am not sure what to do about the scaling, i guess i will wait and see what others find/decide.


Attached is the log file for those interested.

Since I can rapidly switch sonars now (MB1200 to MB1260 and back), I'll play with it to see if there is a noticeable difference with the scaling change.  When I flew the MB1260 on 2.24, it seemed to hold ok so it may not be a big deal that the scaling is different. I'm just curious to give the patch a try. With the changes in SVN looking good from Jason, I should be able to see what the sonar log looks like tomorrow with both sonars on a couple of runs.





It seems your Ez4 reports ~700 when on the ground

The Sonar code puts this through a moving average filter and produces the ramp up or down from 700 when you land and take off

Looks like we should filter this behaviour out in the sonar code

I cant see your log file can you try to attach it again


That was with the MB1260 EZL0 not the EZ4, i only mentioned the EZ4 because it requires nothing be blocking on start up. I am used to plugging my quad in while its on its side so im not sure if this is why the EZL0 was doing that. I tested the MB1260 on the bench starting it up with the quad level and have not seen that behavior except for that one flight.


Also sorry, the log must not have attached, here it is.


Just out of curiosity i decided to fly two test flights today and grab their logs. Both flights were stabilize only and only consisted of a few minutes. Both flights altitude was varied at least once slowly as well as a few sudden changes in altitude. I wanted to see the difference between the graphs with the moded code (to adjust for the 1260 scaling, graph 1/log 1:01) and the stock code (no scaling adjustment for 1260 scaling, graph 2/log 1:13).


Green on the graph is barometer and red is the sonar. What i expect to see is both be equal or close up and until the sonars height limit which is around 700cm (the 1260 is actually good up to 10 meters).


Looking at the graph it seems that the average filter on the sonar is a bit to aggressive, even on a slow climb out the sonar value can not keep up with the changing altitude. What i expect to see is the sonar to follow the baro (witch some lag due to filtering) up and until its max height.


This IMO is one of the causes of the constant climb out....


BTW i do have on order a MB1200 but what my log shows you will have the exact same problem with this and other sonars as well.


The other thing to note and it has me miffed is at the end of flight 1, beginning and end of flight 2 the sonar ramps up to 700 when on the ground. I did not see this on the bench last night and it does not appear to do it all the time.



Interesting. BTW, the Sonar is not filtered. The Average filter is only there for the non-ADC input. The ADC does have a MA filter, but at 400hz vs 10Hz the lag is virtually non-existant. I have a fast slew rate limiter on it right now to beat down spikes, but it should handle 1 m/s and looking at the graph I think you never beat the filter.


So on your graph, It looks like Barometer just isn't correct, no?


Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service