Blogs

Just letting you all know that a new version is up. You must use the new version of Michael's Tool to do the setup. The older tool won't work with this version. CLI usage through the Arduino serial window will always work.

Many bugs are squashed. PID reports correctly now for D terms. 

The new rate based nav is on by default, but please be careful with it. Keep that hand on the Mode switch! 

Frames are a compile time option in the AP_Config.h file. (or use the GUI tool)

Frame orientation (X or + ) is done with a CLI based setup menu. (or use the GUI tool)

Basic motor LEDs are enabled.

Logging should be better but let's try and narrow down on the Bad Logs bug.

Jason

Made in China!

Don't know what to say.

Ardupilot mega IMU: 520 rmb = 80 USD

Ardupilot mega 240.00 rmb = 36 USD

I found Ardupilot Mega + IMU board on (taobao)

I have no idea about quality, sensor or anything else.

Any comments?

One area of multi-rotor UAV research that has been barely scratched is ground locomotion. The definition of ground locomotion is the use of systems built into the flight vehicle to move on the ground, likely without using the flight propulsive systems. Basically, this is what you get when you combine a UAV with a UGV. The following points illustrate the reasoning and need for such a system:

1) Electric Multi-rotor UAVs are only limited in flight duration by the battery capacity they carry. So, unless they exhibit some type of energy-harvesting behavior (mainly solar- or laser-powered flight), multi-rotor UAVs must land, usually sooner than later as compared to a fixed-wing UAV.

2) Although Multi-rotor UAVs are well suited to human-operated or human-assisted missions such as aerial photography, bridge inspection, and so on, there is little reason against, and many possibilities for, development of a completely autonomous system that does not require human supervision. This includes perimeter monitoring, migratory vehicles, scientific sampling, and other tasks. To create such a system, the vehicle must be able to autonomously recharge or exchange its batteries.

3) At present, most autonomous multi-rotor UAV research takes place in an indoor laboratory where researchers directly handle and maintain the test vehicle. Unless the research focus is the development of a recharging plate or platform for the test vehicle to land on to recharge (such as has been done at ETH Zurich), the autonomous system is only self-reliant in matters of flight and aerial maneuvering. Rendered another way: the machine must undergo the equivalent of a major surgical operation (preformed as the researcher removes and replaces the battery pack) in order to remain an active flying machine.

4) If the research topic is autonomous recharging, multicopters work great in an environment where a well-tuned motion-capture system and developed charging interface exists. However, as soon as autonomous multicopters venture outside of the lab into the outdoors, the well-defined and controlled environment disappears. Multi-rotors can exist in this type of environment just fine so long as attitude state information is known, but position information is somewhat reduced: The cues from a GPS and other navigation source can have a mean error of up to 2 meters, far to large for a precision landing on a charging pad.

5) A motion-capture system could be installed at the critical area of a landing pad or recharging dock/station to forward accurate position and state data to the vehicle. A multi-rotor could use GPS to arrive in the vicinity of the target area, to have the motion-capture system pickup the reflective patterns on the UAV, thus accomplishing the same precise interface as in the lab. Conversely, the UAV can have the vision-systems/devices necessary to use cues from defined targets on the landing dock.

6) For both versions of the solution posited in Point 5, there is still a large degree of complexity. Either the UAV must communicate with the ground station motion-capture systems, or the UAV must be able to identify specific marks on the charging platform. This ignores the other complex tasks involved in the scenario such as identifying if a station is already occupied by another quad/multi-rotor, and the possibility for unusual lighting and optical difficulties that might make vision-based landing difficult.

7) The alternate solution introduced here: At the cost of about 40 to 60 grams, a pair of continuous-rotation servos with wheels can be mounted to the underside of the quadrotor. Instead of negotiating with a motion-capture data link or processing data from a computer vision system to make a perfect landing on the charging pad, the entire flight vehicle can make a landing using GPS to within a flat 3 to 5 meter square target area. On the ground, the vehicle can drive directly to a empty charging dock using methods that have long existed for UGVs, such as line-following or lighthouse type arrangements. The control problem is simplified in that no motion capture system needs to exist, and the design of the landing area can be simplified or done away so long as the vehicle can drive in the landing area unhindered and locate a charger readily.

8) The utility of a ground locomotion system is much more useful to a multicopter than for just charging: Positioning on the top of a building for a better camera shot, handling the logistics of entering and exiting structures and areas that subdue flight devices, and accomplishing movement in general without using the flight devices are just a few examples.

Bibliography and Related Work:

VTOL Air/Ground Design: http://diydrones.com/profiles/blogs/transformer-bot-turns-from

ETH Zurich Recharging Pads: http://youtu.be/pcgvWhu8Arc (Seen from beginning and 0:25)

Attempts to have a multi-copter land on a UGV: https://www.youtube.com/watch?v=XpUdW_U2KJ8

Ground-based recharging: Seen in all commercial household cleaning robots such as the iRobot and Neato.

1/ Software Update on the integration of Remzibi OSD and APM

I am just updating Blake's and binzi's Blog contents:  Blake and binzi

I do not know how to make a firmware for APM Planner, so you will need to use Arduino GUI tool

Configure the APM_Config.h to your need

//to deactivate use OSD_PROTOCOL_NONE
//#define OSD_PROTOCOL OSD_PROTOCOL_NONE
#define OSD_PROTOCOL        OSD_PROTOCOL_REMZIBI

// port 3 is the telem port on the shield
#define OSD_PORT            3

// set a radio switch to activate/deactivate the OSD output :

// below 1450 will display the OSD

// above 1450 will stop displaying the OSD

#define OSD_MODE_CHANNEL    6

// choose your unit to display the disctance to waypoint in feet or meter
#define OSD_UNIT            OSD_UNIT_METER
//#define OSD_UNIT            OSD_UNIT_FEET

Then follow the normal process from the wiki above.

http://code.google.com/p/ardupilot-mega/wiki/Code

2/ Hardware

To connect your APM with the Remzibi OSD, you need to have a cable from Telem port to Remzibi GPS port. GND and TX (from APM) are enough.

If you do not see any OSD info at first, stop your camera feed to see if the OSD shows up anything. You might be starting in the wrong TV mode (PAL/NTSC). You just have to push the OSD button for about 1 second.

3/ Remzibi

You need to use Remzibi OSD software from Remzibi site and update your layout with APM.bin and flash the firmware using ARDU firmware (Announcement) in the same software.

Note: for metric or feet units , be carefull to use the right unit in the Remzibi OSD software. You need to change the APM_Config.h for feet/meter of the next waypoint in the status at the bottom

4/Usage

Once everything is connected, normally the APM sets HOME for the OSD once it gets a GPS_fix. If you connected your OSD after that, then you can just push the OSD button once to force the HOME location on the OSD.

The arrow and distance from home will always display home direction and distance to home direction. It won't show the next waypoint direction (too complicated yet )

5/ what's new

I have updated all the units and it should be displaying proper values now

Hi guys this is another late night post but I'll try to lay it out right.

I have updated the:

• Camera tracking code to use the new DCM maths
• Camera control code to use the APM_RC stuff instead of the outdated servo_out (ashame to be honest as that was very easy to use but the new one is more accurate).
• Waypoint activity sketch to work with the new location variables (thats the only change but it make the code look harder than it is).

Thanks to Mr Doug Weibel my fears of complexity have been allayed and everything needed to get this going is in one config file. . As I have received interest I am releasing this before I have flight tested under the new APM2.1 release. My previous blog posts show my old camera setup with retraction and targeting but I now have a GoPro so its back to the drawing board.

Camera Sketch Download v1.10 (whenever I edit the file I'll increment - thanks to those wanting more)

Extract the zip file inside your APM2.1 folder with the rest of the sketches, add #include "Camera_Config.h" at the end of the header includes section in the ArduPilotMega.pde, add the do_control_video case in the handles_must void of the commands_logic.pde, add the verify_do_control_video case in the verify_must void of the commands_logic.pde and overwrite test.pde (it has a test for the camera servos).

(Click the picture at the top for an animation for where - not sure why its not doing it always though guess ning isn't gif friendly).

The variables in the config are fully commented so you can change them as you need. This works with all servos of limited range (<360) and the tilt servo only move to vertical so the picture is always the right way up.

For setup of the variables use the comments next to the variables in the config as well as the picture below.

Updated:

• Fixed codebase problems, Johann's check created, Euler angle incorrect units now fixed.
• Added stabilisation (two lines and no mathsm stupid to leave it our really).
• Added relay triggering method (thanks Kirill).
• Two methods for waypoint triggering now coded.
• Added two new triggering methods that should limit vibration.
• Separated the voids used by APM (mavlink ones and test code).
• Added test code for the camera servos (pan/pitch, tilt/roll and trigger not retraction).
• Added PAN_RATIO and TILT_RATIO to variables to change movement of servos easier.
• Alter test code to move in 15° steps around axis so checking of servo movement ratio can be done.
• Created new targeting code that works with all limited movement servo (<360) fitted the the bottom or top of the plane.
• Diagram on the maths for calculating the virtual co-ordinates

Waypoint Triggering - Do something at a waypoint.

1. Waypoint triggering using the waypoint_check code you need to add waypoint_check(); to case 1 of the medium loop in ArdupilotMega.pde then change the values in waypoint_check to the waypoints you wish to take picture at.
2. Mission planner to use waypoint triggering (far easier in the field) you need to add picture_time_check(); to case 1 of the medium loop in ArdupilotMega.pde then in the mission planner add do_control_video waypoint to start and stop taking photos at waypoints.

Camera Triggering - use camera

1. servo_pic - wiggles the servo to press the camera button. You need to adjust the wiggle to press the button correctly without stalling the servo.
2. throttle_pic - turns off the throttle, waits (time), uses servo_pic to use camera then turns throttle back on. The wait is derived from the # of cycles the medium loop sees (default = 10).
3. distance_pic - turns off the throttle, waits (distance), uses servo_pic to use camera then turns throttle back on. The wait is controlled by the distance to the waypoint (default <3).

GPS Tracking - its only pointing at home still but with waypoint planning hopefully working this may be updated soon so it will actually be useful :) until then I wouldn't worry about it.

Currently grabs waypoint 0 (home) and tracks that.

Add GPS_track(); to the fast loop of the ArdupilotMega.pde just before the } at the end.

Stabilisation

Add cam_stabilisation(); to the fast loop of the ArdupilotMega.pde just before the } at the end. 

Testing your camera setup

With everything in your airframe and ready to test the connections to your servo setup and that you have configured it correctly use the test section of the CLI and use "camera". The test will:

1. pan left to right in 15° increments
2. pan right to left in 15° increments
3. tilt up to down in 15° increments
4. tilt down to up in 15° increments
5. take a picture

To check angle increments use this picture around your servo. If the movement is less than 15° you need to increase the ratio value and if it is more you need to decrease the ratio value. If everything moves as it is supposed to well done you have configured the entire setup and are ready to use it on a flight.

I used the previous iteration (APM1.13) of this code happily but with the changes I may have borked it somehow. The config file can be changed by anyone and has details on what each variable means.

If you do not understand any of this do not use it. This is for those pushing the envelope.

Disclaimer: I have not flight tested this code yet, I nor DIYdrones take any responsibility for damage caused.

ArdupilotMegaPlanner was written in .net which is a Microsoft language that they opened up the standards to. An opensource mutiplatform version of .net's CLR came out called mono. Ubuntu comes with mono installed so you can run ArdupilotMegaPlanner.exe without installing anything. All you have to do is open ArdupilotMegaPlanner.exe with mono and your golden.

Here are the steps I used to get ArdupilotMegaPlanner running. Right click on ArdupilotMegaPlanner.exe and select "properties" now check the the "permissions" are set to executable. Now click on the "open with" tab click on "add" a new window will pop up and on the bottom you'll see "use custom command" type "mono" (without the "") and hit the "add" button now double click on ArdupilotMegaPlanner.exe and you should be good to go. There are some glitches like the graph bars are sideways, the setup tool freezes and mavlink and pid adjuster only works through telemetry (which is fine by me because that is how I was wanting to use it any way), but the important functions like the firmware unloader, updates, and flight data work great!!

Oh ya it doesn't open a whole window just a menu bar that doesn't stand out at first. nothing is wrong it acts the same way in windows.

I would like to say thank you to Michael Oborne for writing the the program, making it open and available to all of us, and for writing it in a multi platform language that we all can use.

P.S. with mono installed Mac users should be able to use this program as will

Designing a robot that can traverse variable terrain usually involves a number of unsatisfactory compromises. You can go with a flying robot, which will almost never get stuck, but is of limited use in detailed sensing and can't operate for very long. Or, you can go with a ground robot, which is much more efficient, but also much more likely to run into an obstacle that it can't get around.

An ideal platform would spend most of its time on the ground but still be able to fly when it needs to, but this is a very tricky thing to make happen, since the design of something that drives is fundamentally different from the design of something that flies. Researchers from the Center for Distributed Robotics at the University of Minnesota have managed to create a single robot that can actually do this effectively.

As it turns out, it was actually more efficient to design the robot with two completely independent motor systems than to try to design a transmission that would allow the low speed wheel motors to power the rotors or vice versa. And even then, it's still extremely complicated: the rotor folding mechanism cost almost US $20,000 to create. With that in mind, future developments for this platform will focus on making things simpler, while also teaching the robot to take advantage of its hybrid nature when it comes to autonomous path planning.

The researchers -- Alex Kossett and robotics professor and IEEE Fellow Nikolaos Papanikolopoulos -- describe their work in a paper, "A Robust Miniature Robot Design for Land/Air Hybrid Locomotion," presented yesterday at the IEEE International Conference on Robotics and Automation (ICRA), in Shanghai.

Great fun. The Sparkfun team did a terrific job of giving a flavor of this competition, from the thrill of victory to the agony of defeat, and all the crazy crashes inbetween.

It's full of DIY Drones team members, too, with Doug and Jason highlighted. Lots of great shots of Doug's catapult. The post is here.

Successful flight of the MAJA Drone with the ArduPilotMega

The MAJA Drone built and tested by Jean-Louis Naudin, a true UAV with full autonomous flight capabilities done on May 2011.
 
Avionic setup:
 - Ardupilot Mega (Atmega 1280 @16 MHz), 32 Mips
 - Full 9DOF IMU,
 - Built-in 16 MB Data Logger,
 - Airspeed and absolute pressure sensors (Bosh),
 - triple axis magnetometer HMC5843,
 - 10Hz Mediatek GPS.
 - Full high speed telemetry with MavLink protocol,
 - PC Laptop ground station (APM planner with Mavlink protocol from Michael Oborne),
 - Hand-held groundstation (Ardustation with embedded Ardustation protocol).
 
Firmware: APM v2.2 (modified version by JLN)
Camera: GoPro HD Wide
 
Payload: Up to 1.5 Kg (Lipo battery included)
Flight time: Up to 1 hour (depends on the Lipo capacity)

 
More infos at: http://diydrones.com/profile/JeanLouisNaudin

How to setup the mode switch mixing for Turnigy 9x with ER9x

First thanks to Olivier whose post in my Futaba tute  helped me get my head around ER9x mixing.

I am an AC2 user so there may be some APM differences I have missed.

This tutorial was created using eePe v247 and ER9x r349.

I am going to assume that if you have managed to load ER9x, then you must be familiar with eePe and basic ER9x programming.

We will be using the 3 position flight mode switch and the 2 AIL D/R switch in this example to be able to get all six flight modes for the APM/AC2. We are aiming to get pulse widths of 1165, 1295, 1425, 1555, 1685, and 1815. Remember that 1815 will put APM into hardware manual because it uses the ch8 input, so you may as well assign manual mode to that position when you setup your chosen flight modes in CLI.

Use the PWM test in CLI to read the pulse width numbers for ch5 on AC2 and ch8 on APM. The pulse-width readout is now conveniently located on the Radio Calibration page of the Planner. I have used a servo programmer here as it is convenient for photos.

You can use eePe to setup initial mixing but Remember to backup your eeprom first.

Please don't just blindly copy my values as your radio may produce different pulse widths. The Turnigy is not as accurate as my 12fg and the pulse values seem to vary slightly every time I cycle power. Hey, it's a $55 radio :)

1. Clear any flight mode mixing you may already have, otherwise you will go round in circles chasing numbers due to the switch interaction. I wasted many hours by trying to jump straight into mixing.

2. Start with end points at +- 100 and subtrim 0 on ch5.

3. Setup these mixes on ch5. Don’t get overly concerned about the numbers for ID0 & ID2, they just get us in the ballpark.

4. Put the flight mode switch in position 1. Adjust the weight of the ID1 mix to get a pulse of 1490. This is the key to not chasing your tail later, it is also not the normal centre pulse width but is right in the middle of the range we are trying to setup.

5. Leave flight mode in position 1 and put AIL D/R switch in position 0. Add the mix shown here (make sure it is !AIL) and adjust the weight to get a 1425 pulse.

6. Leave flight mode in position 1 and put AIL D/R switch in position 1. Add the mix shown here (make sure it is AIL) and adjust the weight to get a 1555 pulse.

7. Put the flight mode switch in position N and AIL D/R in position 0.  Adjust the ID0 weight to get an 1165 pulse.

8. Put the flight mode switch in position 2 and AIL D/R in position 1.  Adjust the ID2 weight to get an 1815 pulse.

9. That’s it. If you flick through all 6 combinations, it should be pretty close to what the APM/AC2 expects to see.  I ended up with  1165, 1298, 1423, 1556, 1681 and 1813.

Kinda cool way but will it work with quadcopters

http://www.rangevideo.com/index.php?main_page=product_info&cPath=46&products_id=216

Easy and cheap fix to solve dropped video frames.  Range video should have them back in stock 3rd week of May and I think they will sell quick.

Very cool: The New York Times was at the Sparkfun competition and did a story on DIY Drones!

It will take me a while to live this quote down ;-) "“This is the future of aviation,” Mr. Anderson, 49, said. “Our children will not believe that people used to drive cars and drive airplanes. We are the weak link in the chain.”"

There's also a great video of one of the autonomous ArduCoper 2 runs, plus more of the AVC, here.

The new Carbon arrow shaft and blue 1 1/2" foam board.

All parts are glued together with epoxy.  The foam was cut with a RotoZip, razor blades, and sandpaper.

The raw quad chassi weights only 165g and is very ridged.  About 12 hrs. to build.  

Bare weight 165g

Flying weight: 787g ( 1 battery)

                       964g (2 bateries)  Still 30 grams lighter

    I moved all of my electronic from this quad

which weights 375g bare. ( HEAVY ) 

Flying weight: 994g

motor: 2212-1400kv

prop: 9x5

Batteries: 2200 mha 11.1v = 7 min flight time. :O(

The size is the same but the weight difference is 215 gram. 

With all the weight saved I will increase flight time and allow for larger batteries and / or camera.

This is to let you know that AC2 beta has been updated based on everyone's feedback. I think we're getting closer to a full release.

Things to concentrate on:

Logging - Logs are the most helpful thing you can post. If you have an issue, please post the log and let me know where to look.

Altitude hold: The Dterm was a bit too aggressive preventing the copter from changing altitudes. It's been lowered by default to 0.03. If you have trouble changing alt, try adjusting this value down a bit.

Mission scripting was a bit broken - fixed now.

Frames have now moved out of the CLI and into defines. This means you'll use the download tool to grab the frame config you need from the start. This makes the code a lot simpler internally and saves a lot of code space.

There is a newer rate based navigation algorithm (above in Flash) to try it, set this parameter in APM_Config.h and upload with Arduino:

#define NAV_TEST 1 // 0 = traditional, 1 = rate controlled

The sim above in Flash now addresses the steady state error with the I-term. PID's are great ;)

It's set to hold 4.5 M/S right now. It may not beat the wind yet, it's still limited to Pitch Max of 18° That will change for the release to full 45° pitch. This will let the copter fight high winds in WP mode.

Lot's of other minor tweaks to improve performance.

Please post all issue to the issues list:

http://code.google.com/p/arducopter/issues/list

Thanks!

Jason

I had the brilliant idea of building a device that will send GPS location over SMS text messages.

this, after i lost my prototype quad Arducopter last week. it felt not too far, i could hear it, but a few days of searching in the forest gave nothing....

R.I.P. dear copter.

here is the last successful flight, in memory..

to the point,

the Xbees are working at 900Mhz,

and the DroneCell is quad band, but the local cell company is using both 900Mhz and 1800.

should there be interference between them ?

and how can one know if the Dronecell will choose 900 or 1800 Mhz ? given the cell company support both...

OpenLRS is a radio control system designed by Flytron in Turkey. For most of us, the name will make clear that this is an open source product. Source code is available for download, you can make improvements or change the code and share these with others.

The OpenLRS M1 is an open source transmitter module that is configurable for any channel (420-450mhz) or any protocol or extra features as telemetry receiver of OpenLRS Rx module. The M1 module exists of a 100mW RFM22B RF unit and Atmega328 processor with Arduino Bootloader.

The TX module includes:

• Frequency Hopping on 3 channels (see below)
• Serial port for firmware upload and telemetry application
• a buzzer for audible information
• bi color led for visible information
• RFM22B tranceiver module including Si4432 chip with configurable 0-100mW output, Frequency hopping capability and hundreds of other features
• 16Mhz Atmega328 processor with Arduino Pro Mini compatible bootloader.

Frequency Hopping
The code that is preloaded to the transmitter does 3 channel frequency hopping (not FHSS, FH only) for reducing risks. The standard refresh rate is the same as your normal transmitter (50hz), if one of channels is disabled by an external source, refresh rate is reduced to %66 (33hz) , if you loose 2 of 3 channels you can still fly with only %33 (15hz) refresh rate. If you don't like how Flytron has implemented frequency hopping, you can write your own hopping codes or just use 1 solid channel.

The receiver (is also a transmitter)
If you don't need the Futaba Tx module's advantages, you dont need an M1 modules too. Just order 2 receivers and update the one of them as a transmitter. Because M1 module and Rx modules using same RF modules (RFM22B) . Only you should change the pinouts of transmitter code. Code will be shared on the Flytron website shortly.

The RX module includes:

• Serial Port for firmware upload and telemetry application
• 3.3v I2C port for all modern sensors as WiiMotionPlus, WiiNunchuk, MEMs gyros, accelerometers, barometers, etc.
• 8 channel servo output
• PWM output for RSSI output. (You can modify it to be a 9th channel)
• Red and green LEDs for visible informations
• RFM22B tranceiver module including Si4432 chip with configurable 0-100mW output, Frequency hopping capability and hundreds features.
• 16Mhz Atmega328 processor with Arduino Pro Mini compatible bootloader.

Telemetry
The OpenLRS Rx module is actually a Transceiver, that means that you can use it as a transmitter or a telemetry transmitter. Just imagine, you can follow your plane's voltage levels or sensors of your quadrocopter and you can change the configuration by your PC.

Serial or Parallel PPM selectable
If you are using an autopilot/multicopter controller with serial PPM. You dont need any firmware change. Just plug a jumper (binding plugs of 2.4ghz receivers) between channel 1 and 3's signal outputs. OpenLRS Rx detects the jumper when startup and gives 2 short blink. This mean it's giving serial PPM signal from 8th channel.

 
You dont need external multicopter controllers or autopilots
The OpenLRS Rx module, includes serial and I2C ports for your future projects. Just include a WiiMotionPlus (DealExtreme) and upload your code for making a basic quadrocopter. Add a Wii Nunchuck and you have 6DOF IMU. or just buy a 9DOF IMU and connect. Our 3.3v I2C port compatible with all of modern I2C sensors. You can connect your GPS or other Serial equipments with serial port.

7 Watt booster for UHF frequencies
The booster is using a Mitsubishi RA07M4047M RF amplifier to generate a deadly 7W RF power, extending the range of your Long Range System (LRS) massively. The output power is configurable by the voltage you supply to it. It starts boosting from 3.7v(0.8W) to 9v(14W).  You can supply power to this booster with a 2S lipo (7.2-8.4v) battery and it will give you 7-10W power, depending on battery voltage. This booster can be used with any (if not all) of the known LRS's (DragonLabs, Thomas Scherrer TLRS, EzUHF)

Flytron

Flytron has all information on above products listed on their website. Schematics for both the transmitter and receiver are available as pdf on the specific product pages. There you will also find datasheets for the transceiver chips/modules used. Flytron also has a forum section where their Long Range System items can be discussed Last, but not least the source code used with OpenLRS is available for download.