Blogs

The DJI WK-M Multi-Rotor controller has had a firmware update over the weekend, the guys at Wookong headquarters added the “Care Free” mode in this latest update “5.0”.

We took the Hexa out to the field and had a look at what “Care Free” would do! The Hexacopter has to be told where home is at start up, from the home point there is a 10 meter radius before the care free takes over, when you are past this point the copter will fly in any orientation or constant yawing (see the video towards the end to see just how smooth this is!) and keep forward, backwards, left and right in the same place throughout the whole flight until you return home.

We could not trick it, fault it or have it skip a beat after sending a few batteries through it, the wind was not playing to the DJI's advantage on this test, there were gusts, then no wind and a steady breeze of about 5-7 mph from time to time, all of which the DJI soaked up and just got on with the job in hand!

Over all the performance of the DJI was solid and flawless.

Regards

Martin

www.buildyourowndrone.co.uk

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.

Since I've had such problems with buying a brushless in-runner, I've got brushless outrunner instaed.
To mount it in the plane, I've used motor mount (that was a problem to find in my country too) from the twinstar,
slightly modified.

Pictures will tell the story.

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

After our flight testing was halted by a blown ESC I decided to start work on Software/Hardware in Loop (SIL/HIL) testing. As I pointed out in previous posts we plan to use APM to control multiple autonomous vehicles, all cooperating to various degrees. Before we can safely test such systems outdoors, especially given our constrained operating area, we need to test them in simulation. Prior to our purchase of APM we had been using X-Plane as a simulation environment for some time and so we were pleased to see the existing HIL system provided by the Mission Planner. The problem with this system from our perspective is when simulating multiple vehicles not only do we need multiple copies of X-Plane running (a problem we've always had, hopefully mitigated in X-Plane 10!), but we need multiple Mission Planners running as well. 

The solution we came up with was rather than use X-Plane's native UDP data stream, write a plugin for X-Plane which automatically generates the correct MAVLink HIL messages that APM is expecting and outputs them over a network (SIL) or serial port (HIL). As of today I have finished v0.8 of this plugin which is compatible with ArduPlane in SIL mode. Future revisions will support ArduCopter and HIL.

For initial testing you can use the Mission Planner to connect to the telemetry port (TCP port 5763) to interface with APM the same way as you would in flight.

For more information or to download the plugin click here.

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:

An update on the navigator concept:

(see here

http://www.diydrones.com/profiles/blogs/proof-of-concept-cross-wind-navigation-and-low-level-autopilot )

I think the screen shot is interesting.

On the left is ArduPlane Desktop in default config, running the "autotest" mission at 1000hz perfect world data.

On the right is the vector field guidance autopilot for navigation, using a different heading and roll autopilot as well.

No wind in either scenario, but LVFG can do all kinds of wind as well.

After a successful first year of the Mr. Lifter contest in 2011, a new contest has been launched for 2012. The contest has many categories you can enter -- from 'heavy lifter' to 'all out time duration', 'most weight efficient', to 'largest copter' to name a few. One category that is new for this year is the "furthest distance" (round-trip) in a single charge. Perfect for UAV or FPV.  Some amazing entries from 2011 are asking to be bettered -- such as Walter Lafouine's heavy lifting hexa copter, lifting an amazing 12.1kg.

Enter the contest