Blogs

http://www.flightglobal.com/articles/2010/04/01/340168/pictures-farnborough-beckons-for-italian-uav-display-team.html

While the Boeing 787 and747-8 appear set to be the commercial showpiece of July’s Farnborough Air Show, military eyes are likely to be drawn to the Italian unmanned formation display team intending to debut at this year’s event.

Farnborough 2010 organisers have yet to give final authorisation for the Foggia-based ‘Squadriglia Tranquilla’ (‘Quiet Squadron’) to participate, but Flightglobalunderstands that approval is likely to be granted this month.

The nine Alenia Aeronautica Sky-X UAVs have been heavily modified, mainly to reduce fuel and maintenance costs. All of the expensive surveillance equipment used during military operations has been removed, leaving relatively simple pre-programmed on-board guidance. Each Sky-X has also been fitted with a smoke canister.

I will be at Farnborough so will enjoy watching that from the beer tent.

For the last T3 round before the weather improves (in the Northern Hemisphere), we're going to do something indoors! It's a simulation round, which I previewed here.

I'll repeat the basics:

There are two kinds of simulations: "open loop" and "closed loop".

Open loop means that you connect the output of the simulator to the input of the autopilot. The simulation drives the autopilot with synthetic GPS coordinates and sometimes synthetic attitude data, essentially replacing the autopilot's sensors. This basically fools the autopilot into thinking that it is flying, and you can watch how it responds. This is typically done by having the simulator output data via the serial port and feed that into the autopilot.

Closed loop means that you also connect the output of the autopilot to the input of the simulator, so that the autopilot is "flying" the aircraft on screen. This usually requires a relatively complicated bit of hardware that converts the PWM servo output of the autopilot into what amount to joystick commands via USB or serial that steer the plane in the simulator. It can also be done entirely in software on the host PC, as in the case of Matlab simulations being driven by a flight simulator.

Here are some blog posts that show examples:

--Curt Olson's FlightGear demo

--Faisal Shah closes the loop, Part 1

--Faisal Shah closes the loop, Part 2

Here's the contest structure:

Two sets of winners:

Both must write "DIY" (in cursive) over a place of their choosing. Example above from brakar, who, like Jesse & Jared, have jumped the gun a bit and already submitted successful entries for this round.

--Group One: Open loop (video showing you mirroring the airplanes control surfaces with the arrow keys): First six to complete this win a $25 gift certificate to the DIY Drones store.

--Group Two: Closed loop (aircraft controls the flight simulator): First three to complete this win a $50 gift certificate.

A special top prize will go to the person who best documents how they went about it and creates a useful tutorial for others to use afterward (judge: Gary Mortimer). The prize for that will be the notorious Raven UAV clone (unless the winner requests something else, in which case I may grant mercy and come up with something of equal or greater value).

Also, as suggested by Brian Wolfe, anyone who completes either of these rounds will get points added to their grand total: One point for open loop and four points for closed loop. Here are the current cumulative rankings after five T3 rounds:

Brian Wolfe 31
Vassilis 24
Brakar 23
Mark Griffin 18
Krzysztof Bosak 17
Andrus Kangro 12
Jesse Jared 8
IOS 6
Bill Premerlani 6
MarcS 6
Joe 6
Steve Joyce 5
Steve Westerfield 3
Chris Anderson 3
Icebear 1

Entries must include a video and KML track and a description of your simulation setup (flight sim, autopilot, other hardware). Submit your entry in the comments below by 12:00 midnight PST on Sunday, May 2nd.

https://www.youtube.com/watch?v=cipTQAUM-v4

Note** these are 100meter orbits with really strong winds to provide a setting for this test. Hence the reason why the autopilot has a hard time holding a perfect circle. However the improved algorithm is holding so much better in the high wind scenario than the original algorithm!

This is an example of how to eliminate the oscillation in ground track using a heading error>bank angle type proportional controller. The groundspeed of the vehicle determines its turn rate for a given bank angle. Typically you tune the PID (only P is needed) for a given trim airspeed and assume that the ground speed is fairly constant and something close to the airspeed. However when there is high winds, this isn't the case. The ground speed can change +-50% in some cases in and out of phase with the wind if not more.

This causes oscillations on the "upwind" side because the turn rate is so much higher. To take this nonlinearity out of the system, I added the turn rate equation into the mix and solved this problem. The largest contributor to this problem is the GPS lag. So using this turn rate equation in the middle, it makes the controller more predictable with the changing ground speed.

I made an attempt at a video so hopefully it will better explain what is going on here. Especially beings a lot of people are having this problem!

-Beall

I think I've debugged one of the issues I was having with my OpenLog connecting to Ardupilot. This will probably be blatantly obvious to you veteran Arduino Programmers, but it got me, so I figured I'd post in case it helps anyone else.

After a few flights with only the open log and the ArduIMU, I decided to integrate the ArduPilot board and move the logger to the Ardupilot board. My ArduIMU was now talking to the ArduPilot, and I hacked up the ArduPilot code to remove the autopilot/radio functionality and simply combine the ArduIMU input with barometric pressure, and spit out the aircraft parameters as fast as possible.

While stripping down the ArduPilot code for my purposes, I made a whole bunch of changes at once (Mistake #1).

Once everything was back together, I found that I was only getting a log created about half the time. Sometimes there would mysteriously be no log file created. Other times, I would have a small file filled with a bunch of null characters. While debugging I would connect the OpenLog to my FTDI cable and find that it was now operating at 9600baud rather than the desired 57600baud.

The reset to 9600 was the clue. The OpenLog has an emergency reset function. If you get the OpenLogger stuck in an unknown baud rate, you can power it up with the RX line grounded. When this is detected, the OpenLogger goes back to 9600baud on the next power cycle.

So here's my current theory.

One of the changes I made to the ArduPilot code was to add a delay at startup. The reason I added this delay was because of the instructions in the OpenLog datasheet. The OpenLog instructions state: "Turn on OpenLog, wait ~2 seconds and start throwing text at it!" So I added a delay(3000); statement to the void setup() function.

It took a few days of working backwards to figure out what was causing the OpenLog problems. Then I stumbled on this page in the Arduino Reference library:

http://www.arduino.cc/en/Tutorial/DigitalPins

Thats when I realized that I had placed the delay() function before the Serial.Begin() functions in setup().(Mistake #2) I think this meant that during the 3 second delay, the serial pins were in their default input/high impedance state, giving a somewhat random response from the serial logger at the other end.

I moved the delay() line to the end of the setup() function (after the all the initialization is done) and I did 10 powercycles in a row. Each one resulted in log being correctly written to the microSD card.

Tom

As we prepare to migrate our current LabVIEW groundstation from ArduPilot to supporting ArduPilot Mega, we're taking the opportunity to rethink its architecture and code base.

Right now it's written in LabVIEW, a visual programming environment that has the advantage of rapid development and easy-to-make instrument displays, as well as being cross-platform. But the problem with it is that the development tools aren't free (indeed, the ones that can create an executable file start at $1,249!), and distributing the files requires users to download a runtime engine and serial driver. As a result, we don't have as much community participation in the ground station as we do in most of our other projects.

Over the past year, we've been looking for an alternative with free and good development tools. It needs to be cross-platform, compatible with open source code standards, and appropriate for a ground station (ie, able to handle a rich visual environment and to talk directly with the serial port). Eventually a good candidate emerged in Nokia's Qt application and UI framework, and I'd like to present it here for community feedback.

You can see a glimpse of Qt above, but here's the description from the site:

"Qt is a cross-platform application and UI framework. Using Qt, you can write web-enabled applications once and deploy them across desktop, mobile and embedded operating systems without rewriting the source code.

• Intuitive C++ class library
• Portability across desktop and embedded operating systems
• Integrated development tools with cross-platform IDE
• High runtime performance and small footprint on embedded"

Note that it's cross platform on more than just computers--it will also run on phones, too, which introduces the possibility of an ArduPilot GCS on Android or some other smartphone, which would be very cool. Also, we intend to integrate the current ArduPilot configuration utility into the GCS, so one desktop program can handle all the ArduPilot functions, from mission planning to real-time data display, including integrated Google Earth and video handling and image processing.

So what do you think? Is this a good code foundation for a full-featured groundstation? Does Qt look like something you'd adopt for the right project?

[UPDATE: See this Swiss team's MAV groundstation for an example of what Qt can do. Nice! It's open source, so we can build on it if we want.]

Arcus IMU with camera stabilization firmware test #10 from Riccardo Kuebler on Vimeo.

Check out Krzysztof's profile, http://diydrones.com/profile/KrzysztofBosak and his latest post: http://diydrones.com/profiles/blogs/what-can-be-flown-using-rudder

I've mention this project a couple times and finally, here it is.

What: This is an ardupilot board that has been modified as per the picture above. The modifications allow reading the position of 4 channels from your receiver and driving 4 output servos. The firmware has been altered to remove support for gps and instead use the one ATMega328 serial port to write out the receiver channel data and read in servo position commands from an external computer.

Why: I am working on a gumstix based autopilot. The gumstix runs all the "smarts" but I need a simple way to decode receiver channels and drive servos, and I need a manual override safety switch. The ardupilot provides both of these.

I'm no master solder expert, but I managed to avoid soldering my fingers to the board and everything works, so I'm happy.

I am attaching my firmware mods (based on the Ardupilot-2.2.3 firmware with lots of hacking and chopping.) My current incantation only does servos, but I tried to leave the door open to attaching other analog sensors which could then also be reported to the host computer ... this could include pressure sensors, voltage sensors, etc.

ArduPilot_SensorHead_v1.3.zip

I ran into problems using pulseIn() to read the receiver pulses (which made sense after I looked at what pulseIn() is actually doing) so I wrote my own routine that watches all 4 channels at once and times the pulse. I haven't convinced myself that I have the overall board timing locked down exactly the way I want it, but for now it seems to work pretty well. I can read 4 channels of data off my receiver (+ the selection channel state) and I can drive 4 servos from the host computer (tested with a simple sine wave function.)

On the subject of hardware in the loop testing, a board mod like the one described here could be used to read the servo outputs of a standard ardupilot, and feed them to a simulator to be translated into control surface commands there. Some additional software/communication work would be required, but it should be a reasonably straight forward project.

The answer is:

since UAVs are supposed to fly gracefully,

if you pick a platform that is manageable in manual mode (not overly sluggish),

you can fly a machine of arbitrary size.

Also the stall recovery using rudder is intuitive.

IMO positive stability is not strictly required,

but for real-world applications aircraft stability and autopilot action should better be working together.

MultiplexFox (0.26kg, no payload, 20-45min enduirance, 45-55km/h)

Research plane - classified as Barely Flying Machine. -40deg glide slope when unpowered.

Autopilot is the supporting structure... (maybe World's first Intergral Autopilot Design ;-) )

EasyUAV (1.2kg AUW, 0.65kg empty weight, 20min-1h10 endurance, 35-45km/h)

Pteryx UAV (3.2-5kg AUW, 2.6kg empty weight, 20min-1h30 endurance, 40-55km/h)

Fully custom UAV for aerial photography, not available as a kit or in any other form.

(a joint development of AerialRobotics and TriggerComposites, www.pteryx.eu)

All can be hand-launched, however for Pteryx with over 4kg AUW

it is possible to use bungee launch if you want to operate reliably

even under stress.

Today the $170 Raven clone we were talking about the other day arrived. Here are some quick impressions after unpacking it.

First, it's BIG. The wingspan is 60" (152 cm), which is about 15% bigger than the real Raven RQ-11 (130cm). Here you can see it head to head with a stock EasyStar.

The build quality seems pretty good. It's all balsa/ply, with no fiberglass or plastic. The tail boom is an aluminum tube. None of it seems very sturdy, however--this is nothing like the real Raven, which is made of carbon fiber and kevlar and designed to crash land.

However, the model comes with NO instructions, and I really have no idea how the wing is supposed to attach to the body, or where the CG is supposed to be, to say nothing of where the rudder and elevator servos are supposed to go, since the interior of the body is totally empty. There are hatches in the wing for the aileron servos, but no mounting rails.

The tail boom just slides into a hole in the body. I guess you're supposed to drill screw holes or something. No clues given.

The motor mount. No information given on suggested motor or prop.

Here's the inside of the body. Basically, this is an empty vessel. You'll have to do a lot of work creating a plywood interior framework for electronics and such.

It comes with a small bag of generic hardware, including some joke foam wheels and mounting brackets for landing gear that it doesn't have. This is almost certainly a hardware pack intended for another plane. There seems to be no connection to the Raven, although the control horns and fabric hinges could certainly be used on this model. Perplexing...

Bottom line: I really don't think this is the plane for me. Even with instructions, this is going to take many hours to get ready to fly. It's going to be hard to transport, with its large size and one-piece wing, and I'm worried about how it will handle hard landings. The tail boom mount looks fragile to me, and I really can't see how the wing mount can be anything but a fracture waiting to happen.

I think this might work as a very large display model for shows, but I can't really see it holding up to much real flying.

And without instructions, I wouldn't even try making it. For a $170 model, I'd expect more polish. In short, based on what I've seen so far, I can't recommend this.

I ran across this if anyone is having trouble grasping the concept of PID loops. Great, simple explanation:

http://www.pc-control.co.uk/feedback_control.htm

Rim

Gary Mortimer and I are leaning towards a simulation round for the next T3 contest, but I need some feedback about what would work best.

There are two kinds of simulations: "open loop" and "closed loop".

Open loop means that you connect the output of the simulator to the input of the autopilot. The simulation drives the autopilot with synthetic GPS coordinates and sometimes synthetic attitude data, essentially replacing the autopilot's sensors. This basically fools the autopilot into thinking that it is flying, and you can watch how it responds. This is typically done by having the simulator output data via the serial port and feed that into the autopilot.

Closed loop means that you also connect the output of the autopilot to the input of the simulator, so that the autopilot is "flying" the aircraft on screen. This usually requires a relatively complicated bit of hardware that converts the PWM servo output of the autopilot into what amount to joystick commands via USB or serial that steer the plane in the simulator. It can also be done entirely in software on the host PC, as in the case of Matlab simulations being driven by a flight simulator.

Here are some blog posts that show examples:

--Curt Olson's FlightGear demo

--Faisal Shah closes the loop, Part 1

--Faisal Shah closes the loop, Part 2

Here's a proposed contest structure:

Two sets of winners:

Both must write "DIY" (in cursive) over a place of their choosing.

--Group One: Open loop (video showing you mirroring the airplanes control surfaces with the arrow keys): First six to complete this win a $25 gift certificate to the DIY Drones store.

--Group Two: Closed loop (aircraft controls the flight simulator): First three to complete this win a $50 gift certificate.

What do you think? Is this doable?