MegapirateNG vs. MultiWii

I've been reading up on forums on the progress of future releases for the MegaPirateNG code base. To my astonishment I soon found out that the main maintainer behind MegaPirateNG left the project to join the ArduPilot team. This means that currently MegaPirateNG isn't developed. A small project fork all tho seem to have been done by some enthusiasts. This is called megapirateng-add-ons ( https://code.google.com/p/megapirateng-add-ons/ ) and is a beta into MegaPirateNG 2.9.1. Some folks claim its superb while some clam it has serious bugs. Others tell to look into the MultiWii code base instead.

Today I tried out the MultiWii 2.2 code, which is the latest in it's branch. From the first look and feel, it feels like the quad is handling a lot more stable. This is before touching any PID parameter configurations. I've done some level flights and it feels really stable. I haven't figured out if it's possible to configure the controller to decelerate the quad on releasing any of the pitch or roll controls, which MegaPirate did by default. That behavior is very helpful for beginners.

The guide I used to get going with MultiWii can be obtained from this forum thread:
http://www.multi-rotor.co.uk/index.php?topic=411.0

This is my current configuration and a look at the MultiWii configuration program.

One detail I found very useful is the fully configurable mode selector. This can be used to combine several features to build your own flight modes instead of having to use any vendor supplied modes.

My configuration states that not using AUX1 should result in a level (angle) flight. Using AUX1, level, barometer to hold altitude, magnetometer to hold heading and GPS to hold position should be used. AUX3 is used in a similar fashion but invoking GPS return to home instead.

It's thereby possible to combine any of these features in any desired way. Further explanation can be obtained at the MultiWii wiki page.

Stay tuned for more information as I go along. I will try to test out the GPS return to home function rather soon.

Ultrasonic range finder part II: how it works

The now famous URF (ultrasonic range finder) has a bit more to tell than I wrote in my last post. One of my big questions was how it would interact with the on-board barometer. As any technical person would understand, is that at some point there will be some kind of conflict as these sensors will indicate different measures.

The URF is rather exact but only has a range of five meters. The barometer on the other hand has unlimited range but isn't that exact. In fact, its quite noisy and differ +/- 1-2 meters.

My experience is that the flight controller handles this in the way that, if the URF indicates different than last measurement then, it's the current height. Otherwise, the barometer is used. This way the URF is disregarded if it's too far from any object and the barometer takes over but also acts as an anti-collision sensor when coming in proximity to the ground.

What I'm still to experience is: What happens if the quad flies over trees? The barometer may indicate 20 meters, while the URF suddenly indicates 3 meters. What happens if it's programmed to hold at 20 meters? Does the quad bounce up 17 meters further? Interesting question.

Issues that I've experienced installing the sensor is that on my device, the Echo and Trigger labels are the wrong way around. On the flight controller that I'm using, the Multiwii MegaPirate board I'm supposed to connect echo to pin 9 and trigger to pin 10. That didn't work unless I connected them the other way around ;).

Sensors, sensors

 

This is how I've mounted the ultrasonic range finder. It needs to be mounted some distance away from other electronics to avoid interference. I still don't know if this will work but it's a first try. Otherwise I'll have to find another solution. The range finder has a maximum range of five meters and should be pretty exact. I still have no clue how the flight controller will treat it's information in conjunction with it's on-board barometer. That's for the future to tell.

The other sensor, or should I say alarm, is a lost signal alarm. It reacts by emitting beeps after one minute of no change to the servo I've attached it to. It's currently attached to the throttle and so, if I don't change the throttle for one minute, it'll start beeping. I'd say the theory is that if you don't move the stick for more then a minute, your signal should probably be lost. Anyhow, then after another minute, it'll sound a more than 85dB beep until it's regained signal. In theory you should then be able to find your model if it's crashed somewhere out of sight. Cheap insurance policy.