Blogs

Through the eyes of a CCTV security system-

Robot Magazine July/August 2013

Arxterra envisions Telerobotic Parks that can be explored from your living room, using your browser and the computing power that already exists in modern smartphones. High bandwidth wireless internet and rugged rovers "will intrigue and challenge makers, robot enthusiasts, and adventurers,"Arxterra predicts. The Arxterra Pathfinder Mission plans a launch in southern California just south of Quail Lake, where robots will join the rich fauna that includes badgers, racoon, prong horn antelope, black bears, bob cats and many more among the diverse wildlife. Shown is the rover prototype. Learn more at  http://www.arxterra.com/

NEW APM 2.5 Pin out and Wire Diagram And Camera Gimble explanation
Hey guys i recently got the APM 2.5, when looking at the pins, I saw A0 - A11 Pins werent being used and i did not know what they were for so i was googling and found a PDF that stated

A0- Sonar/ Ultrasonic A1- Voltage Sensor – Attopilot
A2-Current Sensor – Attopilot
A3- Optical Flow Sensor
A4-Motor LED
A5-Motor LED / Buzzer
A6-Motor LED
A7-Motor LED
A8-Motor LED / Analogue RSSI
A9-Camera Shutterhttp://speedtester.bsnl.co.in/
A10-Camera Roll

Link to Gimble explanation in google
http://code.google.com/p/arducopter/wiki/AC2_Camera

So After researching for some time, I have found that for a camera gimble A10 is roll and A11 is pich but there was no explanation of were Pan is connected (YAW).So I i dug some more and found some consensus to the following :
Currently Mission Planner shows that we have 3 axis so would be good to update that. I suspect (haven't check the code) that PAN goes to A9 but that is just a guess.
Anyway, I lack one wiki page on those extra outputs, what can be connected to them. So we have A11, A10 (and A9?) for gimbal, A1 and A2 for AttoPilot? current/voltage sensor:.

So after my post was denied several times as being " a request for assistance" let me rephrase, What is your guys experience, have you tried A9  and it worked or not, what other solutions have you tried?

Here is more info: http://copter.ardupilot.com/wiki/camera-mount/

Here's my 1st mapping test flight with a Skyhunter twin-boom pusher. Im running Arduplane 2.73. Mapping camera is a Canon s95 running an intervalometer script via chdk. Its suspended from a single axis gimbal that keeps the camera pointing down regardless of aircraft bank angle. Video shot from a GoPro 3 Black Edition.

It took 120 photos during the 10 minute flight, and stitched with PT GUI. I need to refine my grid spacing and polygon locations relative to the target area, and intervalometer timing. The generated map is a little rough, but its a great start.

 I gave up on using the APM trigger at 3m from waypoint function as I couldn't get it to work and there's just no documentation on it.

 
When Richard Van As, a master carpenter in Johannesburg, South Africa, decided to make a set of mechanical fingers, it wasn’t just for fun. He’d lost four of the fingers on his right hand in an unfortunate work accident. For a tradesman like Rich, having a disabled hand is a big professional detriment, so Richard decided on the day of his the incident that he would use the tools available to him to remedy his situation. Watch the inspiring video above to hear how Richard’s project, Robohand, is changing lives with patience, spirit, and a MakerBot Replicator 2.

Getting Started

MakerBot heard about the Robohand project in January 2013. Richard had been trading ideas with Ivan Owen, a collaborator in Washington State, for several months. Ivan used his prior experience with mechanical prop hands to make design suggestions, while Richard attempted to replicate the designs in his workshop.

The process was taking weeks and months per cycle. For us here at MakerBot, that was too much wasted time. We knew our 3D printer, the MakerBot Replicator 2, could take this important work to new heights. We saw their collaboration and the work they were doing as groundbreaking, and we asked Ivan and Richard to accept a donation from us: a MakerBot Replicator 2 for each of them, one in Washington, and another in South Africa.

If the tool was useful to them, we hoped they would share their work on Thingiverse.com for the world to download. It turns out the MakerBots were incredibly useful, and the guys have followed through on their promise. Just hours after they received their packages from us here in Brooklyn, the two collaborators were sharing files back and forth, testing the design in one place and doing another iteration on the other side of the world. Richard says it took the prototyping process down from weeks to just 20 minutes.

But that’s only half the story.

Giving A Hand

Robohand has grown far beyond the goal of making a set of fingers just for Richard. When the power of desktop 3D printing and MakerBot entered the picture, Richard began to realize how quickly he could refine a design for other people who have lost their fingers, or who were born without fingers. After posting his own story, he received emails and Facebook messages from parents whose children were candidates for a Robohand of their own. One of these children was five-year-old Liam.

The condition Amniotic Band Syndrome is poorly understood, but the effects of it are pretty clear. Children are often born without extremities, especially fingers and toes, when fibrous bands in the womb prevent these parts from developing normally. It’s this condition that caused Liam to be born with no fingers on his right hand. The cost of purchasing a traditional prosthesis was far too much for the family, especially since Liam is a young and fast growing boy who would outgrow a prosthesis in a few months.

Liam was given a Robohand just days after Richard and Ivan received their MakerBots in January, 2013, and he has already been fitted for his second. The word spread, and other kids in the Johannesburg area like Liam with Amniotic Band Syndrome have received their own Robohands, sized just for them. The files, including the assembly instructions, have been posted online at Thingiverse, and they have been downloaded over 3,800 times by people around the globe.

What Is A Robohand?

A Robohand is a set of mechanical fingers that open and close to grasp things based on the motion of the wrist. When the wrist folds and contracts, the cables attaching the fingers to the base structure cause the fingers to curl. Nearly all the parts of a Robohand are 3D printed on MakerBot Replicator 2 Desktop 3D printers.

Ivan, who played a big part in the initial design stages of Robohand, says he studied the anatomy of crab legs and human fingers to get the basic muscle and tendon structure. The result is a simple assembly that Richard believes anyone can make themselves. While a full set of prosthetic fingers may cost thousands of dollars, all of the Robohand parts that are made on the MakerBot Replicator 2 add up to roughly a few dollars in material cost, with the total mechanical hand costing around $150 (USD).

Who Needs A Robohand?

Amniotic Band Syndrome affects 1 in 1,200 live births.

About 80% of cases of Amniotic Band Syndrome involve the loss or malformation of fingers and hands.

Finger amputations are the most common amputation in the US, accounting for over 90% of all amputations, according to various reports.

How Do I Get A Robohand?

Robohand was not imagined as a service or a product. Instead, Richard has shared the design files and instructions for creating a Robohand on Thingiverse so that people around the world can download, customize, print, and assemble Robohands for themselves or for others.

So far, we’ve heard stories of Robohands being made for children and adults in the US, Canada, and Thailand. Are you a MakerBot owner who can give this incredible gift to someone in your community?

Get Involved

There’s still a lot to be done. Richard has given hands-on help to a few of the people within his reach, but Robohand needs your help in order to get to the people who need it most.

● Want to spread the word? Share this video with your friends on Twitter or Facebook.
● Looking to to support the cause? Check out Robohand’s Indiegogo campaign.
● Are you an occupational therapist or prosthetist? Leave a comment below!

Make a Robohand

The design files and assembly instructions for Robohand can be found on Thingiverse.

Robohand’s creators would like to empower others around the world to use their files and create and print in 3D Robohands of their own, and they are not in the mechanical hand business. They created Robohand out of the goodness of their heart. Now it’s time to provide the files to the world and see what other good can come from them!

Robohand uses the following tools to make their mechanical hands:

● MakerBot Replicator 2 Desktop 3D Printer
● MakerBot PLA Filament
● Stainless steel hardware
● Thermo-forming orthoplastic
● Elastic bands
● Nylon cable

The full bill of materials is listed here.

Original blog post : http://www.makerbot.com/blog/2013/05/07/robohand/

Domestic Use of Drones

...left with a cliffhanger: are you allowed to shoot down a drone if it's over your "airspace" (very end of the video)?

Testing out how the new Y6 responds to an in-flight motor failure. Not bad!

Dear Friends,

after one week of work to first sample of electronics , we are ready with workspace enviroment for developer that want join our team.

Electronic Specification: 

In VR Gimbal We decide to use this kind of electronic parts  :

• as micro we use STM32F1 64 pin.
• 1 MPU6000 + HMC5883 for Z axis Direct Drive CAM using i2c bus.
• 1 MPU6000 on spi bus. for Roll and Pitch cam.
• EEPROM for storage the parameter of gimbal.
• 3 ST Driver for manage 3 Brushless Motors with 9 Hardware PWM Output.
• 1 input for Ublox GPS.
• 4 PPM Radio Input or 1 PPMSUM radio input until 8 channel or more.
• 1 Telemetry port for mavlink control.

As developer enviroment we use VR Ide Universal (based on eclipse) compatible with VRBRAIN and MP32 board now also with VR GIMBAL.

The developer lib and hal at the begin will be compatible with our APM_LIB ported to STM32F1 library the same used on MP32F1 board. 

That support all the APM library available and arduino language sintax .

In our code we decide to port on VR Gimbal :

• AP_COMMON
• AP_VAR
• AP_InertialSensor
• AP_IMU
• AP_Camera
• AP_Mount
• Mavlink

and other utility yet available on our standard F1 package ... 

We would develop also a utility for manage the board on pc and on android smartphone.

If you are interest to join our work in developing stage will be a special price for you of 75 euro for 3 axis control board + 15 euro for IMU  (at the moment is available only 20 board) .

Your name will be in the list of developer of this project. The code will be opensource as other in this great community ... the support in development and donation are welcome .

For more info about the project contact me at info@virtualrobotix.com

In our roadmap the first  stable version of code will be available in 1 month. 

In the next week will be available the enviroment , with hal and library , then starting to implement the code functionality for manage the first opensource 32 bit 3 axis direct drive.

I hope that you like our project and join us in development.

In VR Lab mecatronix group are working hard and is yet available a good gimbal for GOPRO

And also is coming Gimbal for pro and semi pro camera.

I hope that you like our work :)

for more info and join us : http://www.virtualrobotix.com/group/vr-gimbal-user-group?xg_source=activity 

Best

Roberto Navoni

FPV flying my 3DR quad in Discovery Park in Seattle. I was able to get behind trees and still get a crisp video signal to the goggles.

Gear:

NAZA w/GPS

5.8ghz Video tx/rx

GoPro 3 Silver

5000mah 3S battery

Fatshark SD Base Goggles

Using Quadframe US landing gear with vibration dampeners

We went and filmed the repair works of the stranded Costa Concordia.

Thanks to everyone for your awesome input on our first post! Several of the tips we received have had a strong influence on our development path. We are already working on a radical redesign for our Mark III prototype that will incorporate some of your suggestions.

Where we left off:

Our last prototype had some semi-successful results. Mark I, which we now refer to as the “Tank” was much too heavy. After stripping it down we were able to get it into the air and shoot some decent footage. However, flight control was sluggish and somewhat unpredictable.

So we designed Mark II “Skeleton”

Pictured above you can see Mark I “Tank” and Mark II “Skeleton” side by side

For this version we made several major changes to the design:

• Used a skeletal approach to the frame design

  • Removed as much metal as possible

  • Shortened the entire frame by 3 inches

  • Used 1/16” metal instead of ⅛”

• Added multiple weight compartments

• Simplified gimbal mounting

  • Spread out the placement of vibration mounts

  • Reduced number of plates

• Moved battery onto the gimbal

Before we designed our new “skeleton” frame, we performed some rigidity testing on 1/16” aluminum. We found that as long as we kept support spacers within 3.5 inches of each other, 1/16” aluminum would be rigid enough to support the gimbal.

We also did some testing to determine optimum GoPro placement. We found that in order to maintain a clear field of view with the widest angle video setting, the GoPro could safely be placed nine inches from the center of the copter. This allowed us to shorten the entire frame by three inches.

We also refined our gimbal balancing approach.  In Mark I “Tank” we tried to selectively cut out metal to balance the gimbal.  Ultimately we had to add a stack of washers onto the back in order to balance everything out. We felt that this was not an elegant approach and the washer stack was rather ugly. So we removed the extra metal, and then designed several compartments for washers. This gave us more flexibility in balancing the gimbal while maintaining our design aesthetic.

On Mark I “Tank” we placed our vibration mounts close together. This created an unintentional joint and the gimbal had a fair amount of play which caused a swaying motion in flight. In response to this problem, we decided to spread out the vibration mounts. This greatly simplified the way our gimbal attached to the Hexa frame by allowing us to remove several heavy aluminum plates.

As many of you pointed out, moving the battery onto the gimbal is a much more efficient use of weight for balance. Coincidentally our 7 ounce battery approaches the weight needed to balance the GoPro carriage on the opposite end of the gimbal. This also allows us to keep more weight below the vibration mounts while lightening the overall payload of the Hexa.

With all of these changes designed into Mark II “Skeleton”, we sent it off to be cut out of 1/16” aluminum!

Our machinist was gracious enough to send us some pictures of the CNC Router used to cut our gimbal parts.  In the image below you can see the cut marks from our plates in the backboard. There are some more pictures and info about CNC Routers on our blog here.

The Results:

Mark II “Skeleton” is 40% lighter than Mark I “Tank”!  Including the battery, our new payload weight is 36.25 ounces (2.66 lbs.) down from the previous payload weight of 56.75 ounces (3.55 lbs.)

When we took to the air it was immediately apparent that the Hexa could easily handle the new payload weight and maneuver smoothly.

How was the flight and footage? Check out this video and see for yourself. Please Note: This video showcases clips from the GoPro that are unprocessed, as well as clips that have been processed. The processed and unprocessed clips are indicated by text in the upper right corner.

As you can see, we were able to fly for a reasonable amount of time with this payload weight. We were airborne for around 6 minutes and still had some charge left on the battery.

The level of vibration in the footage was encouraging. We put 2 clips through the Adobe After Effects Warp Stabilizer filter in an effort to easily identify the “jello” distortion in our footage.  We were pleased to see that there was little to no distortion present. We appear to be isolating the GoPro from the high speed micro-vibrations generated from the spinning motors.

Our footage is still suffering from some macro-vibrations. We believe there are two main  issues. First we need to balance the props and design some new mounts that will dampen the motors vibrations directly. We have noticed some warbles in flight even when the gimbal is not attached.

Second, we need to look into fine tuning the servo response time. We’ve noticed a rocking action in the video when the Hexa quickly accelerates from side to side. It appears to be a result of servo latency.

What we’ve learned from this prototype:

• It flies!

• Acceptable level of controllability

• Reasonable amount of flight time, 6+ minutes

• Decent raw footage

• Little to no “jello” from micro-vibrations

• Issues with macro-vibrations

• Roll servo response time issues

• Could be even lighter

Where are we now?

True to form we are ready to confront our next challenges.  We are already designing our Mark III prototype. For this next iteration we are considering a radical redesign:

• Moving the pitch axis to the center of the gimbal

• Dropping the “H” frame for more of a single “I” beam approach

• Getting rid of all the ServoCity parts

• Isolating the motor mounts

• Researching composite materials other than aluminum

• Building a neutral density filter mount for the GoPro

Stabilization:

On our first post, several commenters suggested moving the pitch rotational axis from the GoPro Carriage to the center of the gimbal. We have been looking into this option and believe that it may help us in several ways.

Firstly we can get rid of a lot of the hardware needed to rotate the GoPro carriage. Secondly it will allow us to drop the “H” frame and go for a much simpler “I” beam shape. Thirdly, as several commenters pointed out, this puts our axis on the balance point, which means gravity will contribute towards keeping the gimbal level.

Further Weight Reduction:

While we’ve been very happy with the ServoCity parts, they do add a significant amount of weight. Our new goal is to design a direct drive system that is strong enough to support the chassis so we can disregard the heavy aluminum servo blocks.

Vibration:

We’ve also learned that isolating the gimbal alone will not solve all of our problems.  This is why we’ve decided to design some anti vibration motor mounts in an effort to attack the problem at its root. Hopefully our mounts will provide the solid, rigid mounting needed for the motors while providing some vibration isolation for the Hexa frame.

Materials:

We are in the process of investigating some of the materials that were suggested to us by the commentators of our first post. We are very interested in Garolite G10 as it looks to have the strength-to-weight characteristics we are looking for without the high price of carbon fiber.  However, it’s more practical for us to continue building our prototypes with Aluminum for now.  Once we are satisfied with the functionality of our design we may experiment with Garolite.

Reduce Video Distortion and Improve Picture Quality:

We are also considering the addition of a neutral density filter for our GoPro. As we have been researching the reduction of video distortion in GoPro footage, we have come across several references to that fact that the “jello” effect is less severe on cloudy or darker days. This is something we have seen in our own footage as well.

If you are interested, have a look at our blog post: Neutral Density For The GoPro in which we go into more detail about our hypothesis and how ambient light levels augment rolling shutter distortion.  We’ve summed up our theory below. Unfortunately we’ve been unable to find any concrete information on the subject.  If anyone can provide some additional input we will be greatfull!

Our Theory:

The GoPro uses a CMOS sensor which scans through the entire frame at a fixed rate. This means there is a fixed amount of time required to read the entire sensor. On a very bright day this could lead to a significant time gap between pixel sampling as the exposure time in that situation is very short. This would also lead to a very sharp exposure for each pixel. However, on a darker day the exposure is longer and each pixel is sampled for a longer period of time. This would increase the motion blur of the pixels and a reduction of time difference between pixel sampling. Both of those factors could cause the captured image to be more blended between pixels thus reducing the amount of “jello” distortion visible...

... One way to force the GoPro to use a longer exposure time on a bright day is to basically put sunglasses on it. A neutral density filter is a material that will reduce the amount of light that enters the lens without distorting the color of the image.

In an effort to test our theory, our next prototype will include the ability to insert neutral density filters of different F-stop levels onto the GoPro carriage.

Here is the part where we need your help!

We would very much appreciate any input and or experiences you can share with us regarding the following items:

• Motor isolation/dampening, what has worked for you? Problems?  Limitations?

• The use of neutral density filters with a GoPro, has anyone tried it? How did it work for you?

• Do you know of any supply sources for composite material, especially Garolite G10? Where have you ordered from and what was the experience like?

Though we are very encouraged by the latest results of our test flight, our work on Mark II “Skeleton” has taught us a lot and we still need to refine and improve our design. We are now turning our efforts onto Mark III and look forward to sharing our progress with you soon.

We will continue to post our major milestones here on DIY Drones.  If you are so inclined, you can also keep up-to-date on our incremental progress via our blog: http://www.skyrisfx.com/mission-updates/

Cheers!

-Jeff and David

www.SkyrisFX.com

Echoing a company belief in autonomous systems, clever algorithms, and replacing fallible humans with smart machines, Google's venture capital arm announced yesterday that it is investing $10.7 million in a company that makes drone brains.

AirWare's osFlexQuad

Full story at Popular Science

And also reported here: TechCrunch

Google has some history with UAVs - presumably for mapping. As well as considerable work in autonomous cars. $10.7M is pretty much a rounding error to Google Ventures, but it is an interesting bet for them.

An MD-200 Quadrotor Two years ago Google purchased one of these quadrotors from German manufacturer Microdrones wikimedia commons

These high-tech models help the geologists to criss-cross the landscape, not unlike what you will find on Google Earth. This virtual fieldwork enables the researchers to gather information on anything from the type of rock to the thickness of the sedimentation; all with the help of a few mouse clicks on the computer.

– A landscape’s surface often reflects what lies beneath ground and corresponds with the rocks below the seabed. When we have an overview of the rocks and minerals in one area, it is far easier to make estimates about where to find oil and how the oil flows, says Simon Buckley, senior researcher at CIPR and head of the VOG group.

Quick and affordable

So far, the researchers have used ground-based laser scanners (LIDAR), infrared sensors and cameras to replicate the landscape. But putting instruments on the ground is both time-consuming and limited to lower ground areas.

In higher elevations in the shadows of sensors, for instance behind rocks or high mountains, the researchers have had to mount the cameras and laser sensors to helicopters, which they have leased.

– Using drones is more affordable. All places can be reached quickly and you can shoot in inaccessible areas, Buckley explains.

Pictures shot with the help of a drone complement the images from low-level terrain that the researchers already have in hand. The end result is more precise and complete 3D models.

– The aim is to bring all models together to get the best possible geological map of an area, says Buckley.

The use of drones in the search for oil is similar to techniques used in Switzerland and Germany to look for minerals. The models created by the CIPR researchers can also be used for research on CO2 storage.

– It isn’t hard to collect a point cloud of laser readings and present these. The challenge is to use the data for geological analysis, Buckley points out.

A helicopter in the office

The drone is operated from the ground just like a radio-controlled plane, shooting images of the earth’s surface from the air. The pilot on the ground also operates the camera.

There are plenty of restrictions in place, though, and not anyone can fly a drone. Norwegian aviation authorities put strict regulations on anyone wanting to use drones for research. Aleksandra Sima has been practising in a flight simulator and has tested mini helicopters in her office.

– The worst thing that can happen is that a drone crashes and hurts people, says Sima before reassuringly adding. – But we won’t be flying drones in populated areas.

(Translation: Sverre Ole Drønen.)

http://www.uib.no/news/nyheter/2013/05/the-drones-of-oil

In order to keep you guys updated on the project's development, I'm happy to present our first flight report!

Andy and his "tripod mop"; Jonathan conducting pre-flight-tests.

The weather conditions were decent: not all that much wind, clear sight and no random short-lived rainfalls.

As we weren't exactly convinced of last video's quality (shaky camera syndrome anyone?), we decided that this had to change. Voilà, enter the floor mop. Although rather unconventional, it makes for a surprisingly useful tripod!

The flight itself was as we had hoped: the wingcopter responded well, the handling was easy.

During the first section the tilt-angle was set at 90 degrees. In the second one we flew with a 45 degree angle. Both configurations performed as expected and without any problems. 

Some of you might have noticed a difference in the tilt-angles between the two arms in the latter stages. The reason was one of the nuts deciding to bail, resulting in one of the arms not being fully fixed anymore. We only noticed after the flight though, apparently someone up there seems to like the project as well xD

Slight disbelief, that was a close one! Memo to selfs: Better fix them with some glue. 

In order to provide a close-up look at the tilting mechanism in action, we made another video.

We hope your enjoyed our little report, we are planning to do them regularly from now on. Feel free to tell us if you liked this one and if you have any suggestions regarding improvements.

Regards,

Andy and Jonathan

More information on wingcopter.com

In true DIY form I am using as much readily available material as possible. 3/4" oak frame, lego parts, etc. I am on the lookout for landing gear materials (small diameter PVC with small caster wheels maybe? Hmmm.).

I am still building and tuning, so please excuse the loose wiring. When I am done tuning, I will neaten things up. Notice the flanker lego pads for future expansion and additonal equipment (FPV).

This is a picture of the "undercarriage" where the lego battery holder is located. Everything to this point is glued and screwed.

Lego battery connector epoxied to battery.

The lego battery holder base is epoxied and screwed to the frame. I have not only epoxied the lego battery connector to the battery but I will also zip tie the battery to the lego battery holder base for redundancy.

Voltage alarm "legoed" to frame. Receiver is also "legoed" to frame below the KK2 board and power distribution board both of which are secured to lego base with nylon screws.

I hope to be done tuning this weekend. Please watch for the maiden voyage coming soon on video.

Joe

The last week or so we've spent porting a version of the AeroQuad AQ32Plus code over to run on the AshimaCore board. One of our goals has been to get a common board that can run (or has the hooks put in place to run) several of the more popular open source flight controllers. Here's some video (why did we do this at night?) of us flying on our own old aluminum frame and on a couple of different Turnigy quad frames (nothing crazy, just hovering mainly):

https://www.youtube.com/watch?v=3dh2J_XQBqY

https://www.youtube.com/watch?v=mwBLNYVLvV0

Got a Bitcraze Crazyflie and not happy crashing the device. So, I designed a bumper and cage for it. Now, I can Crazyflie and not be so worried about destroying it.

This heavy duty frame and its previous light version can be downloaded at Thingiverse.com

Bumper Cage

Bumper Cage V.2

Now standard on the 850Kv AC2830 motors, or as replacement kit.

Bill Bonney recently made a blog post about these -- including a how-to on replacing the shaft. 

I just checked the runout on a couple of these and found no more than .004"

Please note that the prop should go on first so that it fits down over the unthreaded shoulder of the shaft. This provides a slop-free fit on the shaft. The spacer goes on top of the prop, followed by the cap nut. 

Alan and I were talking this over today, and realized that the spacers are not needed at all. The prop nuts have enough internal depth to seat on the prop directly without bottoming out on the top of the shaft (NOTE: if your prop hubs are thinner than the 6.5mm APCs then you may need the spacer). One less part to fiddle with and a little less rotating weight!

I would like to introduce the community to a mixer method used to fly complex aircraft in manual, fly-by-wire and autonomous modes.

The main challenges of mixing are:

• Flexibility to do anything you want.
• Easy to use and prevents mistakes
• Fly-by-wire capable.
• Field programmable
• Easily expandable
• Failsafe compatible

Fly by wire needs control inputs from your transmitter.  Imagine if your tx mixes together elevator and aileron for a delta wing.  If the autopilot looks at a servo channel, it has no idea if you are commanding pitch or roll.  This means that the transmitter can’t do any of the mixing.  All mixing must be after the autopilot.

You can now choose to have one mixer for AP and one for manual or one combined mixer for both.  Maintaining one complex mixer is difficult but two would be asking for problems.  With one mixer, the mixer must be placed after the failsafe.

When setting up mixers for a complex aircraft, the number of mixer settings is enormous.   For a full wing, there are at least four controls that mix into four channels. Each mix has between three and five mix points with some mixers being conditional on state.  That is around 100 parameters for the wing alone.  A live connected GUI is needed to make home setup and field tuning possible.

Experimenting with different mixer setups is part of tuning the aircraft for different flight phases.  The user may wish to add and remove different mixer functions.  The type of mixer function should be easy to change and it must be easy to add different functions to the system.  This needs a GUI that automatically adapts to new functions and support for automatic code generation.

For the past year I have been flying a mixer that solves these problems. The toolchain consists of automated code generators and a gui with live mavlink communication.  The flexibility has meant that I can accurately tune the settings, certainly beyond the level my radio can.  Without the live GUI, the setup time would be far too long and critical field trims impossible.

This implementation is far from perfect. The key problem is that mixer settings are a one-way communication.  There is no way to verify what settings are inside the mixer.  There is no way to make sure that different versions are synchronized.  These are the reasons that this toolchain has not been promoted for general use.

In the long term I would like to see a system that solves these problems.  My thoughts are for something like the mavlink parameters discovery. There may be other ways to improve this.  I am open to suggestions if anyone is interested.

For an overview of the project, visit the wiki here:

https://code.google.com/p/pyfedit/wiki/HowToEdit

Note that the latest version is mavproxy based compared to the standalone version in the wiki.

Some credit must go to Paul G.  One of the key ideas he gave me was how to safely mix manual and autopilot commands to enable smooth autopilot override.

After Brandon (3DR's Applications Engineer) rescued "Fozzie" from an undisclosed lab at UC Berkeley, the getaway car proved to be barely sufficient. We kept the angle of attack well into zero-lift angles, and the little Mazda stayed on the ground.