Owen McAree's Posts (5)

Sort by

ArduWot returns to flight, Simulink in control

2011 didn't end too well for the ArduWot, incorrectly fitted undercarriage made for instant nose over on throttle up which broke the prop and fried the ESC. A new ESC arrived Monday which was quickly fitted only to reveal it to be useless at powering the aircraft and APM, luckily we'd also ordered a BEC (for a different project, but ArduWot takes precedence!). With the ESC and BEC fitted we took her out for a shakedown flight which went without drama, only point of note was a noticeable shift forward in CG with the addition of the BEC. Some advantages of the BEC are some nice little battery monitor lights and a switch for APM/RC gear. The switch is particularly useful as powering up the aircraft in a level attitude (hard enough for a tail dragger) by connnecting the battery in a cramped battery bay used to be quite fiddly!

3689440525?profile=originalBattery monitor lights

3689440541?profile=originalCramped battery bay with switch

Next flight it was time to put Simulink in control. Our last attempt at this went straight to a closed loop heading hold system, but this approach makes it hard to quantify the performance of individual subsystems (namely the delay in the ZigBee link). So this time we started off with some simple open loop step tests. Simulink was given full attitude and throttle command with the defaults being zero roll and pitch and full throttle (as it was a fairly windy day). In the first test a pitch step of 0.75 radians (~43 degrees) was commanded which ArduWot attempted admirably but fell short by a few degrees due to a lack of power. Second test was a 0.5 radians (~29 degrees) roll step, despite the gusty wind ArduWot managed to maintain this perfectly.

Both tests were plagued with Zigbee connection issues which is down to a combination of poor antennae and a restricted operating area. We are forced to operate fairly high and pretty much over our heads dues to high trees all around, this is not the best place to be when you have a pair of omni antenna mounted vertically. We're in the process of knocking up a tracking rig for a high gain directional Yagi antenna which we hope will help matters. When we do lose Zigbee connection for more than 1.5s, APM goes back to it's "Auto" mode. You can see this in the roll test video when ArduWot rolls level and begins to descend, this is it going back to it's default mission which is to fly a circuit around our test site but as soon as it picks up Zigbee again it goes back to Simulinks command.

Despite the telemetry issues we've demonstrated the viability of closed loop control using Simulink. The pitch test saw Zigbee drop out just at the wrong time to properly assess the delay, but the roll test shows a round trip delay of 0.3s which is more than adequate for outer loop control.

The current status of our code is very much preliminary (proof of concept), so it's not very well written. However if anyone is interested there is more information on our wiki, including a link to download our Simulink and modified APM code.

We've just set up a SIL testbed (soon to be HIL also) which should speed up our development and we hope to have some fancy algorithms running in Simulink and other external code running in the coming months. As this happens I'll keep you guys updated!

Read more…

X-Plane and APM without Mission Planner

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.

Read more…

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!

Read more…

ArduWot - Setup and first flights

 

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.

3689433307?profile=original
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.
3689433288?profile=original

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.

3689433365?profile=originalAt 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.

3689433459?profile=original

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

3689433373?profile=original

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!

Read more…

ArduWot - The Beginning

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.

 

3689432708?profile=originalThe 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.

3689432670?profile=original3689432740?profile=original

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!

Read more…