Blogs

At CES today, Parrot announced the latest updates to its AR.Drone. The most interesting bits are higher resolution video and an onboard baro sensor that will allow it to fly higher than sonar range outside. The phone/tablet app also has a better FPV mode. 

Here's the full text of the release:

Parrot ‘AR.Drone 2.0’:

High-Definition Excitement!

At CES Las Vegas 2012, Parrot, a global leader in wireless devices for mobile phones, reveals the
AR.Drone 2.0, the new generation of its renowned high-tech quadricopter that can be controlled by Wi-Fi
using a smartphone or tablet.

With a new high-definition camera, video recording, flight data sharing, new piloting mode, increased stability
and brand-new look, the AR.Drone 2.0 offers an experience like no other!

A flying HD camera

While in flight, the Parrot AR.Drone 2.0's front camera transmits real-time what the quadricopter
sees onto the pilot’s device screen.

For the first time the AR.Drone 2.0 camera, with a 1280x720 resolution, shows a view from the
sky in high definition with smooth and unbelievable images.

The pilot enjoys an experience like never before, as if he was on board. For gaming purposes, this
camera also can recognize specific shapes and colors to show augmented-reality elements on the
smartphone's screen.

Record and share flying experiences

Thanks to the new AR.FreeFlight 2.0 piloting application, players can record their own HD
videos and watch them or share them with the AR.Drone community.

Additionally, with the "travelling" feature, the pilot can film HD video sequences like a
professional! Simply select the direction of travel (forward, back, sideways) and the duration, and
the AR.Drone 2.0 does the rest.

AR.FreeFlight 2.0, a new piloting and sharing platform

In addition to flying the AR.Drone, new application AR.FreeFlight 2.0 – available to download
for free from the AppStoreSM and AndroidTM Market – offers players a new interface and several
options.

. FreeFlight: Access to the piloting application.
The pilot can record flights, take HD videos or photos
and save them in the piloting device. All the flight data
(altitude, speed, duration and place) can be saved,
checked by the pilot and shared with the community.
. Guest Space: Access an overview of the AR.Drone
2.0, the best flight videos and practical information.
. Drone Update: Access the AR.Drone 2.0's free
software updates.
. AR.Drone Academy: Get geolocation data of the best flight zones, watch other pilots' videos
and access their shared flight data.
. AR.Games: Access applications/games available for the AR.Drone.
. Photos/Videos: Directly access your own videos and photos. Watch or upload to YouTube
for the community to enjoy.

‘Absolute Flight’, a revolutionary ultra-intuitive flight mode

After the AR.FreeFlight 2.0 pilot application has been loaded onto an iOS or AndroidTM
smartphone or tablet, the Parrot AR.Drone 2.0 connects to the device via Wi-Fi. After
connection, all the on-board instruments appear on screen with a cockpit view.

Press the take off button briefly and the four brushless motors turn on. The AR.Drone 2.0 takes
off.

Flying is very simple. With your thumbs placed on either side of the screen, a control button
automatically forms beneath:

. Press and hold the left button and the AR.Drone
2.0 follows the movement of the pilot's device: it
moves forward, backwards or sideways when you tilt
the tablet forward, towards you or to the left or
right.
. Slide your finger over the right button, and the
quadricopter rises, descends or rotates right or left.

Thanks to Parrot's patented new ‘Absolute Control’ mode, the player accesses an even more
intuitive piloting system.

With a 3D magnetometer, the AR.Drone 2.0 knows its precise orientation with respect to the
smartphone, which becomes the reference point. The pilot no longer needs to care about the
orientation of the AR.Drone 2.0's front camera, which will accurately track the smartphone's
motion and tilt.

Experienced players will select ‘Relative Flight’ mode, the conventional flight mode. This
disables Parrot AR.Drone 2.0's magnetometer. The pilot manages the quadricopter's orientation
with no assistance.

Surprising stability at any altitude

The heart of the AR.Drone 2.0 contains MEMS (microelectromechanical systems).
A 3-axis accelerometer, a 3-axis gyroscope, a 3-axis magnetometer and a pressure sensor
give the Parrot AR.Drone 2.0 surprising stability, complete with:

. 2 ultrasound sensors, which analyze flight altitude up to 6 meters.
New! A pressure sensor completes the device and provides great vertical
stability.
. 4 blades, specially designed for the AR.Drone 2.0, make it possible to carry
out smooth flights.
. A second camera, placed beneath the quadricopter and connected to the central inertial unit,
measures the craft's speed using an image comparison system.

2 hulls made for both types of flight

The Parrot AR.Drone 2.0 has 2 hulls with specially designed contours. Made of PA66 (a
material used in designing car bumpers), they are light, highly resistant and protect the
quadricopter.

For outdoor flight, the contoured hull, available in three colors
(orange/yellow; orange/green; orange/blue), reduces wind resistance and
preserves the AR.Drone 2.0's handling and stability.

When indoor, a second hull protects the blades
from any impact. The black-and-white cockpit,
underlined with a red stripe, reinforces the quadricopter's mysterious,
thrilling appearance.

Finally, light-emitting diodes (green in front, red in rear), positioned on the landing gear, help the
pilot track the orientation of the AR.Drone 2.0 for easier flying.

An Open Development Platform

In order to expand the use of the Parrot AR.Drone 2.0 and its compatibility with other
operating systems and to develop new flying games and applications, Parrot is providing
developers and members of the Apple® and AndroidTM communities with a software
development kit.

By logging in at https://projects.ardrone.org and accepting the terms of the license, developers can
access the source code used to fly the AR.Drone 2.0. A wiki and a tutorial also are available. A
forum is available to discuss new developments and share feedback with Parrot engineers.

***

The Parrot AR.Drone 2.0 runs on a rechargeable lithium-ion battery (included).

Parrot AR.Drone 2.0 will be available for purchase at selected retailers in Q2-2012 in the United States
for $299 MSRP

*

Its no wonder AV have been making lots of noise in the press about UAS in the NAS soon.

Their man has just been put in charge of the ASTM F-38 committee.

The rules might well be changing and it would seem almost certain that military standards will form the backbone. Best dust off your STANAGs

http://www.suasnews.com/2012/01/11090/ted-wierzbanowski-of-aerovironment-appointed-chair-of-astm-f38-commitee/

http://lnkd.in/Hwsd8c 

Lets hope the AMA are truly getting ready to fight your corner, they were not at the ARC 2.0 table.

http://www.suasnews.com/2011/11/10245/uas-arc-2-0/

I know most people think this is dull but unless you act your voices will be ignored. As soon as the NPRM is finally announced getting your comments in will be important, read the comments on that last link.

Thanks to hobbyking for sending POS prop spinners with 8mm prop shafts!

Below are custom ones turned from solid aluminium.

Much stronger and with tighter tolerances. Also I decided to thread the shaft (as in video) and props,

so the props thread on :)

Gonna do some prop thrust test tomorrow.

As is customary and traditional, we celebrate every new 1,000 members here and share the traffic stats. This time it's 21,000!

There were more than 1.23m page views this month, which is a record. It just took us four weeks to get this latest 1,000 members--we're averaging about one new member every 43 minutes.

Thanks as always to all the community members who make this growth possible, and especially the moderators who approve membership applications and blog posts and otherwise answer questions and keep things ticking here. We've got about 40 moderators now, but if anyone would like to join this group, please PM me. If you've been here for a while and have been participating, you'll fit in great.

Hi all,

MatrixPilot quad_testing code begins to be funny to fly :)

In the video you can see a flight with the code at r1158. It is very stable and reliable. Controls are very smooth.

The quadrocopter is an Arducopter frame equipped with UavDevBoard4. No GPS, no other sensors are used at the moment. The only available mode is Fly By Wire for now.

Many thanks to Bill Premerlani and his fast implementing of his great research and development work on this subject.

Performances are growing up very quickly.

Best regards,

Ric

During this holidays i finish the port of HIL functionality on Multipilot32 .

On the picture you can see my hil configuration :

MP32 + VRIMU FULL

FOX 5 Frame.

Serial interconnection with my PC

On the Pc there is Mission planner rev 1.1.18 and AerosimRC or Xplane.

This is the first video tutorial of first flight this revision is in Italian , but is simple to understand what i'm doing .. i hope to have some times for recording an Eng. revision , or if a member of our community would doing his video is welcome :)

I use Camtasia to video screen capture . It work fine and not change performance of simulator.

The code is available on repo this is the direct link :

http://code.google.com/p/multipilot32/downloads/detail?name=Firmware_AC32_Hil_rev_ok.rar&can=2&q=#makechanges

This revision of code is the ACopter 2.1.1r7 derived from 8 bit revision Arducopter 2.1.1r7

Enjoy with your MP32 and Happy New Year :)

For more info check the original blog post :

http://www.virtualrobotix.com/profiles/blogs/i-m-happy-to-present-the-hil-revision-of-code-for-multipilot32

Best

Roberto

Plan is to mount under fuselage of Telemaster 12' and Mugin when it arrives.

Camera Position is being controlled by Arduino via ethernet, Pan, Til,t Zoom  , and record to local SD,and  h264 stream, works so far.

Nice thing about this camera is its speed. Also does great with its built in video stabilization.

My plan is to pass a Lat, Long and Zoom level to the Arduino and let it keep that camera position. Will plan on listening to mavlink telemetry port for GPS data, desired position.

Axis Q6035E Camera is capable of  Tilt: 220°, 0.05° – 450°/s, HDTV 1080p 1920x1080

And H.264: Up to 30fps (60hz in HDTV 1080p)

Also has built-in "Auto Tracking"... Not sure how well this will work...  Have my doubts.. Ground tests are OK...

Product Link: http://www.axis.com/products/cam_q6035e/index.htm

1.2 lbs after stripped down like below.

It's time for the second round of the second season of the Trust Time Trial (T3) competion! This round is an autotakeoff and landing round, with 3D waypoints. Like the last round, there are two divisions: plane and copters. 

Your mission in this round is to complete the course diagrammed above. Your UAV must autonomously do the following:

1. Autotakeoff. NO MANUAL CONTROL. This must be fully autonomous launch, with the RC transmitter on the ground. For aircraft we will accept rise-off-ground, catapult or hand-launch (but remember, no transmitter!). For copters, it must rise-off-ground. Just flick your RC transmitter's mode toggle switch and put that bad boy on the ground while you watch the show. 
2. Hit the above eight waypoints, which are in increasing and then decreasing height (the target altitude is given after each waypoint number). They are all 100m apart, for both planes and copters. The exact position of WP8 (or however more waypoints you need to end the mission) is not important--it is just whatever you need to set up your landing pattern properly. 
3. Autoland, as close to your launch position as possible. Again, no transmitters!

To enter, post the following in the comments below:

• KML track and screenshot of your track in Google Earth, with launch and final rest positions marked.
• A description of your vehicle and autopilot. 
• Because this is a hands-free round, we want videos of the whole thing! Upload them to YouTube and embed the video in your entry.

Gary Mortimer, as always, will be the judge. In this case it will be scored primarily on "style": he will use qualitative rather than purely quantitative measures to reward clean patterns, tight altitude control and the closeness of the landings to the takeoff points. Note: experience has shown he can be influenced by creativity and fun, so make those videos count! 

There will be three winners in each category (planes and copters), with the #1s getting a $100 gift certificate at the DIY Drones store and #2 and #3 getting $25 each.

All entrants who successfully compete the course with a copter, regardless of place in the judging, will receive a flying robot merit badge!

This is a pretty tough challenge and the weather is still dicey in the Northern Hemisphere, so you get two months for this one. Deadline is Sunday, March 4th, at midnight PST. 

The fly-out series from aufmschlau.ch productions have gained quite some fans over the past few months. In this series, TBS meets up with thermik.net, one of the leading speedglider-collectives, in a TV production for ServusTV (Red Bull TV station).

On a side-note, aufmschlau.ch productions just turned 5. Let's raise our glasses. High five!

This is "25-year-old Tim Pool — an internationally known journalist who attracts tens of thousands of viewers to his live-stream broadcasts from Occupy Wall Street protests in New York, DC, LA and other cities. (His feeds and archival footage are also aired on mainstream networks such as NBC.)", according to this Wired profile. He's taking his video documenting of protests to the skies with a series of customized mulitorotor UAVs he calls "Occucopters".

He started with a modified AR.Drone, but is now moving to platforms that will perform better outside, and that's taken them to APM and ArduCopter:

All their plans for zeppelins and steadycam choppers go well beyond what a toy copter can do. But Pool and Shapiro have been surprised to find many other options.

At the high end is Polish company RoboKopter. Its stunning video of clashing demonstrators in Warsaw in November prompted the New York Times to proclaim “Drone Journalism Arrives.” Shaprio hasn’t gotten pricing from them, but he priced out a similar craft from a company called Draganfly and got a quote close to $30,000.

Pool and Shapiro are instead going with a product called ArduPilot made by DIY Drones. It’s based on the Arduino board – microcontroller that’s a mainstay for robot builders. ArduPilot is a version equipped specifically to control aircraft. They will have to modify the open-source software to support their camera-operator maneuvers. 

We've recently made the move from the old clunky DCM implementation to a new Quaternion approach, and it seems to perform better, or at least the code is much smaller and takes almost no time at all to execute on our 72MHz 32-bit flight controller. I'll be writing an article on the Quaternion method as part of our series on Engineering Insights.

We've also added MAVLink support, and full integration with QGroundControl GCS.  This helps greatly with debugging, and of course enables waypoint flying.  The ROFL quadcopter kits have GPS built-in, and wireless versions that include an integrated XBee module are available.

As always, more videos on our youtube channel: https://www.youtube.com/user/UAirLtd

And the kits are still on sale! http://www.universalair.co.uk/catalog/rofl

Still to come: waypoint flying, and FPV: The flight controller GPS code just needs a bit of tuning, and we'll have the thing flying autonomously in no time.  The full-range of waypoint options in QGroudControl are supported, including waypoint tolerances, and yaw angles.  (See image below):

Tuning the quad is also possible over QGroundControl, this is a massive improvement in useability over our previous custom solution:

Loads more to come, I'll keep you guys posted.

If you are one of the 21 people that read my discussion post earlier this week, then you will know I'm an ArduCopter novice making beginners mistakes, and using pymavlink tools to interface my system.

http://www.diydrones.com/forum/topics/bad-attitude-from-a-stationary-arducopter

Actually, I think the vast majority of those 21 people were me checking back to see if I had any replies, but I digress. Onwards and upwards as they say, without letting you know that sometimes it's followed by rapid tumbling downwards and CRUNCH, like oh so much angry robot confetti. Embarrassing? yes a little, but since these tools seem to be widely underutilised I figured maybe I should write about how I used them to analyse today's incident.

First, an overview for the unfamiliar. MAVLink is a binary messaging protocol specifically designed for communicating with micro unmanned vehicles (MAVs). There are various autopilots (including ArduPilot) and ground segment programs (including both QGroundControl and the ArduPilot Mission Planner) that use MAVLink to communicate. Go here http://www.qgroundcontrol.org/mavlink/start if you want to know more about it.

Andrew Tridgel wrote a software library for communicating in the MAVLink protocol from the python programming language, called pymavlink (http://www.qgroundcontrol.org/mavlink/pymavlink). When you download the source code, it includes a folder called "examples" containing a bunch of scripts that demonstrate how you might use this library in your own python programs. And by the way, the examples are also such a useful collection of tools that you probably won't ever need to write your own python programs.

The three "example scripts" I used today are mavproxy.py, mavlogdump.py, and mavgraph.py. I put example scripts in quotes because these are my complete ground segment software, I have never even used the Mission Planner and don't intend to start. I'm not just being deliberately perverse, there are also sound reasons related to the architecture of our Out Back Challenge system (http://www.canberrauav.com/). In fact the whole reason I'm tinkering with an ArduCopter in the first place is because I wanted more diverse experience with pymavlink. Well, that and it's kinda fun :)

The main program in the suite is probably mavproxy.py, it's a command line GCS that does a lot more than it's name suggests. In simplest terms, it pulls MAVLink data from your modem and sinks it into a number of different places. One of those places is a log file, which we will see more of in a moment. It can also send it to other GCS programs via serial links or a UDP network socket. Or 50 different UDP sockets and serial links, whatever, it's a thing for doing the "plumbing" to send MAVLink data wherever you need it.

mavproxy's development is being driven by our OBC campaign where we are using two copies, one on the ground segment and one on a linux computer in the plane. We have multiple components in the airframe that produce and consume MAVLink messages (including redundant autopilots in a failover configuration), as well as multiple data links to the groundstation and onboard ethernet. Mavproxy is our pony express that makes sure the messages always get through.

It has one more trick up it's sleeve; a command line interface. Actually, an interactive command shell is probably a better name for it, because you can interact with mavproxy while it's running to do basically anything that could be done by clicking buttons on a more conventional GCS. This interactive shell lends itself to another layer of scripting, which is how our artificially intelligent mind reading software is going to guide the vehicle to where the judges think Joe is hiding. Or something like that, computer vision blah blah blah.

Today, I was just using mavproxy to record a log file of my fateful quadcopter flight while verbalising interesting facts through the laptop speakers. I started it something like this:

mavproxy.py --speech --aircraft=hopter --quadcopter --baudrate=57600 --master=/dev/ttyUSB0

The --aircraft option tells it to store the log file (and a copy of the configuration parameters used) in a folder called "./hopter/logs/$(todays-date)/flight$(number)/" which is very handy because otherwise I'd probably loose it. The --quadcopter option instructs mavproxy to use an interactive shell with the appropriate dialect of domain specific language (otherwise it uses the fixed wing dialect by default) for command and control. Typing "help" at the prompt is the best way find out about that, basically equivalent to browsing the buttons and menus in a GUI GCS.

There are plenty of other options...

mavproxy.py --help

So I have a log of my flight and crash. It's a big lump of MAVLink goo, what am I supposed to do with it? This brings me to the next tool in the suite, mavlogdump.py. This converts binary MAVLog data into text. It's got options and stuff but I haven't looked at them yet, I just type this

mavlogdump.py mylogfilenameandpath.log

and pipe it into a text processing chain of unix tools like grep, sort, head, less etc. Then I eyeball it and guess what the data means, from the names and values of the text-rendering of MAVLink messages. You see stuff like "ATTITUDE.roll" and wonder, frob frob frob.

So, about my crash. This is what happened, as best as I can recall your honor: I started mavproxy, switched on my transmitter, powered up the quadcopter, and stuffed around for a while while it sat on a level surface. Then I carefully carried it over to the flight line, put it on the edge of the runway and walked back to the pilot box (forgetting to groundstart again, oops). Then I disarmed, gave the motors a little spin, and realised I had forgotten to plug in the low voltage alarm. So I re-armed it, walked back and plugged that in and returned. This time I disarmed again, spun up and climbed to knee height and tried to keep it in the same spot for a moment before climbing up to a more conventional stooging-about altitude. It got rather wobbly, so I climbed more to give myself recovery room, and started flying big left/right tick-tacks parallel with the runway. Suddenly it stopped flying and tumbled to the ground. I recoverd the pieces then killed the mavproxy.py process.

So, all that's left now is to figure out why. I'll cut to the chase:

mavgraph.py SERVO_OUTPUT_RAW.servo1_raw SERVO_OUTPUT_RAW.servo2_raw SERVO_OUTPUT_RAW.servo3_raw SERVO_OUTPUT_RAW.servo4_raw ATTITUDE.pitch:2 ATTITUDE.roll:2 mav.log

ta-da!

That's the whole log, showing some sitting still, then some getting carried, then a quick spin up followed by some more sitting. Then there is a squigly bit, a squiglier bit, and finally a very squigly bit. The mavgraph window has pan/zoom buttons, so I used my mouse to zoom into the squigly bit and some of the squiglier bit, thus:

Here you can see the motors pulsing and the pitch/roll oscillating, probably due to my quad having shorter arms than the default ArduCopter frame (I didn't tune the PID coeficients yet, a bit less Proportional weight might sort this out). If only that was the worst of my problems...

Here I zoomed right into the last few seconds. Look, when pitch and roll suddenly show tumbling, SERVO_OUTPUT_RAW.servo1_raw jumped to MAX. This is not power output from the motor pluged into the rightmost plug on the APM, it is the autopilot shouting "pull, dammit" (PWM 2100) to motor number 1. Because it had suddenly stopped pulling.

Bullet plugs! I had been warned, and had started replacing them with directly soldered connections, but only done motors 2 and 4 because I was being impatient. Lesson learned.

Hi Everyone,

Maybe you remember, I released OpenLRS Opensource RC radio system in this summer and promised "you can use our receivers as multicopter controller" 

I'm glad to share our new code implementation for MultiWii. 
We added OpenLRS tab into MultiWii 1.9 firmware and replaced 10-15 lines into the original code for radio system integration. Then you dont need an extra controller board just connect your OpenLRS radio receiver and sensors for flying :)

OpenLRS Rx v2 boards supporting all(6) hardware PWM channels of Atmega328P. You can use most of arduino based multicopter controller firmwares with X,+,Y,6Y,Hexa or Octa frames.

As you can see on below, we are using only radio receiver and sensors (ADXL435 + ITG3205 breakouts) for this flight.
ESCs directly connected to OpenLRS receiver. I used our sensor breakout boards, because of stackable board design. We can plug all(acc,gyro, pressure, magnetic) sensors with one 4 pin header in 15x15x8mm space. ITG3200 board under the ADXL345 board in this photo. 

I used unpopulated controller board as base plate, this is why everything looking in red :) 

I used CopterFrame.com's GrassHopper Basic frame.  Ozan(owner of copterframes.com) designed this revolutionary frame for durability and camera mounting without propeller perspective. It's only 3 boom quadrocopter frame, simple like our controller concept :)

Google code page for OpenLRS codes:

http://code.google.com/p/openlrs/downloads/list

OpenLRS product page for hardwares:
http://www.flytron.com/16-openlrs

Our OpenLRS forum for questions
http://forum.flytron.com/viewforum.php?f=7

Thank you for keeping open your codes!  

Melih

Hello guys!
I'm very happy to tell you that the MinimOSD is now in stock in the DIY Drones store!
And more: It goes with a nice customized CharSet and an open source OSD firmware already flashed! ;)
The firmware is Arduino compatible and it uses the original APM MAVLink messages to bring out with some nice features.
Here you can see the Artificial Horizon being tested on HIL side by side with the XPlane AH gauge.

Let me talk a bit more about the firmware that goes flashed on the board:
The current open sourced OSD implementation is part of the ArduCAM OSD project which has support from all the DIYD Dev Team.

The requested APM MAVLink messages are grabbed, translated and it's displayed pretty fast.
But... why it supposed to be fast?
Firstly, the OSD class descends from BetterStream from Mike Smith, which turns it able to format and print better than the Arduino's avr-libc variant does.
Second, the CharSet was rearranged to match the ASCII table. It eliminates the need for a "translation" layer.
There is also a smart way to write individual panels with less SPI transactions (that is conventionally used only to write the full screen at once).
The MAVLink parsing uses a reduced number of buffers, which fits better m328p's resources.
Those things above improves considerably the OSD job.

Our friend Jani already wrote the EEPROM routines to make it configurable. So, it has the base for an external configuration tool.
There is much more work to be done for adding functions and improve it.
We're pretty sure that it will be improved a lot in the hands of the awesome DIYD comunity.

Well, let's talk about features:

MinimOSD is able to work attached to the ArduPilot telemetry port in two modes:
1 - as master i.e. requesting rates of all required messages from APM (both TX and RX from OSD board are connected);
2 - as "sniffer" i.e. just listening to all the messages requested from the GCS (only TX from OSD board is connected).

The firmware auto-detects PAL or NTSC and adjusts the panels.
Until now it has this panels:

• MAVBeats pulse
• Altitude
• Speed
• Battery voltage
• Battery Remaining
• Throttle
• Number of Visible Satellites
• GPS Fix data
• Latitude
• Longitude
• Artificial Horizon
• Heading (0-360)
• Compass (N,E,S,W)
• Pitch
• Roll
• Distance to home*
• Direction to home*

*Based on spherical coords with geographic distortion corrected;

The hard work continues... but, the fun is already granted, of course!

Grab yours right now and happy flights! ;)

I think its time for a new DIY Drones contest which I would like to propose.
The T3 is fun, but it doesn't have any real point other than the winner gets some bragging rights.
At the end of the day, speed is not the goal for most of us so a competition that measuers speed yields no useful information that helps us move forward as a group.

The contest I would like to proprose is an ongoing endurance contest, instead of running over a timeframe, it is continuous and reviewed weekly so that the leaderboard shows who currently has the greatest endurance on each given platform. (Lets stick to commercially available models not custom built ones).

As part of the contest you would submit information such as prop size, battery capacity, cell count, model, weight and payload details etc.
The benefit of this is that we would be able to tabulate the results and publish a document showing the endurance relationship to weight and battery capacity for every type of model that is commonly flown.

That would save us all a LOT of messing around and would be a golden resource for newcomers, even the FPV community could benefit from the data we can extract from an Autopilot.
For each model eg Skywalker, Bixler, Skyfun etc we would be able to publish recommended motors, prop and battery for maximum endurance.

This would also be an excellent resource for people who are trying to choose the right platform.
For example, if you know you need to lift 500 grams of payload then you can find out which model is going to be able to do that with the longest endurance. It would even give you the battery, motor and prop choice in order to achieve your goal.

This information is basic stuff that almost all of us struggle with and can end up costing a lot of money through trial and error trying to figure out. My thinking is that the hardware and software are open source, yet our own individual knowlege is not collated very well, you have to read through thousands of conflicting forum posts to try and put it together yourself. If we all worked together and shared the information we learn daily, then it will make it easier for all of us and we would have some scientific measures behind a lot of the 'opinions' that go into current recommendations. Just as important as the sucessful combinations are the failed ones as these can act as "don't do this" examples for newcomers. These aren't captured anywhere at the moment.

You can also use the data to benchmark changes you make to your own platform, if we have a standardised way of measuring endurance, then instead of just saying "I got 35 minutes" in a post, you can actually measure your real relative performance to other setups, then measure the increase or decrease in performance when a change is made to one of the variables.

The other benefit of this is that it will also push manufacturers to consider efficiency more as they try and get their products into the leaderboard, especially on the airframe front.

I am happy to co-ordinate it and get it off the ground if there is support from the leaders here at DIY Drones.
I can build something to collate and deseminate the data and perhaps later on down the track we could webify it so it is fairly automated.

The key thing where I might need some help is measuring the endurance from a log file in a way that is fair and ideally automated.

I forsee the goal would be something like...

- Launch
- Fly at the slowest speed possible without stalling in Auto mode
- Loiter over a target with 100m radius until your battery cuts out
- Land

Details to be accurately recorded in order to have a valid entry:

So what do you all think? 

                               A  large scale Variable Pitch Tilt Quadrotor implementation.

Here is a description of a Variable Pitch Blade Quadrotor build with some unique features. It is a large Quad, and can be quickly split into 2 halves, enabling easy packing into a carry case for simple transport. The ‘Upper’ half of the quad contains all the electronics, IMU, Autopilot, Payload control electronics, etc. The lower half carries the battery packs and the payload. The upper and lower halves slot together and are affixed by means of 4 captive spring release screws. The payload similarly mounts to the underside of the lower body half. The entire Quad can then be separated into an upper and lower body half, and payload. 

Each motor has a standard ESC ( not any fancy hi-speed update type…) mounted beneath the motor. This keeps the 3phase motor leads very short, ensuring little electrical noise radiation from said leads.. Beneath each ESC is a small CPU module which receives a serial command from the Autopilot. This serial command contains the desired motor speed, the blade pitch angle, and the rotor tilt angle for Yaw control. This small CPU module generate the relevant PWM signal to the blade pitch servo, the rotor tilt servo, and to the ESC, while monitoring the motor RPM, ensuring constant motor speed, as commanded.

 The upper half of the Quad has 2 Variable pitch, variable Tilt, same direction rotating rotors. The lower half has only two variable pitch same direction rotating rotors fitted. The motors are operated at commanded constant speed, and lift is varied by blade pitch, giving much faster control of individual blade lift for stabilization. This is a problem with conventional control by motor speed variation, as the rotor blades become larger in diameter. The inertial mass of the rotor increases, and it becomes increasingly more difficult to rapidly change rotor RPM, both to enable horizontal stabilization, and to control Yaw.

 The Tilt rotors are both fitted to the upper half of the Quad, with the rotors spinning in the same direction. This ensures that when the rotors are tilted ( always in the same direction) to control Yaw, Gyroscopic Precession is equal and opposite across the two rotors, thereby canceling out. Gyroscopic Precession also begins to play a bigger role in larger diameter rotors, when the tilt rotor concept is employed.

 The construction is almost complete. So far all simulations and math shows we should have around 2.5kg lift per rotor head, with an all up Quad weight of 5.5kg, inc 2 of 6cell, 6000mAH batteries, leaving around 2kg for payload. We should get around 15 to 18minutes flying time.

 If it looks like it came out of the ALIGN Factory, it did not…I used parts from the Trex600 series chopper, the tail rotor pitch assy, etc, as well as tail boom, stays, and a few more bits and pieces…The composite parts were all modeled in 3D CAD, and molds made for them. All the custom Aluminium parts were likewise modeled and CNC machined.

 Basic Specs:

Dimension from blade tip to blade tip – 2100mm

All up weight – 5.5KG, inc batteries, 3.4kg exc batteries.

Blades – Trex 450 style.

Variable pitch on all 4 blades.

Variable Rotor Tilt on 2 blades.

Max payload mass – 2Kg.

Estimated flight time with 1.5kg payload – 18minutes

Autopilot – NamPilot

I hope to fly it real soon now….!!

Just running out of space for all the aircraft here!, Guppy, Hornbill, Kiwit, all the 60 trainers, ……Need some sky-hooks!

Regards

Joe

‘The NamPilot’

Two unfinished body Halves:

Cutting out lightening Holes on the CNC:

2 halves with IMU:

Lightened Central Hub Assembly: (with unpainted autopilot cover)

 Lightened Central Hub Assembly:

CNC Machining of Motor Arms:

 The Pitch Tilt Arm:

The Variable Pitch Motor Assembly:

The Variable Pitch and Rotor Tilt Assembly:

Partial frames fitted Together: (floor squares are 300mm X 300mm)

Frames in Transport Mode:

I would like to fly with live video and goggles, but this makes it tough to make any changes on the mission 
planner. To avoid any need to take off the goggles I integrated a series of menus in the OSD.

My setup, as reported here, uses a second APM on the ground.It monitors the MAVLink data stream with an XBee, drives a Remzibi OSD on a second serial port, and supports an Ardustation display and keyboard as a terminal on a third serial port. To make the menu selection as simple as possible I added a quadrature encoder using three of the unused inputs on the Ardustation (nominally the analog inputs, but setup as digital). The A phase of the encoder drives an interrupt, and the resulting ISR examines the A and B phase states to determine which direction the encoder know is being turned. The encoder includes a switch (push the knob in) that is connected to the third input.

The first time the knob is pushed the top level menu is displayed on the top line of the OSD with four selections plus an "exit". Turn the knob to choose the menu item, then push to select. Each selection, in turn, has up to four available menu options. Choices are:
1. Symbology - select between four symbology formats
2. WP - read waypoints from the Ardupilot, set to first WP to restart the mission, next to skip a WP, or previous to move back one.
3. NAV - set Auto, RTL, and loiter modes (yes, easier  to use the transmitter control, but I wanted to try out more of the MAVLink commands)
4. Timer - start, stop, and reset a stopwatch timer on the OSD.

The menus are turned off automatically after five seconds of no input.

I find that that this is a fairly easy way to control the system, and it can easily be expanded to include other commands.

All of the symbology is driven with the Remzibi "$M" command strings that are a bit limited in available  characters -  seems just to be letters, digits, and a couple of others. I can't use the leading and trailing character options for the strings as they take up more space. I would have preferred using something other than "X" to indicate which menu item is being selected, but that was all I could come up with. Hopefully the minimosd will have a more complete set of command strings, or be open source to allow me to improve the presentation.

You can find a video showing the system in operation here. I was in HIL mode so no satellite count, and the GPS time clock has random data (relies on a mod to the GPS library).

Latest code can be found here. It links with the Arduplane 2.27 libraries from the repository.

Andrew

Here's a cool hack of the Parrot AR.Drone using the EZ Robot controller board (a PIC32 board with bluetooth and some very easy to use desktop software). It tracks the color red and chases him around the room!

(via Hackaday)

With the new fast prototyping tecnology is possible to develop new technology from the concept to reality . With high performance DIY electronics and 3D Design tools today is possible to obtain this kind of result.

This is our experience :

We use some 3D Pro as EdgeWorks or Solidworks and Opensource Tools as Bleender for design the frame.

After design we send our advanced project to a fast prototyping company as Shapeways

http://www.shapeways.com/shops/virtualrobotix

Then After some weeks is possible to recive the Frame .

After I put all the electronic inside the new frame I'm ready to doing the first flight the result of first experience was great , in only two hours we put all electronic inside the frame in the next days i would doing also some outdoor flight and put in front of quad a Gopro HD 2 cam for FPV :

The next step will be review of the original project with some upgrade as :

less material for have less price and less weight.

At the moment the weight is around 360 gr is yet good.

In order to fly with:

• Multipilot32+NAVI FULL the frame is compatibile also with APM+OILPAN
• 4 Keda 20-22 Motors.
• 4 Hobbywing 30 A
• 4 10 '' propeller.
• a 3S 4500 ma lipo

around 1250 gr

The main upgrade in our mind is more space for 10 '' propeller originally was developed only for 8 '' prop

possibility to change the tail if one broke. Better design for open and close cover on top of quad.

If you have other suggestions are welcome.

Original blog post :

http://www.virtualrobotix.com/profiles/blogs/form-concept-to-reality-with-multipilot32fx-and-3d-printed-single

Following up on the success of my relay low battery warning leds I have expanded that code to include a complete lightshow and to be compatible with the newest ACM codes (2.1.1) and the APM1 hardware.  APM2 hardware MAY work, but I don't have APM2 at this time, so no guarantees.

Credits to Bill Sanford and Max Levine whose work has been an inspiration and a basis for these leds.

1) Software side :

By using the agmatthews userhooks it is now much simpler to upgrade to a new firmware without having to change the code each time.  You just have to copy 2 files and change setting in the APM_config.h.  The needed files AND my config.h file (for version 2.1.1r5) are in the following file : U4eake_showleds.zip 

Updated files for ArduCopter 2.5 (compile with arduino1.0 relax patch) : u4-showleds.zip  These still work for ArduCopter 2.5.3.

Update files for ArduCopter 2.6 : Showleds_ACM2.6.zip  Because motors were put in a library, every motor_armed in the showleds code had to be modified to motors.armed().  Also you have to put

#define COPTER_LEDS 0

into your APM_Config.h file to disable the new copterleds, which are enabled by default.

You need to copy the usercode.pde and the usercode.h files into your arducopter directory (overwriting the files already there) and add the settings below to your APM_config.h.  DO NOT just copy my APM_config.h, it is only included as an example to clarify the settings.

#define MOTOR_LEDS 0                                   // 0 = off, 1 = on
#define SHOW_LEDS 1                                    // set to 1 to enable AN7-AN15 controlled led lightshow
#define RELAY_LEDS 0                                    // set to 1 to use the old relay led low battery warning

#define COPTER_LEDS 0

#define BATTERY_EVENT ENABLED

#define LOW_VOLTAGE 9.9
#define MID_VOLTAGE 10.6
#define VOLT_DIV_RATIO 3.33

#define INPUT_VOLTAGE 5.26

Also uncomment the 50hz agmatthews userhook and the mediumloop userhook (remove the // in front of it) so it looks like this :

#define USERHOOK_50HZLOOP userhook_50Hz();

#define USERHOOK_MEDIUMLOOP userhook_MediumLoop();

 

The voltages can be adjusted to match your desires.  If you have a 4S battery for example, you should put higher values, like 13.2V for the LOW_VOLTAGE.  INPUT_VOLTAGE is the voltage that goes into the APM (usually the voltage from you ubec).  VOLT_DIV_RATIO is an calibration value that you can adjust so that your reported battery voltage corresponds to the real battery voltage.

After compiling the code with arduino and uploading it to the APM board, you also need to set battery monitoring to option 3 : battery volts

That's it for the software modifications if you have a hexa or are happy with the patterns as they are !  On a quad or octo you may want to adjust the patterns a bit, but I'll explain that further down this blog (see Adjusting Patterns).

The code and blink patterns are optimised for use on my hexa (6 leds strips on the arms + 2 spare ones).  

The leds will go on when motors are armed and out when disarmed.  During flight, different flashing patterns can be selected with Ch7. The other use of Ch7 is not affected, so you can still use it for simple or recording waypoints. The leds will flash with the last pattern in this file when ch7 is high (recording waypoint or simple)
When battery gets below the first threshold (MID_VOLTAGE = 10.6V), the ledshow is overridden and the leds will flash with following pattern : led 1,3,5 on/off and led 2,4,6 off/on. So if the first ones are off, the others are on and vice versa.
When second threshold (LOW_VOLTAGE)is reached (9.9V) the leds will flash quicker.

2) Hardware :

The code uses the AN8 tot AN15 analog ports (portK) on the oilpan of APM1.  In the picture you can see them labelled  AN0-AN15.  AN8 to AN15 are the ones on the right (4x2 pins)

You can either connect 1 led directly to each port (the ports can supply 40mA current) or you can use a ULN2803 darlington transistor chip to drive the leds according to the following shedule (thx to Max Levine for this schematic) :

This shedule is for a quad and uses a ULN2003.  The ULN2803 has 8 ports instead of 7 and if I remember correctly it can supply a little more currrent (500mA per port).  A typical hobbyking 12V ledstrip of 1m (60 leds) consumes about 300mA, so normally you should be able to hang 1m of ledstrip on each of the 8 ports.  That should be plenty !!

You can get the ULN2803 in your local electronics shop or online here : Canadadrones - ULN2803

The darlington chip lets each input control the output directly across on the other side of the chip.  So nr1 in the picture above, controls output 16,   Nr 2 controls output 15 and so on.  If you look at the pinout picture of the oilpan, you'll see that nr 1 is connected to AN8 and nr2 is connected to AN10, so AN8 in the pictures above controls the red leds, and AN10 controls the green leds.  Get it ? ;-)

After the brainsurgery it will look something like this :

Now you just have to put a heatshrink over the ULN2803 chip and tuck all the wires away nicely.

CAREFULL : in the picture above I had soldered the wires to the wrong ports (side of the compass).  That's what you get when working on your copter till 4 in the morning...  It took me a day to figure out why my leds didn't work as expected.  So you have to solder your wires on the OTHER SIDE (side of the usb connector).  I didn't have a picture of when I soldered it right.

Finally you'll also have to set up your board for battery monitoring (option 3 : total voltage) by soldering the voltage dividers and connecting battery voltage to AN0, which is explained in the wiki here :  Voltage sensors on APM1

3) Adjusting the blinking patterns

First you'll have to understand a little about bitmath in arduino : http://www.arduino.cc/playground/Code/BitMath

To save processor cycles I've opted to drive the portK of the atmega1280 using direct portmanipulation. 

If the above all sounds too complicated : here's the simple explanation.

In the usercode you'll often find something like PORTK = B00101010;  This instruction actually turns leds on and off.  0 means off and 1 means on.  Each number turns 1 port off or on, and the first number after B turns port AN15 on. So the ports are B-AN15-AN14-AN13-AN12-AN11-AN10-AN9-AN8 of shorter written : BAN15...AN8

If you would now like to turn the red leds on and the others off in the picture above, this would be PORTK = B00000001; (turns AN8 on, and AN8 is connect to nr1 on the darlington, which turns on red leds)

If you wanna turn the 2 blue ledstrips on and the others off it would be PORTK = B01010000; (ports AN12 and AN14 on, which are connect through the darlington to blue leds)

All 4 strips on would be PortK = B01010101;

Ofcourse for hexa's and octo's this depends on which AN port you have soldered to which nr on the ULN2803.

Now we can turn leds on and off, but they still don't blink or "rotate".  For the blinking a counter is used and depending on the counter, leds are switched on and off.  The counter runs in the 10hz or 50hz loop, so you can time the blinking.  If counter =5 when in the 10hz loop will correspond to half a second.  

For "rotating" arms I use the bitmath again, more precisely the bitshift operators << and >>.  These simple shift all bit a few places.  so 00000001 << 1 becomes 00000010.  The 1 shifts 1 place.  By now you understood that this is an easy way to make the leds "rotate".  Just shift the B00000001 1 place each loop cycle and your 'on' leds will shift an arm each cycle, making them look asif they rotate.

4) TO DO

On the 8 port ULN2803 there are still 2 ports left unused on my hexa.  I'm planning to use those to replicate the gps status light and maybe a failsafe warning light.  I've also thought about using them to drive leds in the form of a smiley :-)  Other ideas are always welcome !

I'm using the relay now to ignite fireworks on the hexa.  But that's a story for another blog ;-)

That's about all I can think of telling you, and by now my fingers are tired and my brain is mushy.

I hope you enjoy these leds and don't scare too many people with your new UFO ;-)  Feel free to ask questions in the comments below if something is not clear.

Ow, and ofcourse I assume that you know what you're doing if you solder on your board.  I take NO responsability if something goes wrong and you break it !  Do this at your own risk ! 

Regards,

U4