Blogs

Just in time to run on your new UDBv3, the UDB development team is excited to release version 2.5 of MatrixPilot! This version adds tons of new features, including inverted stabilization, camera targeting, more configurable waypoints, wind speed estimation, dead reckoning, and hardware-in-the-loop simulation. Big thanks go out to everyone who has written and submitted code, tested bleeding-edge versions, found bugs, and asked and answered great questions.

More info over at our wiki.

What's New in MatrixPilot 2.5

• IMU based "dead" reckoning.
• Support for waypoints at absolute positions, relative to startup, or relative to a fixed location.
• More configurable waypoints / flight patterns.
• Stabilize inverted flight.
• Stabilize vertical / hovering flight.
• Beginnings of automatic landing.
• Camera stabilization and targeting.
• Support for automatic detection of, and adjustment for average wind speed and direction.
• Support for using a magnetometer for yaw stabilization.
• Improve robustness of waypoint following when losing the transmitter signal.
• Hardware-In-the-Loop simulation using a UDB and X-Plane.

Team Javelin UAS - UAV OBC D2 2010 from Javelin UAS on Vimeo.

Here is our Delivery II for this year UAV Outback Challenge - Search and Rescue. I wish we have more time to make better video but it's 5 weeks away!!!

Anyway, enjoy - looking forward to making some Autonomous flying video for you later.

Some software improvements

Fast Company has an article about an Israeli water-use monitoring company, and for some reason they tie it into drones. I've read the piece twice and visited the company's website, but can for the life of me figure out why you'd use drones for this. Surely you'd use direct wireless links for this? If they're too far apart for wifi meshing, just use GPRS. The data size is tiny; it?s a perfect app for texting on cellphone networks.

Can anyone explain this?

Excerpt from the article follows:

"The word drone may conjure thoughts of sci-fi flicks, or images of attacks carried out remotely on hostile lands, or even your high-school biology teacher's voice. You certainly don't expect a drone to help save water, but that's what Arad Metering Technologies intends to do. The Israeli company's battery-operated drone is one of the novel tools it's deploying to help consumers and companies conserve H₂O -- and to make money.

That such an idea would come out of Israel is no coincidence. The country is poor in water and rich in tech innovation, much of it born of constant military conflict. Israel pioneered the use of unmanned aerial vehicles after it lost many fighter jets in the 1973 war. But Arad's drones don't fight: They read data from the company's patented water-meter system to detect leakage or, in irrigation systems, drought.

The World Bank estimates that water wastage costs utilities $14 billion a year worldwide; in developing countries, 200 million more people could be served by the water lost to leaks and theft. Arad CEO Dan Winter says this is largely a consequence of how the business works in places where water is cheap or untaxed: "You train people to abuse water because they pay very little."

This broken system created an opportunity for Arad, which has deep green roots. Its parent company, the Arad Group, began making water meters in 1941, after prescient members of Kibbutz Dalia saw how the devices could help save water. Winter says his tech-centric unit seeks "to bring an added value" to both the core business and customers. Its technology can find irregularities -- a pipe failure, an unusually low flow rate, or a too-constant one that could indicate a leak -- in a few hours, rather than every 60 days as with a typical meter reading.

Arad's system is built around what looks like a standard meter. The difference is on the inside, where you'll find 3G wireless technology, a microcontroller, and 20-year batteries. Every 11 to 30 seconds, the system transmits data, which can be picked up by a drone (best for quickly covering big distances in remote areas) or by a drive-by or fixed-base reader. The data are then analyzed by computer to gauge how much water has been consumed, how much was lost, and even where tampering may have taken place. As a result, companies can save both water and man hours.?

This doozy was spotted by Wired's Danger Room team:

"We’ve featured some seriously over-the-top military patches here in the Danger Room. This one, nabbed by Spencer in Afghanistan, counts as one of the most over-the-toppest.

The emblem is for Task Force ODIN — the team of killer drones, manned spy planes, and intelligence analysts, named after the all-seeing pater familias of the Norse gods. And it’s just what you’d want from an Army-meets-Asgard mashup.

On the patch (from ODIN’s just-departed detachment) an armed drone sails over the head of a blond, bearded warrior, clad in chain mail. “SURRENDER OR DIE!” screams the text along the bottom. But the ironic thing is, ODIN isn’t really in the killing business any more.

During ODIN’s original incarnation, in Iraq, the task force helped bring hundreds of insurgent bombers to an early end. These days, in Afghanistan, ODIN is more in the business of surveillance and intelligence-gathering. Guess “SURRENDER OR WE’LL WATCH YOU FOR A WHILE” wasn’t a catchy enough slogan."

The Robots podcast had a great interview this week with Raymond Oung from the Swiss Federal Institute of Technology in Zürich.

"The idea behind this project is to design a set of vehicles equipped with a single propeller and wheels that can drive around in search for fellow modules with whom to dock. Single modules are not stable but once assembled, the flight array is able to take-off and achieve coordinated flight. Modules then detach in-air, fall to the floor and repeat their search for other propellers.

The main challenge in this system is to come up with a distributed controller that can allow modules to work together to achieve coordinated flight. Because of its endless number of configurations, the distributed flight array is the perfect research and pedagogical testbed to study control theory for complex systems."

1. If somehow possible, a GCS should not rely on libraries or tools whose distribution is limited for reasons such as a) operating system or b) commercial distribution or license issues
2. A suitable GCS should be able to present the relevant data as simple as possible; rather than including the latest bells and whistles (realistic cockpit instruments, audio, etc.) the data should be presented in a comprehensible form
3. The GCS should be as platform independent as possible (i.e., not be Windows-only)
   

Auto Launch in 2.7 from Jason Short on Vimeo.

This is always a cross your finger moment. Chris offered to flight test the new auto-launch code which has never been flown before outside of Xplane. I think I heard him say something like 'well this is an old plane and I've landed it in the bay a few times so I guess we should try...'

The winds were pretty heavy, but the auto heading hold worked nicely.

This is a Blog I decided to start chronicling my experience in the hopes that I might make it easier for newcomers to get involved with these amazing machines we call UAVs!

First let me tell you a little about myself. I live in the Adirondack Mountains of upstate New York, in the United States. I'm shown above with my new Senior Telemaster. (Anyone who has followed any of my posts knows the lengths I have gone to to obtain this plane. That's another story!) I am a Network Administrator with a Composites Manufacturer providing Manufacturing capabilities to medical, industrial, and recreational vendors. I have a background in CAD, and CNC Machining. I have had a lifelong love of aviation since I was a small boy growing up in the suburbs of Boston Massachusetts I have always had an interest in electronics, computer programming, and model aviation. First came Radio Control.in about 1989 I started flying a Great Planes PT-40 I purchased at the local hobby shop. Next came an introduction to robotics about 2 years ago with a kit my son got of the Parallax BOE-BOT. This led me to the Arduino platform. Then last January my brother-in-law (a really good guy) gave me a gift certificate to Sparkfun for my birthday! When browsing Sparkfun's web store I came across the ArduPilot, the rest is my experience chronicled here.

First lets talk about my choice of airframe. I wanted a large, stable platform, with a large interior. My "mission" was aerial photography/videography, OK lets face it really I just want to have fun! Anyway , you need to look at what you want to do with your project when deciding on the proper plane to purchase. If you are looking to burn holes in the sky, then a high wing trainer isn't a good choice; if however you want a gentle stable flyer to take aerial photos (as I did) then a high wing trainer is a good choice Many people here like the Multiplex Easystar. The choice is yours but take some time and decide what your "mission profile" is and then seek the advice of others if you aren't familiar with a particular model. While I'm talking about the airframe let me make a basic recommendation, when we all learned to ride a bike, we didn't hope on a 10 speed and just take off down the street never looking back. Rather we started with a beginners bike, and training wheels.If you haven't flown Radio Control before, do yourself a favor and contact your local club and find yourself an instructor. You'll be glad you did!

Shown in the picture above are the two main boards of the ArduPilot system. On the left is the ArduPilot board on the left, and the ArduIMU+ V2. The ArduPilot is the "brain" of the system that integrates all the sensor data, from sensors such as the ArduIMU, and what output is necessary to obtain the desired performance from the aircraft. The IMU is an option as opposed to using thermopiles. Both systems monitor the attitude of the aircraft by sensing the aircraft' orientation in space. The sense I got was that the IMU provided better stability than the thermopiles in mountainous terrain (such as where I live).

. Shown here to the left is the uBlox GPS module.

This module has proven to be very popular, and in my experience very easy to work with. If you've spent any

time reading threads around here you'll probably realize

it does have a few weak points, the antenna connection

is very fragile; so care must be taken to make sure to protect it. The connector on the back of the module is

also very fragile so care should be taken with it as well.

You can see the uBlox adapter, sold at the DIY drones

store, hidden behind the uBlox module. I would suggest using some hot-glue to hold the two parts firmly

together.

Crash protection is highly recommended with this very fragile item. I have heard several methods of protection, including shrink wrapping the parts together, However I have also heard reports of reduced numbers of satellites

obtaining a lock as the temperature rises, so it's important now to insulate it too well.

There are a several supported brands and communications protocols to choose from. With a wide range of features and a wide range of price as well Another important thing to consider is sampling rate, most GPS units come with sampling rates in the 1Hz to 10Hz range. At the low end 1Hz, a slow moving RC car might be able to use a sampling rate this low, but it's not very practical for a plane, at the 10Hz end you could have good data for a fast moving plane. For me 4Hz was great for a slow flying high wing trainer. The choice yours.

No matter what hardware you have, you'll need to consider how to mount them in your airframe. I wanted to have a system I could adjust.

The ArduIMU needs to be parallel to the ground in level flight. Unfortunately it's not easy to calculate exactly where that will be without some actual flight testing. Most planes will fly at a slightly positive AoA (Angle of Attack), therefore the ArduIMU would need to be mounted at an equivalent NEGATIVE angle in order to be parallel to the ground.

The picture on the left shows the installation of my mounting system in my Senior Telemaster. At the back you can see a long strip of Velcro, this acts as a hinge for the plate to pivot on. The 4 Velcro tabs are to attach the removable AP system panel from the mounting plate. The socket head cap screw at the front of the mounting board allows the adjustment of the pitch, positive or negative, of the mount.

While not necessary to make an adjustable mount I think it will allow me some greater degree of precision. If you are using something like a Multiplex EasyStar, it wouldn't make sense to go with something this elaborate.

This picture above shows how I protected my uBlox module with a foam cradle. Notice the cable connected to the uBlox adapter, it goes AFT to the main payload bay where it is connected to the ArduIMU.

The picture below shows the assembly after it was slid in place between the battery tunnel and the fuselage side.

This picture shows the battery monitor adapter, and associated cable I made to attach to the battery monitor on the Ardu Shield V2. If your not going to use the optional telemetry you can ignore this item, as it's unnecessary.

Because I am using a 6s1p LiPo battery pack whose nominal pack voltage is 22.2 volts, well over the 15 volt maximum input to the Ardu Shield V2 board, I needed a way to modify reduce the voltage "seen" by the analog input (AN5).

The battery monitor circuit on the Ardu Shield V2, uses a voltage divider to drop the voltage down to a value AN5 can read without causing damage to the board. Using the formula: Vout = (R1 / (R2 + R1 + "X") * Vin, I was able to determine the value of "X" necessary to bring the voltage down to 5 volts. For me that was 164k ohms. This is only necessary if you are using a voltage greater than 15 volts at full charge. Always calculate based on the full maximum charge, not the nominal rated voltage.

In this picture I've added the Ardu Shield V2. This enables us to add the differential pressure sensor (black box in the middle on the left) for airspeed sensing, and the battery monitoring capability with the voltage divider. It simply rests atop the ArduPilot board. I haven't installed the pitot tubes yet, but the will go out on the wing at least one prop diameter out on the wing. It's important to note here that you should install both the active and the static tubes outside the airframe, and out of the disturbed airflow behind the prop. If you are using a pusher such as with the Multiplex EasyStar you can simply install these in the nose of the aircraft.

Many people using fast moving airframes with IMUs don't bother using the airspeed sensor, however in slow moving airframes, or airframes that fly near stall speed, the Ardu Shield is recommended.

Here in the picture on the left you can see the ArduIMU on the left, the ArduPilot (red board) on the right, and the Ardu Shield on top of the ArduPilot.

They are all isolated from vibration using two different types of foam. You can see a 1/4" thick layer of neoprene foam on the bottom, and a 3/4" pocketed closed cell blue packing foam.

The idea is that the different foam densities protect the electronics from vibration at different frequencies.That's the idea at least, we'll see how well it works in practice.

At the top of the payload bay you can see the battery monitor cable coming from the forward compartment visible at the top of the photograph. Towards the front on the right hand side, you can see where the momentary push-button reset switch is installed through the fuselage side.

This picture shows how the adjustable mount is used to level the cradle the IMU is mounted in. First I check to see that the wing saddle is
level, then I move the level to the cradle, and adjust the mount to
bring the mount level with the wing saddle.

Well, that's it for now! In Part Two, I'll install the pitot tube in the wing, load the code, run through some ground tests, and finally begin some flight testing!

Good luck with all your projects,

Nathaniel

.