I have not posted up anything in a month so thought I should give an overview of what I've designed. Unfortunately I have hit a LARGE snag in that BatchPCB is basically broken for international orders as no shipping options appear and so you cannot buy anything (its been like this since January). 5 months of waiting to produce these (no international shipping) and I'm pretty fed up, frustrated, shocked and losing faith so here for at least a quick look are my current plans.

First off I've been designing a quad to be smaller than ArduCopter but still hold everything so I can develop my camera stuff more quickly. It changed from basically a clone of ArduCopter to a slightly bare version to its current incarnation which is basically board holders with arm holders. The entire design has mounts for everything in the ArduCopter kit as well all the extras (pan and tilt, optical flow sensor(s), sonar, magnetometer, telemetry). As I progress with the build (or hopefully finish it with ease) I will update on here but the picture above is the progress so far including the 360° pan and 120° tilt bracket with sonar mount.

Now for my designs that I seem to be perpetually waiting for. All pictures are animated GIFs that ning apparently hates.

Optical flow boards

1. ADNS - 2610 with ATMega328 for translational and I2C communication with APM
2. ADNS - 5050 with ATMega328 for translational and I2C communication with APM
3. ADNS - 5050 with ATTiny85 for translational and I2C communication with APM
4. ADNS - 3080 with ATTiny85 for translational and I2C communication with APM

5050 seems to be the best sensor for our needs compared with the other two as the 2610 isn't available in the UK and the 3080 is 20 pin rather than 8 and only marginally better.

4 of these on my quad should hopefully stop it hitting walls. I'm hoping to create a library for these so they can be called for navigation easily like the rest of the I2C hardware for APM/ACM.

ACM distribution boards (4in² each).

2x two layer boards

1. Power distribution below
2. ESC distribution separating out the BEC 5V supplies to use for other things

Nothing new here but anyone fancying a smaller quad might find it useful.

ArduSlave boards (pictures aligned over I2C pins to compare size).

1. I2C controlled ATMega328 with PWM outputs only
2. I2C controlled ATMega328 with all pins broken out
3. I2C controlled ATMega2560 with all pins broken

I am hoping to get the PWM only board done so it can be used as camera control circuit over I2C. The idea being to offload the computation to the 328 so the APM can do what it does best and keep your plane/copter safe while the ArduSlave will sort your pictures. Of course the other boards could do this and much more given the extra channels.

Synthetic aperture radar system (I did say I was working on a different imager).

1. Bottom board is the analogue section for it with power regulation, ramp generator and amplication leading to stereo jack to plug into a laptop.
2. Top board is the RF section using SMD devices instead of coaxial devices to save space.
3. Combined board to show how it fits.

2.4GHz with 240Mhz bandwidth in a FMCW configuration. Record the "audio" and process with MATLAB.

I intend to record the audio onto an SD card after finding a suitable ADC as described in the picture. I already know this as a coaxial system works but as I'm using SMD I've probably borked something plus having a laptop in an Easystar isn't easy so once I've found a good ADC to save the "audio" that will deal with the laptop problem. I'll just need to develop a system on a different frequency so it won't make my plane crash :D

Interested in SAR? Think I'm mental? Want to see why I think its possible? Follow the links HERE, HERE, HERE and HERE.

Here is an edited version of the MITLL IAP course lecture powerpoint (it now includes the bill of materials).

The FY21AP is a stand-alone autopilot system with FY-AFSS algorithm, GPS receiver and barometric sensing equipment. It is fully upgradable with OSD, telemetric digital communication, Data Modem and Ground
Station Control (GCS).

The flexible layout makes this the most versatile autopilot system in the market, designed for beginners, UAV operators and professional RC aerial photographers.

Features:

Internal use high-performance ARM processor, high stability.
6DOF IMU (3 accelerometers, 3 gyros)
10Hz GPS accurate location
Combining GPS and the barometer fix altitude accurately
complete OSD telemetry information display
Optional GCS software , monitor flight trajectory in real time
LED display for flight mode
strong anti-interference ability
Auto return to base in case of signal lose

There are 2 versions available, one with OSD and one without OSD. For more information, see the the specific product pages (price that you find on website maybe lower, the price depends on your membership level at Hobbyking):

FeiYu Tech FY-21AP with AP117 OSD module - Price: US$ 355.00

FeiYu Tech FY-21AP (no OSD module) - Price: US$ 258.00

Feiyu Tech AP117 OSD (With GPS) - Price: US$ 138.00

http://www.hobbyking.com/hobbyking/store/catalog/HKY-21AT.jpg

All in one (4)ESC's and PDB,  $89

Get all that messy wiring out of the way.

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.

Maybe this camera I found on the web would interest fellow aerial photographers.

It apparently doesn't weigh more than 85g, can take up to 1080p and it looks like a easy camera to fit on a plane compared to a bit more bulky GoPro.

It doesn't have a fisheye lens either, (is that a good thing or not?) 

It looks like it's still on pre-order, so I can't fiend any proper reviews yet.

Here is a link to the product site.

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 bought a cheap RC Futaba T7CP on ebay, but I spent 3 days in order to understand the right configurations of switches to enable 6 flight modes.
Here, my solution. Hope useful for the community.
(I used some hints from other blogs)

1. I used SWE and SWA. SWE is a 3-position switch. while SWA is on the left and it is a 2-position switch

2. You have to set End Point, SubTrim and RT in MIX. First, set the ENDPOINT for CH5 to be 50%(UP) and 52%(DOWN). You can tune the values until the pwm value(see point 5.) are right.

3. Then, set the SUBTRIM for the GEAR (CH5) to be 100%

4. Configure a P-MIX ( I used P-MIX1) to be without offset, and with the following rates: 24% and 60% (You can switch between the rates by using the 2-position switch)

5. Exit (END button) and check the pwm values in CLI->test->pwm.

6. Configure you radio in CLI->setup->modes

NOTE: Maybe, in order to not mess the radio setup, you have first to setup radio channel: CLI->setup->radio

I attach some pictures for sake of clarity.

Regards to everyone

1. First set the endpoint for Rudder (CH5)

2.Then adjust the GEAR of CH5

4.Finally, set the mixing program.  I choose P-MIX1

5.Set the Master and Salve Channels (I used for Master CH7 and for slave CH5). Set the 2 rates : you can switch between one and the other by toggle the A switch

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

This week I took the Modular Test Platform (MTP) for it's maiden flight, I can't tell you how nervous I was to give it it's first throw, or how excited I was when I saw flying through the air! You all probably know what I mean.

I got 2 or 3 "OK" flights in (20-30 seconds) before it had gotten beaten up enough to not really fly anymore. With each crash though, I was expecting more damage, but those wooden dowels really add a lot of strength and rigidity, while the foam and hot glue give it some flexibility. Eventually, the motor section got so crushed that the motor was too unsecured to make additional flights.

The needed improvements are:

1.) Improve CG: at first it was tail heavy, causing the airplane to "high alpha" and not allow the wings to really generate lift. As I moved the battery toward the nose to shift the CG, things got better and better.

2.) Reduce control surfaces: even the smallest movement of my transmitter sticks would make the airplane almost lose control as it exerted a LOT of force. Either (or both!) the control surfaces need to be reduced in size or the throws need to be reduced.

3.) More power: the brushed motor, 10C NiMh x 7.2v battery, and 10 amp ESC set up has got to go. It was taken from a wild hawk, and while functional, the power system is heavy, weak, and inefficient. The new system will have a brushless motor, 20C 11.1v LiPo, and 30 amp ESC. I've already bench tested it and it has at least 5 - 6 times the thrust.

4.) Wing incidence: I also think adding a little angle on the wing will add natural stability and climb.

Next week I'll be making these and other improvements to the MTP. Anything I've missed?

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!

 My last blog post on this subject was incomplete. Now I have photos I actually built and tested it. 

After reading a recent blog I have decided I REALLY need to get out there and fly this year. I spend far too much time in front of my computer... So thanks to Max Levine's wonderful blog, http://diydrones.com/profiles/blogs/ardupilotcopter-mega-6 I've decided to go ahead and modify my Turnigy 9X to add a 6-position switch. This is going to be more or less a mini-build log as all I've done so far is order the parts....and they're all available from a single supplier, so save money on shipping!!!

Again, props to Max Levine for his original blog on this topic.

Parts ordered (the resistor values came from an experiment with a Turnigy 9X and potentiometer):

(1) X ALPS 6-position switch = $7.06/ea or (1) X ALPS 6-position switch = $9.40/ea

(1) X 6mm knob = $0.59/ea

7 resistor solution:

(1) X 1.3K ohm resistor - $0.11/ea

(5) X 1.5K ohm resistors = $0.11/ea = $0.55

(1) X 1.0K ohm resistor = $0.15/ea

5 resistor solution:

(1) X 2.8K ohm resistor = $0.15/ea

(3) X 1.5K ohm resistors = $0.11/ea = $0.33

(1) X 2.5K ohm resistor = $0.15/ea

EDIT Sorry to keep changing the resistor values on you, but I'm trying to get as close as possible to the middle of the band for everyone. AR Projects read a min and max of 1085 and 1921, where I read a min and max of 1047 and 1878.

Current Cost (not including shipping all ordered from Mouser.com) = $8.46

Shipping is "estimated" at $6.40 so I'm in for $14.86 so far.

For those that don't want the hassle, you can buy a 6 position switch pre-made from one of our fellow DIYdroners - AR Projects - http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120731012907&fromMakeTrack=true&ssPageName=VIP:watchlink:top:en

UPDATE 6/11/2011

I didn't wait for Mouser to get the switch in stock, so I ended up spending $9.40 including shipping to get the switch from eBay. If you can wait, the original price of $8.46 plus shipping still stands. If not, you're looking at $3.40 for the knob plus $6.00 shipping and $1.40 for the resistors and knob plus Mouser charged me $5.20 in shipping. Total cost with shipping was $16. If I could have waited I would have saved about $2.00 on the total cost.

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140481713934&ssPageName=STRK:MEWNX:IT

These are the target and actual PWM values achieved using 7 resistors. (6) 1.5K and (1) 768 ohms

Pos 0: <= 1230 = 1165 Target - 1175 Actual
Pos 1: 1230 - 1360 = 1295 Target - 1300 Actual
Pos 2: 1361 - 1490 = 1426 Target - 1431 Actual
Pos 3: 1491 - 1620 = 1556 Target - 1555 Actual
Pos 4: 1621 - 1750 = 1686 Target - 1684 Actual
Pos 5: >= 1750 = 1815 Target - 1811 Actual

That's about as perfect as it can get.

ADDITIONAL NOTES:

A few things worth mentioning during the "build."

1) Before you try to solder the wires going to the switch, take a pair of large cutters and trim off the bump on the switch. If you look at the top of the switch, you'll see a keyed piece of metal that would be used to keep the knob from rotating, if the plastic housing was designed for it. If you try to clip it after the fact, you may run the risk of breaking off a resistor like I did.

2) Take an x-acto knife and ream out the hole a little bit. The threads on the switch won't go through otherwise.

3) The radio case will be a bit tight to get back together in the corner where you installed your switch. I forced mine ever so slightly....but I could have done a better job cutting the metal tab off my swtich.

Model airplane crash leads to local lawsuit

Not much in details but the Star Press Article is available here.

  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.