Arducopter's Sonar-based Altitude hold works great

I have installed the recommended sonar sensor (XL-Maxsonar EZ4) on my custom-framed Arducopter. Using the ArudPirateNG code, I've been flying with the Altitude hold and it works great. I love it! It allows me to put the quad at the altitude I want, say five feet off the ground, flip the Altitude hold switch on my Tx, and then fly around at will at that altitude. This allows me to practice my yawing, pitching, and rolling without having to worry about crashing into the ground. (Still have to watch out for trees and buildings!). It's very cool. Thank you to the team!

I'm really looking forward to automatic take off and landing in the future, and also obstacle avoidance (using yet to be installed side-firing sensors obviously). I have included some pictures of how I mounted the sonar sensor underneath my quad. I have also included some pictures of the tiny EyeCam camera (made by DraganFly Innovations) that I installed on my arducopter. It transmits video in real-time back to a 9" portable screen and a small video receiver that I rigged up with a battery.

@andrew - this sounds very much like the APM is unable to read the values coming back from the sonar. The slow increase in throttle that you're seeing is certainly caused by the "I" term of the PID controller and it indicates that the APM is not able to read the sonar values.

Could you check that around line 229 of ArduCopterNG.pde you have the appropriate type of sonar defined? i.e. if you're using the XL what's below is ok. If you're using the LV you should comment out the 2nd line and uncomment-out the 3rd line.

#ifdef IsSONAR

AP_RangeFinder_MaxsonarXL AP_RangeFinder_down; // Default sonar for altitude hold

//AP_RangeFinder_MaxsonarLV AP_RangeFinder_down; // Alternative sonar is AP_RangeFinder_MaxsonarLV

#endif

Also inside of System.pde around line 185 you can see whether the sonar is connected to one of the analog ports at the back or the telemetry port at the front of the APM. I.e. below it shows it's using the telemetry port.

#ifdef IsSONAR
AP_RangeFinder_down.init(AP_RANGEFINDER_PITOT_TUBE, &adc);

@Robert - the automatic take off is a bit of unexpected actually. It's possible the Pirates code is different but the original NG code, when you switch on the autopilot, it should set the target altitude to the current altitude. the only thing is that it won't allow the target altitude to be

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Andrew Bailey February 20, 2011 at 4:47am

Randy, I had already checked that and have reset it using the CLI. Sorry. I'm using the default PIDs. I have tried tuning these and it does not really make any difference at all.

The only other thing I can think of doing is ordering another sensor and giving that a try. I do have a feeling that this is probably a setup or software issue. Thanks again.
Developer

Randy February 20, 2011 at 3:17am

@Andrew,

i wonder if maybe your PID values are messed up. Could you check out the CLI menu (put the little white switch on the back right of the APM ..switch it towards the rear and connect using the Arduino IDE 115200 baud)...i believe the option is 'o' to set altitude hold and obstacle avoidance PIDs. the default values can be seen in ArduCopter.h around line 662. they should be:

KP_SONAR_ALTITUDE = 0.8;

KI_SONAR_ALTITUDE = 0.3;

KD_SONAR_ALTITUDE = 0.7;

so when you're entering through the CLI you'll enter 0.8;0.3;0.7
Andrew Bailey February 20, 2011 at 2:54am

Robert, I do like your 'out of the box' thinking, but I definitely have the config correct. It works pretty well in fact using just the barometer hold, so I know that it is set up right. Thanks anyway.
Andrew Bailey February 20, 2011 at 2:49am

Hi Randy, thanks for your post. I am on ArduPiratesNG rather than ArduCopterNG, but I found the lines you referred to just the same. They were correct on my setup. However, I tried switching to the LV in ArduPiratesNG.pde just to see if it had an effect. It did! Still not usable, but it behaves differently. This time, when I engage alt hold the quad does start ascending, but not as fast and it does respond to up and down positions on the throttle stick. With the XL version defined it made no difference what I did with the throttle position. Unfortunately the response with the LV defined is not usable as it simply will not settle at a single stable setting, it is either going up or it is coming down. It is almost as though there is no dead band.

Very interesting! Maybe this will give a clue. Any ideas based on this behaviour?
Developer

Randy February 20, 2011 at 2:27am

@jimmy

I think the wider beam will be fine, it's possible it will even be better.

My guess is that the wider beam will give slightly worse altitude control when the quad rolls and pitches but I think you might be able to go higher and still get decent sonar readings.

I actually have both and I've used both but my testing hasn't been very scientific.
Jimmy February 20, 2011 at 1:53am

I'm sorry, should be LZ EZ-0 ofcourse

Press ENTER to look up in Wiktionary or CTRL+ENTER to look up in Wikipedia
Jimmy February 20, 2011 at 1:50am

Hi all,

I have the Maxbotix LZ EZ-4, the one with the widest beam.

Only afterwards i noticed a smaller beam was advised.

Any ideas how the wide beam would negatively affect altitude hold in our application?

Would it be usable ? Can the beam be tuned ?

Thanks for your input!

Jimmy

Developer

Randy February 20, 2011 at 12:15am

Chethan A February 19, 2011 at 10:10pm

please let me know where i can get those small video cam (wireless) and a receiving and transmitting unit for the same..,
Robert Beatty February 19, 2011 at 5:15pm

Andrew: I have a random thought that is probably nonsensical: Could it be that you have your RC configuration backwards? So, maybe the Altitude Hold is ON from the beginning, and then you're actually turning it OFF (instead of on), or something like that? --Robert

of 5

This reply was deleted.