Blogs

A: They're both examples of "multi-agent AI scripting". MIT postdoc Frans Oliehoek has been developing some powerful methods for swarms of autonomous objects (software or hardware, like UAVs) to communicate with each other and distribute tasks by following simple policies. One of the simulations his colleagues have tested this on is the videogame Starcraft,  as shown in the demo above.

Here's his code library, the "Multi-Agent Decision Process Toolbox", which may look a little intimidating. But the MIT press office has also written it up well. Here's an excerpt:

In a series of papers presented at the International Conference on Autonomous Agents and Multiagent Systems, Oliehoek and colleagues at several other universities have described a variety of ways to reduce the scale of the policy-calculation problem. “What you want to do is try and decompose the whole big problem into a set of smaller problems that are connected,” Oliehoek says. “We now have some methods that seem to work quite well in practice.”

The key is to identify cases in which structural features of the problem mean that certain combinations of policies don’t need to be evaluated separately. Suppose, for instance, that the goal is to find policies to prevent autonomous helicopters from colliding with each other while investigating a fire. It could be that after certain sequences of events, there’s some possibility of helicopter A hitting helicopter B, and of helicopter B hitting helicopter C, but no chance of helicopter A hitting helicopter C. So preventing A from colliding with C doesn’t have to factor in to the calculation of the optimal policy. In other cases, it’s possible to lump histories together: Different histories can still point to the same result for the same action.

The FY-90 Controller is purpose built for Quadcopter use.

The Attitude flight stabilization system (AFSS), which is the heart of the FY-90Q, is an integrated 3-axis gyroscope and 3-axis accelerometer. AFSS forms a comprehensive inertial based navigation platform that calculates 3D flight attitude using proprietary FeiYu Tech algorithms.

When in full balance mode, the AFSS detects any changes to the models horizontal attitude. If an attitude change is detected, the unit will send out controlling signals to change the rotational speed of the Quadcopters motors to maintain stability.

The FY-90Q system features 2 flight modes.

Mode 1: Full Balance mode, in this mode the Quadcopters flight is fully stabilized on all 3 axis, resulting in extremely leveled flight. Suitable for Aerial photography, video, FPV and beginner Quadcopter Pilots.

Mode 2: Aerobatics mode, in this mode the control signals to each motor are very responsive. This mode is specifically for skilled Quadcopter pilots who want fast forward flight etc.

Specs.
Input Voltage: 4v~6v DC
Current Draw: 52mA (5v)
Size: 55 x 33 20mm
Weight: 20g
Max rate of rotation: <500deg / S

This flight stabilisation is much more sophisticated than the KK multcopter board that Hobbyking just sold, but it seems they are getting serious about the quad market and this is a good step in the right direction.

Price is US$ 109.00 and probably lower if you are a Hobbyking member. See the Hobbyking product page for more information.

I have a digital photocamera mounted on my plane for aerial photography. It's just a simple camera, Fujifilm A170, cheap and provides pretty good quality of photos for this price - about $70, nothing sophisticated. I liked everything but the servo is used to take a photo. I know, it's the simplest way to do aerial photos using an airframe, however this method is so inconvenient. Then I decided, why I use mechanical solution when it's possible and better to use electronical?!

First of all I disassembled the camera. I think, it's interesting for you too to see what's inside:

Then I found out how the shot button works. It has two-position button, first for focus, second for shot. The button has 4 pins. Here is it:

When I short circuit two of the wires - focus process happens, when I short circuit the third wire with that couple - shot happens.

Moreover, I decided to make an external wires for the power. Really, why does the plane need to carry standard heavy Ni-Mh batteries when it's possible to power camera from the main LiPo battery?!
Here are them inside:

And a nice compact view from outside:

I've noticed that if the first and the third wires connected together and then short circuit the second with them, focus and shot happens one after another. It allowed me two use one relay instead of two, so I did:

Then a few words about soft. Certainly, it's possible to control relay with mission scripting in APM Planner, however I wanted to control it with the switch on my transmitter. I connected a cable from the sixth channel of my transmitter to the sixth channel input of APM. Firstly, I created a simple function, which just turns on and off the relay and added control_camera() execution in the fast_loop, here is the code:

void control_camera(void) {

  if (g.rc_6.radio_in < 1500) {
      relay_off();

  }

  if (g.rc_6.radio_in > 1500) {
       relay_on();
  }

}

It works pretty good, but I had to take a photo "manually", then I decided to modify code to make it "auto". I have calculated the optimal altitude, speed and delay between the shots to cover the area below. After that I add the function, which makes photos every XX seconds. Here is this function:

int camera_flag = 0;
int camera_delay = 0;
int current_camera_timer = 0; // counter (in seconds)
int dds = 3; // how much time the relay is on while making a shot (in seconds)
int dbs = 10; // how much time to wait between shots (in seconds)

void control_camera(void) {
  if (g.rc_6.radio_in < 1500) {
      // turn the relay of or do nothing while the switch is off
      if (camera_flag != 0) {
          relay_off();
      }
      camera_flag = 0;
      camera_delay = 0;
      current_camera_timer = 0;
  }

  if (g.rc_6.radio_in > 1500) {
      // while the switch is on - make photos
      if (camera_delay == 1 && current_camera_timer > dbs) {
            current_camera_timer = 0;
            camera_delay = 0;
      }
      if (camera_delay == 0) {
            if (current_camera_timer == 0 && camera_flag == 0) {
                  relay_on();
                  camera_flag = 1;
            }
     
            if (current_camera_timer > dds && camera_flag == 1) {
                  relay_off();
                  camera_flag = 0;
                  current_camera_timer = 0;
                  camera_delay = 1;
            }
      }

      current_camera_timer++;
   }
}

control_camera() execution is added to one_second_loop() function

Here are the calculations of the most optimal flight parametres for aerial photography flight:

h - altitude
v - speed
tetta1 - half angle of horizontal camera lenses view
tetta2 - half angle of vertical camera lenses view
alpha - factor of neighbour photos cover each other (from 0 to 1, I set 0.8)
f - camera lense focus
a/n - size of camera matrix divided by number of pixels in row (a~4mm, n~4000 for 10 mega pixels)
u - exposure time

t - time between shots

s - area of one photo coverage
w - distance between neighbour flight pathes


t = 2*h*(1-alpha)*tan(tetta1)/v
w = 2*h*(1-alpha)*tan(tetta2)
s = 4*(h^2)*((1-alpha)^2)*tan(tetta1)*tan(tetta2)

h = v*f*u*n/a - fly higher than this altitude to get non-blur photos

In the next version of my function I plan to replace constant time between shots by real-time, which will be based on mathematical calculations above.

I also would like to say special thanks to Darren and Yiangos Yiangou for their valuable advice.

As someone who never really got the hang of sketchup, this looks interesting. Free solid modeling tool, billed as a stripped down version of Inventor and keeping feature such as assemblies, constraints and .STL export.

Downloading a copy now.

http://www.123dapp.com/downloads

Antonio Liska, who has won the Sparkfun AVC for two years with a homebuilt autopilot, is now selling a commercial version of that hardware.  It's called the "Goose" and it's just airplane-only at the moment and closed source, but it has impressive features:

Hardware:

• Optional Built-in electronic speed control (ESC)
• Supports Spektrum, Hitec Optima receiver or a GCS joystick for RC backup
• Current Sensor
• 6 PWMs
• 6 Serial Ports
• 3 Spare 10bit ADCs
• Removable SD card for data logging
• Non-removable 4kbit flash memory
• Standard .1inch servo headers
• Standard Deans power connector
• Complete voltage regulation for servos and accessories 5v/3.3v/3v

Capabilities:

• Multiple flight modes selectable via GCS:
  • Standard RC
  • Fly-By-Wire
    • R/C sticks control roll pitch and airspeed
  • Takeoff (Runway or hand)
  • Flight plan
    • Orbits and way-points
  • Land
    • Land in the selected location
  • Return-to-launch
  • Taxi
    • Follow a ground path and optionally enter takeoff mode
• Configurable triggers for servo and digital IO
• Error monitoring – messages displayed on GCS
  • Motor malfunction
  • File system checking
  • GPS serial connection
  • Voltage checking
• Multiple Failsafes
  • Low voltage
  • Loss of communications
  • Mission boundary crossing
  • Loss of GPS
  • Watchdog output pulse
  • Parachute deployment
• Hardware in the loop simulator with FlightGear
• Manual tuning of PID loops in flight
• Flare sensor
  • MaxSonar
  • Sharp IR SHARP2Y0D02
  • Pressure Altitude
• Lifetime flight statistics are logged for various min/max conditions
• Fast Fourier Transform for vibration analysis during integration or preflight
• Fat file system for compatibility with PC

Sensors:

• 3 ST Micro Gyros
• 3 ST Micro Accelerometers
• 2 Freescale Pressure sensors (MPX5004 and MPXH6115)
• 1 Temperature
• Ublox GPS is Externally connected

I thought it would be fun to have an 'inverted flight' switch on my transmitter. With an APM, it's easy! I just added a check for a PWM value above 1700 on channel 7 in read_control_switch(), and when it is above 1700 it sets a inverted_flight boolean. That adds 180 degrees to the nav_roll, which is the target roll for the stabiliser, and it switches the sense of the elevator stabilisation in the main stabilize() code. The result is this patch to the current ArduPilotMega code.

I tried this out a few times with HIL simulation using FlightGear first, then took it flying today with my SkyWalker. There was a lot of wind, so not exactly ideal conditions to be trying experimental patches, but I didn't want to wait for next weekend so I took a chance. It works perfectly!

I setup a spring loaded switch on my transmitter to set channel 7 to 1900 while I held the switch. That allows me to takeoff normally, then whenever I hold the switch in the on position the plane immediately flips over and holds nicely stable flight upside down. You can direct it reasonably well while inverted, although it certainly isn't as responsive as with upright flight (a glider like the SkyWalker isn't really designed for this sort of thing!). The manual mixing of elevator is inverted while upside down (just like it is when you flight upside down manually), which makes this patch good for practising inverted flight, as you can get used to the controls.

The only tricky part of the patch was the change to stabilize() to handle wrap of nav_roll at plus and minus 180 degrees. I originally wrapped it just based on the value, but the HIL simulation showed there was a discontinuity in the stability control at exactly 180 degrees, so the plane would suddenly try to flip over again while upside down as you passed the 180 degree mark. This turned out to be an interaction between the wrapping of the dcm roll_sensor and the nav_roll wrap. The fix was to wrap the nav_roll variable based on the sign of the dcm.roll_sensor variable, and that leads to really nice inverted flight with no crazy behaviour near 180 degrees.

This patch works with any of the stabilised flight modes (ie. anything but manual), which means you can flick the switch for inverted flight while flying a mission, or while in any of the other autopilot modes. It should add a bit of interest to longer missions!

(thanks to Stan for taking the video and coping with the gale blowing at the time)

Hi all,

I did a flight with Ben Levitt's code to track a moving target with a UavDevBoard.

Here is the video

Many thanks to Ben for the code and to all the core team (Bill Premerlani, Pete Hollands, Ben Levitt), for continuous support.

Best regards,

Ric

If you update to the latest Mission Planner (1.05) you'll see a cool new feature Michael Oborne has just added: integrated OSD video! Just select your video input device from your aircraft's camera feed from the Configuration screen (Planner tab) and it will replace the background of the artificial horizon on the GCS, turning it into a heads-up display instead, as shown in the left window above.

Pretty cool, huh? It's a virtual OSD!

 This week SparksFun has a new Imax6 charger for RC batteries.

They will also start stocking the shelves with LiPo batteries next week.  SWEET!

Every Friday SparksFun has a Showcase video of thier products.

Get it here:  Charger

Jason, Gigio and I just got back from a day of test flying four ArduCopters, which is the most we've ever had out at one time. These were of different designs, with different props, motors, ESCs, batteries, frames etc. The point was to try to see why some people have great-performing ArduCopters and others have issues. We assumed it was due to hardware differences, but we needed to test to know more.

Unfortunately, the wind was around 20Mph, gusting to 30, so it was a pretty tough environment for flying. Serious stress testing! We had our share of "hard landings", but all quads lived to fly another day.

Here's what we learned (and are doing):

1. Quads with the gyro filters enabled do seem to fly better, but this seems to be most obvious only if they've got vibration issues to begin with.
2. Balance your props! Out-of-balance props lead to vibrations that can cause IMU errors to accumulate, leading to the "I have to hold the stick all the way over to stay in place" problem. Jason is going to put a better software filter on the accelerometers to try to compensate for that, but the main difference between good-flying quads and bad-flying ones seems to be vibration.
3. While you're at it, double check that your motors and props screws are tightened down. Check them often. We had one motor fall off in flight (d'oh! It wrapped itself around the one arm on way down and pulled out a wire. need a new motor now) and one prop fly off. One of those (the former) was mine, so I feel pretty dumb about not checking.
4. We've fixed that bug where the quad gains altitude quickly in alt hold at the transition between using the sonar and the baro sensor. That will be in the next code pushed in a day or two.
5. Position hold ("loiter") in 25 mph winds is hard ;-). Jason is going to tweak the algorythm for that situation, where the quad has to tilt by 20 degrees just to fight the wind. That's near the max angle of tilt in the code, so if it gets blown downwind, it can't tilt further to come back. For these kind of steady-state tilts, he's going to allow it to tilt further to return to position.
6. Something I learned: if you want to reset "forward" in Simple mode, just disarm the motors, point the quad in the direction you want forward to be and rearm. That will reset the direction.

Jason is going to be releasing 2.0.24 in day or so. If that solves most of these issues and passes beta testing, we'll take AC 2.0 out of beta!

  This little sketch lets you use an Arduino to read the output signals from your RC Rx and displays them to the terminal window.

RC_input_serial_PRINT.pde Download here

    This could be use for testing the 6 position switch output signals, throttle positions, custom mixes, and much more.

Connect the RC Rx Outputs 1-4 and Ground to the Arduino. GND to GND, (Ch 1  pin 9) (Ch 2  pin 10) ( Ch 3 pin 11) (Ch 4 pin 12).  Set Terminal window to 56700.  Displays every 2 seconds.

An Arduino is a very useful tool to have in the tool box.

Since getting video into a computer is cheaper than ever, we've been
contemplating the idea of a cheap, turret mounted camera for position
tracking.  The sonar transducer is a huge source of weight & it doesn't
look like Marcy 1 will ever be stable enough to stay in sonar range.
The reduction in board size & transducer weight would pay off.

The optical mouse is proof that machine vision may replace all other
sensors.  They 1st appeared 25 years ago, requiring grid mousepads.
They barely worked, 10 years ago.  Today, they're taken for granted.

Machine vision would have to difference key out the background.  It
would have to measure X, Y, & Z from a single camera.  It would have to
be cheap enough to justify the means.

After playing around with different color keying algorithms, was pretty
confident position sensing could be done better with vision than sonar &
could be good enough to keep Marcy 1 in a box.  Ideally the camera would
be turret mounted, so that meant recycling a micro camera to build
confidence before investing any money.



This 6 year old laptop camera was never used. 



Really nice LCD, if only we could use it in a new laptop.



Just a standard USB cam.



Reinforced & soldered.

Unfortunately, these old cameras only do 4fps at 640x480.  320x240 in
complete darkness gets them up to 15fps.  The price goes up as frame
rate goes up.  Position sensing is going to be 1Hz, at most.



Finally caved in & got a Logitech C510 camera for only $40, locally.
Turns out the Logitech C510 actually goes up to 1280x1024 even though
it's only advertized at 1280x720.  No surprise why it was for sale &
discontinued.

In bright light, with minimum contrast, minimum brightness, 0
saturation, it'll actually hit 30fps at 1280x1024.  The reality is 15fps
is the most our simplest machine vision algorithm can process.

It spits out tons of bad frames on our desktop, but not on the laptop.
Lacking a way to disable auto exposure is a killer for machine vision.

The object of the game is to detect the center & size of an object.  The
only algorithm that seems to work, at a decent framerate, is luma keying
in a totally black room.  It's certainly good enough, since Marcy 1 can
only fly in total darkness, but developing in total darkness is hard &
we really want to fly other vehicles in daylight.

Flashing LED's would probably work, but Marcy 1 is constantly moving.



Don't turn it on.  Take it a apart.



The stand needs to go.



It definitely has the Auto Pilot look.

Focus is glued in place.





Put it on a pan/tilt platform to try to increase the field of view.  The
problem is it can't use difference keying, the servo movement is going to put a lot of noise

in the result.  A fisheye lens would be ideal.

 

Now we have video of the camera turret tracking the object, & how well
it tracks.  Marcy 1 got a 2nd LED to give the machine vision a bigger
target.  Even though the Logitech C510 can do 1280x1024, we found 640x480 to be

the most useful resolution with the turret. 

Discovered the brightness on the Logitech doesn't buy any more high end.  It
just clamps the white levels at lower values & reduces the size of the
JPG's.  If there was a way to lock the exposure, we'd be ecstatic.

Gigio (udrones) has added a great tutorial to the manual on how to add a pan-tilt camera mount to ArduCopter using Hobbyking parts. Total cost: about $57. Perfect for a GoPro camera.

AC2 defaults to autostabilizing the camera (tilt/roll servo outputs are one Out 5 and Out 6). We'll be adding the ability to automatically track a position on the ground soon.

                    To put everybody in context, this is the very first idea that I had

                    in mind and since picture worth a thousand words,

                    here is the battery exchanger initial concept:

                   Grabber arms, battery casings, electrical connections

                   and some flip-flop action strategy mechanism.

                   Here’s some interesting development aspects in pictures ……….

                   What we are interested in is to have the incoming VTOL precisely

                   positioning itself so that the SWAPPER does its job.

                  The last 10 inches are the most critical for mechanical final touch down alignment.

                  This is the first concept attempt to mechanically guide de VTOL in place.

                    In this case, the legs are guided by the conical receptacles.

                    And then, the concept evolved to this:

                            Earlier initial mechanical contact with the deck increases

                           the correction capacity.

                           The awaiting charged battery is protected from

                           excessive VTOL derivation on the axes.

                          This is the last evolution of the deck concept that I came with

                           The arrow show the derivation slop.

                           In fact this set up permit a YAW mechanical correction of 90 degrees.

                           I’am ending this first development report with what is coming next.

                          Getting some factual datas on this last 10 inches of

                          pre-landing bumping activity.

                         Some pictures of the testing material:

This document describes how to connect an ArduPilotMega with qGroundControl via USB (helpful for first tests of your micro controller).

ArduPilotMega

ArduPilotMega is an Arduino based Autopilot micro controller, programmable with C/C++. Arduino based stuff is nice, because it does not require much of hardware knowledge to get started.

qGroundControl

qGroundControl is is a ground station which can be used to fly a UAV/Drone and it can be used to visualize/test/log data from MAVlink compatible devices (for example the ArduPilotMega).

Preparing the ArduPilotMega

There is not much todo on the hardware side as long as you use the official firmware. At the writing of this post, APM 2.1.2 was the firmware used. It can be "flashed" with the Arduino IDE (using avrdude) or with the APM Mission Planner. You have probably already done this.


Secondly, you need to configure your plane. In my case it's a Multiplex funjet. My configuration looks like this.

APM_Config.h:
// -*- tab-width: 4; Mode: C++; c-basic-offset: 4; indent-tabs-mode: nil -*-// $Id$
#include "funjet.h"


funjet.h:
// $Id$
// NOTE: set dip 4 HIGH (for elevon mix)
//       http://code.google.com/p/ardupilot-mega/wiki/Reversing
//

// DIP Settings for Funjet:
// 1: LOW
// 2: HIGH
// 3: LOW
// 4: HIGH

// Servo channels
// 1: Left Elevon
// 2: Right Elevon
// 3: Throttle
// 4:
// 5: AP Control
// enable HMC5843 - Triple Axis Magnetometer Rev 1.2
#define MAGNETOMETER ENABLED
#define AIRSPEED_SENSOR               ENABLED// #define AIRSPEED_RATIO       1.9936
// ALTITUDE_MIX                             OPTIONAL
// Configures the blend between GPS and pressure altitude.
// 0 = GPS altitude, 1 = Press alt, 0.5 = half and half, etc.
//#define ALTITUDE_MIX       0.5


Once you have compiled and uploaded the code and your configuration you are ready to test sensor data in qGroundControl. Note that no special configuration is needed for the MAVLink protocol on the APM side (as of V 2.1.2) which communicates with qGroundControl.

Make sure that SW2 on the APM is set to flight mode (turned to flight direction) and connect APM via USB cable to your computer.



Flight Mode

You might first test if the APM is sending some binary output over USB. To do this use your favorite terminal program (like hyperterm.exe, minicom or Arduino IDE's Serial Console).

When verified that the binary serial output is sent, start qGroundControl and click on the "Connect Link" Button. The default settings are reasonable, make sure using 115200 baud and select your serial port.

Now change to Engineer's view. You might not get any data yet (left panel with sensor options is empty). In this case APM does not yet know what to transmit. Make sure the «Calibration and Onboard Parameters» widget is shown. Insert 3.3, 10 or 50 Hz in all possible data streams. I read that 50Hz is preferable because the main loop of APM runs on 50Hz. If it causes problems with the serial connection, a lower frequency might help. As soon as these values are set, they are stored in the APM's EEPROM. So these values are present after a reboot of the APM which (I think) is a really nice feature.

That's it, have fun.

Gary Mortimer passes on sad news:

The Washington Post reports the death of Maynard Hill an inspiration to so many in the sUAS world. Our condolences to his family

Maynard Hill, a designer of model airplanes who secured a spot in aviation history in 2003 when one of his creations flew 1,882 miles across the Atlantic Ocean on less than a gallon of fuel, died June 7 of prostate cancer at his home in Silver Spring. He was 85.

A balsa-and-glue virtuoso, Mr. Hill was a legend in the model-aircraft world even before his first-of-its-kind transatlantic feat. Beginning in the 1960s, he set a total of 25 world records for speed, duration and altitude, flying his radio-controlled aircraft as high as 26,990 feet, as long as 38 hours and as fast as 151 miles per hour.

Read the full article here

One of the most commonly-used features in pro UAVs is point-and-click mission control in real time. Rather than just pre-planned missions or manually flying the UAV, operators can just click on a map and say "go here now". 

Good news: we've now implemented this in APM. If you update to the latest Mission Planner and APM code, you can right-click on the map in the GCS and just select "Fly To Here". The UAV will fly there and loiter until you give it another command. We call this "Guided Mode". There are more commands coming in this mode soon, but the functionality is now built-in.

We'll be implementing this in ArduCopter 2 before it comes out of beta, too. Go Guided Mode!

[UPDATE] Team leader Doug Weibel explains how it works:

"Guided is a separate flight mode. If you enter it you will remain in it until you do something to change modes. So if you tell it to "go here now", once it arrives there it will loiter at the Guided waypoint till you tell it to do something else. Something else could either be going to another Guided waypoint (staying in Guided mode) or changing to some other flight mode. If you change to Auto your mission will resume where it left off."

Via Slashdot, here's a story with interesting videos about a group from Boston University.  There's a lot of interesting details about their build and in-the-field fixing.

The Brazilian Free-tailed bats above  (also called Tadarida) come together in the millions in caves all over Texas, leaving every night in swarms so big they can be detected by doppler radar. Somehow, they manage to fly through this dense self-clutter without major collisions, and so our goal is to better understand this behavior. For the AIRFOILS project, the IML team created the previously mentioned Batcopter. The goal was to fly a UAV through the dense clutter, and record the bats’ response with three ground-based high-speed FLIR cameras and an airborne 3D HD GoPro camera. The hope is to extract fundamental control laws of flying behavior in order to achieve better autonomous UAV flight.

 

 

 

I really enjoy making FPV videos. But recently we started producing and selling our aircraft to customers around the world, which has taken up so much time it's hard for us to produce enough videos to fit our weekly schedule. So it's very refreshing to see that at least our customers are having fun :) These are a couple of clips from two of our first customers doing their first ever FPV flights (zero prior FPV experience!). Enjoy!