After our flight testing was halted by a blown ESC I decided to start work on Software/Hardware in Loop (SIL/HIL) testing. As I pointed out in previous posts we plan to use APM to control multiple autonomous vehicles, all cooperating to various degrees. Before we can safely test such systems outdoors, especially given our constrained operating area, we need to test them in simulation. Prior to our purchase of APM we had been using X-Plane as a simulation environment for some time and so we were pleased to see the existing HIL system provided by the Mission Planner. The problem with this system from our perspective is when simulating multiple vehicles not only do we need multiple copies of X-Plane running (a problem we've always had, hopefully mitigated in X-Plane 10!), but we need multiple Mission Planners running as well. 

The solution we came up with was rather than use X-Plane's native UDP data stream, write a plugin for X-Plane which automatically generates the correct MAVLink HIL messages that APM is expecting and outputs them over a network (SIL) or serial port (HIL). As of today I have finished v0.8 of this plugin which is compatible with ArduPlane in SIL mode. Future revisions will support ArduCopter and HIL.

For initial testing you can use the Mission Planner to connect to the telemetry port (TCP port 5763) to interface with APM the same way as you would in flight.

For more information or to download the plugin click here.

Today we finally got bored of waiting for the windy weather to subside so we took ArduWot out anyway. In the couple of weeks since our last flight we've written an interface between APM and MATLAB/Simulink utilising the MAVLink protocol. For anyone not famliar with Simulink its basically a tool used by control engineers to prototype control systems in a (reasonbly) friendly graphical way. We've used Simulink to control helicopters (T-Rex 250) indoors using a Vicon visual tracking system to determine position/attitude at 100Hz and a conventional RC transmitter. By utilising APMs fly-by-wire mode as the inner loop controller we can command roll, pitch and thottle at a fairly low rate from Simulink over Zigbee. This functionality lets us move outdoors (where we don't have the luxury of a VTS to give us 0.1mm/deg resolution!) and conduct some more interesting research activities, such as optimal control, formation flying, target tracking, etc...

Todays flight was a simple proof of concept test where we used a Simulink based PID controller to perform heading hold. It worked remarkably well but it was too windy to perform any meaningful performance assessments. The biggest issue we have is that using the RC_CHANNELS_OVERRIDE message takes command away from the RC transmitter (in FBW mode) so when we terminate the Simulink model if APM doesn't receive the message to stop overriding (setting all commands to zero) then it freezes on the last signal it received. As we're currently using XBee modules with whip antennae we do regularly lose connection for short periods so occasionally can not get control back (without switching to manual mode, which is undesirable in strong winds!). However, it seems that APM times out after about 20-30s and defaults back to the RC transmitter.

We are using RC_CHANNELS_OVERRIDE at the moment because the SET_ROLL_PITCH_YAW_THRUST message doesn't seem to be implemented on APM. I think for our purposes we may implement this message instead as this would allow us to command the nav_pitch and nav_roll angles on APM directly and utilise the mixing of RC transmitter and APM control if we ever need to get out of trouble quickly!

If anyone is interested in control of APM from Simulink I'd be happy to release the code (after a bit more testing!). Also if anyone has an interest in sending attitude commands and implementing the relevant MAVLink messages, let me know and I'd be happy to help!

Since my previous introductory post we've installed APM in ArduWot and racked up quite a bit of flight testing. In this post I'll give you guys some details on the setup of APM and the flight testing we've done so far.

I mentioned in my previous post that we'd famliarised ourselves with APM using a flying wing before purchasing the Wot 4, for completeness here's a photo of that setup.

The poor old flying wing has suffered a lot of abuse in the past but with APM strapped to it it performed remarkably well. However as you can see it isn't the neatest looking installation and it has a fairly big impact on the wings performance. With the weight of a larger than standard battery as well as the APM it flies pretty quickly which doesn't suit our small test area. So the next step was to find a more suitable airframe with a few key features:

• Easy to assemble - allows us to rapidly expand the fleet
• Robust - we conduct a lot more flights than your average RC hobbiest
• Internal space for APM - additional payload space not too important, but APM must be enclosed
• Slow flying - to afford us the best use of our test area
• Undercarriage - enabling take off and landing from grass
• Able to handle wind

The Wot 4 Foam-e seemed a good match to all these criteria and so ArduWot was born. The video below shows a flight test of the Wot 4 prior to the installation of APM. We have always conducted these sorts of familiarisation flights when using a new airframe as they allow us to identify any undesirable characterists, but the Wot 4 had none!

Shortly after that flight the installation of APM started, and shortly after that it was finished! Removal of some foam reinforcement created a space the perfect size for APM, it's almost like it was designed for it.

The APM was modified to include the magnetometer and a battery lead for voltage monitoring. A small cut out was made in the fuselage ahead of the wing to mount the GPS in. Quite a bit of fiddling was needed to get APM to sit neatly without getting servo wires trapped, but eventually it went in. There's even sufficient space on top of the APM for our relatively massive receiver.

At this point we went out for a few flights to test the basic fly-by-wire functions and we were very pleased with the results. The following day we tackled the installation of a pitot-static probe.

After deciding to go with a conventional wing mounted pitot-static we spent the best part of a day figuring out the least destructive way of installing it. Eventually we decided to feed the pipes through the hollow wing to the aileron servo mount with the aid of a metal rod and a small hole cut in the wing to guide it through a rib. From the aileron servo the pipes head forwards through a hole we made in the spar and leading edge structure where they were attached to the probe. Finally a slot was cut in the leading edge to push the probe into and it was epoxied in place. The pressure sensor itself is mounted to the wing in a position that puts it directly above the APM when installed.

With the exception of a permanently installed XBee module (which is currently crammed in the battery bay), the ArduWot is complete!

Our preliminary flight tests have focused on determining the parameters for stabilisation and navigation. So far everything is going well with the APM surpassing our expectations. Before we can start using the ArduWot as a research tool we will need to create a MAVLink interface for MATLAB/Simulink and we have just started work on this. In the meantime we will continue testing what APM can do as standard (auto take off and landing look like fun!). We are also planning to contribute to Arduplane (and Arducopter with our ArduRex project), we will be implementing features such as initialisation offsets for taildragger aircraft (like ArduWot) once we are familiar with the code.

I hope this has been an interesting insight into our exploits with APM!

The Loughborough University Centre for Autonomous Systems (LUCAS) have spent a number of years working with an indoor rotary wing UAV test environment with little progress on outdoor testing. In recent weeks we've strapped an ArduPilot Mega to an old flying wing and have been very pleased with the results, so much so that we're now building up a dedicated Arduplane, the ArduWot.

The airframe is a Wot 4 Foam-E which comes ARTF, and when they say it's ready to go in 30 minutes they're not lying. All servos come pre-installed as does the motor and ESC. Tail surfaces slide into place and are retained by a single bolt. Wheels are pre-attatched to the legs which screw to the fuselage in seconds. The longest single task was changing the battery connector on the ESC for our preferred EC3.

The battery sits in a bay underneath the front fuselage (little blue hatch in photo below), leaving the centre fuselage pretty empty.

Our receiver is overkill for such a simple aircraft, so in reality there's more space than might first appear. The plan is to remove the foam block between the receiver and the servos and fit the APM here.

Some initial test flights today (without APM installed) showed the Wot 4 to be very easy to fly but also highly maneuverable. Most importantly for us is that it flies around nice and slowly (unlike the flying wings!) which lets us maximise the use of our relatively small test area. Tomorrow we shall be installing APM and doing plenty of test flights.

We are planning to build up a fleet of Arduplanes and Arducopters to conduct research activities such as collaboration, collision avoidance, target tracking, etc... I will keep this blog up to date with the latest developments!