Blogs

I'm not sure if I've posted on this before, but last September the White House Office of Science and Technology policy commissioned a great report on DIY Drones and the rest of the amateur/civilian UAV movement. It's full of terrific ideas for non-military uses for UAVs, and is complementary about this community and its potential to revolutionize the future of aerospace.

It makes several recommendations, including that DARPA use this model for its own UAVs (which it has done with UAVForge)

It rightly sees the educational potential of DIY Drones, too:

The full report is here. 

Hello,

Some time ago I fell on this :

http://www.diydrones.com/forum/topics/printed-wing-concept

that was the spark that ignite everything in my head.

I'm doing kitesurf and kitefoil and we can't reach excessive speed (over 24 kots) due to fast stabilisation problem.

In the water the small pressure differential can have enormous effect, which make you fall every time.

So I first started doing a fast IMU for my wing and now I'm trying to print it ;)

we do not have any problem of weight, the wing is lifting lot for a small surface.

Here is the pictures of my firts printing attempts ... on a mendel prusa ;)

will try to talk later on the IMU ;)

SparkFun released a new version of the UAV Dev Board today.  It comes with a new, faster processor with much more program memory and RAM, and loads of extra digital and analog IO.

MatrixPilot 3.2 is already fully compatible with the new board, including support for the expanded set of RC Inputs, Servo Outputs, analog inputs, PPM Input, and even the native OSD.

The gyros have even less drift than on the UDB3, and thanks to Bill's continued research and development, the dead reckoning IMU is rock-solid.

Another nice feature is that SparkFun dropped the price down to $100!

This is a great talk showing off the technology around Google's self driving car. Heavy use of Slam and the fusion multiple databases including Google maps.

Sebastian Thrun is also teaching AI at Stanford online here: https://www.ai-class.com/

As is customary and traditional, we celebrate every new 1,000 members here and share the traffic stats. We're now at more than 19,000 registered members. We had another month of more than a million page views. It just took us six weeks to get this latest 1,000 members--we're averaging about one new member per hour.

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.

Next stop: 20,000!

Hello all,

The Bixler Electronics Chassis is being added to the DIY Drones store today. This accessory allows you to mount your APM/Oilpan, GPS Module (Mediatek or uBlox), Differential Pressure Breakout, Receiver, and pan/tilt camera mount on your Bixler. The chassis provides access to the CLI switch, USB connector, and the Reset button as well as providing a clear view of the ‘ABC’ LED’s on the Oilpan at all times. It is also compatible with two GPS modules; the uBlox module can be mounted to the vertical plate near the back and the Mediatek gps module fits perfectly on the shelf above that (or you could use some double sided tape and stick any module anywhere). Most receivers should fit on the top base and can easily route wires to the APM beneath. The APM is mounted on the bottom and once it is mounted there is no reason to take it out as everything is accessible, but if the need arises, the bottom plate is designed to pop out more easily than the rest of the chassis so there is no need to take it all apart.

Sorry for the delay, we have been quite busy. Stay tuned for upcoming products. Happy Flying.

http://store.diydrones.com/Bixler_Electronics_Chassis_No_Pan_Tilt_p/bx-chassis.htm

http://store.diydrones.com/Bixler_Electronics_Chassis_With_Pan_Tilt_p/bx-chassis-cam.htm

skywalker-jim.param

aiplane: skywalker 

TX: futaba 12fg

LRS: 400 mhz

weight: 2250 g

battery: lipo 4 cell 5000mha

autopilot: ArduapilotMega GPS, magnetometer, airspeed indicator

video: Tx Rx 5.8 Ghz

telemetry: xtend 900 mhz , 500 mw power

There have been multiple discussions in the threads of various ArduStation posts in the last few weeks about form, function, capabilities both in conjunction with and without a GCS or planner. I have joined in on some of those discussions and what came out of many of them is that we all have different approaches to what we want out of an ArduStation-like component. Some people want a simple mechanism to just decode the LAT/LON, calculate a direction and point the antenna. Some people want it to point the antenna and pass along the data stream via another communication protocol. Still others like having the screen and buttons to tune PIDs, etc. Some wanted the whole enchilada PLUS a touchscreen to do away with the old text screen and buttons...needless to say there was not a lot of consensus - so that got us talking and a modular format became a part of the discussion.

So what I would like to propose is a new project called the ArduStation HUB. A completely modular unit that will allow people to build upon it and add each component they require. So chime in, tell me what you think. Do we even need anything like this? Is my design brilliant? lunacy? Let's crowdsource the design and I wil get them built - if we come up with something truly awesome, perhaps we can get it added to the store.  I know MANY of you have been working on various versions of hardware / software etc.  Can we come up with the modular software to match?

Parts List:

APM kit

Big Y6 - 50cm (20inch) motor2motor

2836-11 750kv motors

30a ESC

12x4.5 props

carbon fiber diy frame with HobbyKing CF landing gear

LVEZ0 sonar with resistor/cap filter

low voltage piezo on AN6

rgb led strips along the bottom of the arms for showing armed/not armed (bottom off unarmed, bottom on armed), low batt (yellow blink), dancing lights for auto-trim (multi colour blink), and gps fixed/not fixed (blue blink) connected to AN8, AN10, AN12, AN14

superbrite red, green, white, and blue 5mm leds pointing up at the motors to light them up at night so you can see the props

I changed/added a few lines in leds.pde and it works nice on my quads and hexa.

I have an Olympus e420 dslr that I would like to lift.  The camera weighs 660 grams.

I still have to build a camera mount.

Little Y6 - 30cm (12inch) motor2motor

1811-2000kv motors

6a turnigy plush ESC

4x2.5 props

carbon fiber diy frame 54g

I am going too trim the square plate on the little y6 so it doesn't look so boxy.

I will update with more photos soon.

BTW does anybody have any experience with different size props on the top and bottom?

Update:

The frame is done.  It weighs 168 grams with three legs. My gopro in the case weighs 185 grams.

With motors, esc and leds the y6 now weighs in at 810 grams.

I used 3 rgb strips on the bottom of the arms and 3 leds on the top.

I used 4 2n222 transistors from the old radio shack (its The Source in Canada now) to switch the 12v leds using the 4 AN ports designated for motor mount leds from the arducopter wiki.

I have two versions of leds.pde that I am testing out.  The first one produces nice flashes with a quick on/off and the other one shows the status of the copter mentioned above.  They both work nice and I will post a video of them in action.

Here are some more pics.

Update:

I soldered my brand new apm and had countless cold solder joints.  I bought a new soldering iron with heat control and I guess I didn't have it turned up high enough.  I mounted my mag underneath the gyros/accels with foam tape and plugged it in to the i2c port with a gps cable.  That turned out to cause me more days of misery.  The sda wire going to the mag was going open inside the heatshrink.  I could upload code but I could not enter setup cli.  It would hang right at the start.  I ended up soldering right to the pins underneath.  It works well now.  I think better than how I have it mounted on my other apm which is socketed and sits up high.  I notice in mission planner watching the yaw that it jumps around less after I calibrate the mag.  (by arming it and spinning it around like with ardupiratesNG).  I also soldered on 8 wires from a hdd cable to the an8-15 ports for leds.  And two pin headers on an6/an7 underneath the board as well for the piezo buzzer and future use.

After getting the board all touched up and working I put it on my Y6 and blew the mega2560 board!  I mixed up the black and red wires on the battery monitor cable and pop.  Smoke came from the bottom.  I have another apm so I tried the new imu shield on my old apm1280.  It still works!  12 volts thru the ground rails! Yeah!  Now I leave the extension cable attached.  The new apm2560 mux chip is toast for sure. But I was able to connect to the mega and 328p chips with a usbasp on spi ports. I already ordered a new one.  Can the blown board be fixed?

 I use a standard 3s or 4s balance extension cord for the battery monitor.  That works great combined with the piezo code.  The piezo beeps on arm and beeps on disarm.  When the battery gets low it starts to beep a little til its under the low voltage you set.  The default values I find work the best.  At the beginning of flight the battery voltage for a 3s is about 1 volt higher than actual.  But by the time it gets to 11.0 (thats where I currently have mine) it is right on.  All the way down to 10.6 it is accurate.

I upgraded the ppm encoder firmware to the latest to test out the ppm sum but have not had any luck yet.  The receiver is a hk-tr6a-v2 with 6ch ppm sum out the bat port.  It does work with wiicopter and 6ch ppm sum so I just have to play around or if somebody has any suggestions.  The ppm encoder sees the ppm signal I think because the blue ppm led changes states according to the wiki.  I like the new blink patterns of the encoder.  On the desktop you can watch the ppm led blink faster as you give more throttle.

Here it is all done.  I just want to build a pan/tilt camera mount for my Olympus E420 and Canon SD600.  I would like to connect both to the Arducam_OSD project.

Next Up:  My leds.pde

This is my copter not armed and waiting for a gps fix.  The bottom blue of the rgb strips are blinking.  Faster until it locks.

After the gps locks the bottom lights come on.

Once armed the top motor facing leds come on.  They don't look that good in the photo but when the copter is in the air at night you can clearly see the motors and props.  Makes it easy to fly at night.  They don't blink.  I had them blinking but it was annoying at night.  During the day it is better to have them blink though.

This is when the battery alarm is going off.  The front turn yellow and the back is white pink purple.  All the lights are flashing.  And the piezo alarm is going off solid.  I have the yellow b led on the apm turn on as well on low batt.

I am testing out various configurations for lights for arducopter.

I have left the basic leds.pde alone and added some statements for rgb lights.

I also turn on the yellow 'b' led on the apm when in low batt condition. (good for bench testing without lights connected)

I am constantly playing around with different lighting schemes so the leds.pde changes daily.

The current scheme works well for any type of copter.

Here is a link to a boring video showing my 2nd flight with the y6 with lights on.

I am having trouble with my motors/esc starting.  I put them on soft startup and it helps a bit.

Update:  First flight with y6 successful on 2.0.50 git.

Using 12x4.5 epp props on top and bottom.  AUW 1583g with gopro and 2650 lipo I got 6 minutes of flight.

Lipo took 2700mh to charge.

Update:  This flight I am trying out 12x3.8 apc slowfly on top and 12x4.5 epp props on bottom.

I have the ratio set at .90 in config.h but I don't know if its being used.

I got 7 minutes flight from 2650 mh lipo and put back in 2700 mh when charged.

My low batt indication comes on at 11.0v and I was able to fly for another minute or so.

My copter all up weight for that flight is 1414 grams.

I have a LV-EZ0 sonar on my y6 attached to the bottom of the leg.  Alt_hold works perfect with no pulsing up to about 8-9 ft then it starts to pulse hard and climb slowly.  I am using all default pids except for stab P&R is currently 4.4 and stab I at .005

I am going to try various prop sizes and pitches as well as different motor ratios and I will log it here.

I like real world testing!  I am looking for some current sensors so I can monitor the current to all motors individually.

Photo Credit: Kevin Peterson/UC Berkeley

Science Magazine published an article suggesting that a project motivated by the recent DARPA push for small, quiet UAVs may be providing support for theories about the origin of flight in animals. 

Besides being an interesting evolutionary and biological theory, it also raises two questions here.

1) Could mini-ArduRover or ArduBoat projects benefit from wings?

2) ArduBird, anyone?

IEEE has published an interesting overview about Google's self-driving cars.

The advances in this field should be of interest to our ArduRover community. The article mentions that Nevada has updated its laws and has become the first US state to allow for these vehicles to legally share the road. No details about the process to "license" the "driver" is mentioned, but I'm certain that interested parties could find out more. 

The article talks about some of the challenges unique to this area of robotics. Specific behavior was coded into their 'autopilot' to communicate intent through action. The example of drivers at a four-way stop is used, where other drivers are not strictly following the rules of the road, and no driver moves, the car will first "announce" its intent to cross the intersection by moving more visibly, just like a human driver in the same situation. This is a domain-specific layer of complexity beyond that required for general robotics, related as it is to interaction with unpredictable agents sharing the robot's space.... such as humans, animals, and moving but "inanimate" objects.

This highlight a possible problem area in the design of our APM projects based primarily on DCM and PID controls. Our APMs have little "understanding" or modeling of the world, but for two-dimensionally-locked robots (well, we usually *hope* our ground and surface vehicles remain locked on the two-dimension plane... it usually means bad things when they leave it...) many which are successful have at least a basic method of modeling the world, its obstacles, and the physics involved. Beyond this, and outside of controlled environments, the robots also need to predict future conditions and the effect of its actions, and refold that information into the ongoing sense and avoid process, comparing and adjusting the whole time.

So where do we go from here, with that knowledge? And is there, perhaps, merit, to adding a "physics sensor", perhaps using a modern graphics chip created for the gaming industry? These are challenges which, perhaps, may take the "ArduSurface" projects in vastly different directions, but I suspect much of that work would subsequently be valuable to their flying counterparts. 

BBC has a nice little video news story about the new computer-controlled passenger transport pods at Heathrow. It includes some nice shots of the video monitoring, computer map, and of the pods in use, and also includes a brief history of this form of transport, and a sound bite by a hopeful business owner about deploying this in smaller cities. 

You can view the full video news story at http://news.bbc.co.uk/2/hi/programmes/click_online/9613795.stm

NASA Develops ACAT Auto-CGAS Smart Phone App

A small hobby-type radio-controlled model aircraft is being transformed into a
high-tech flight research aircraft at NASA’s Dryden Flight Research Center and
will be used to develop such a ’sense-and-avoid’ application for smart phones.

Andy V.

I like to spend my time in the field actually flying and not spending hours plugging things in.

Here is the latest upgrade to my Ground Station which provides a single wire from my antenna to my laptop.

All I need to take to fly is the antenna, laptop, plane and an XBox controller.

A single USB cable goes from the laptop into the case on the back of my XBee Patch antenna.

This cable goes into a USB hub.

Plugged into the Hub is:

• Xbee for Telemetry
• XBox 360 PC interface which turns an XBox controller into a wireless joystick.
• WinTV usb capture dongle

Also in the case are my 5.8 Ghz Video RX. I have put the antenna connector on the outside of the case so I can either use a small rubber duck antenna or connect it to my 5.8Ghz patch antenna which also fits on the stand with a short extension cable.

The Video RX outputs to the USB capture card which sends live images over the same USB cable as Telemetry to my APM planner where I overlay the picture.

There is a 2200mAh LiPo which provides power to the video RX. So I don't have to keep opening the case, there is a charger inside the case with a power input on the outside so I simply plug in a power pack to charge it up, or connect it to a power cable I have in my car.

The second photo shows it with the antenna on and you can see the power switch for the Video RX.

The stand it is mounted on is an aluminium commercial speaker stand so it is light, extremely durable and folds up very compactly to sit on the back seat of my car.

On the other side, you can see the long USB cable that enters the side of the case and runs to my Laptop. The Video RX charging connector is underneath.

The tray holds my notebook so that I can use the mouse while holding my plane.

The 900Mhz patch antenna is 14dBi so you don't have to point it directly at the plane unless you are on a long distance mission. The whole center piece swivals and the patch antenna also tilts up and down for more precise alignment.

This setup is for my new Ritewing Zephyr which has almost finished construction. Once its done I'll post pics of it and hopefully I'll get around to making a video of the whole system in operation.

Below you can see the GS being used in the field prior to the latest upgrade (shows the laptop stand in action).

Thanks to Michael for adding Elevon mixing to the Joystick control in the APM planner. That was the final piece of the puzzle to getting this up and running.

Thought I'd share my progress so far on an X-plane model of the Skyfun.  I'm still struggling with PlaneMaker at the moment, so I've not flown it and have generated the data purely from scaling photographs knicked from t'interweb.

If you can help out with dimensions (metric please!) of things like the tail fins, chord lengths etc, that'd be great.

When it flies to some level of satisfaction, I'll release a version into the wild.

Well,

here are a 1.8 year old video that i edited to show how are the video footage of high stability rotorcraft.

This is one of me first test with full-HD video cam.

As you can see, this platform is much more stable as ardupilot.

No wooble or vibrations.

Some balance in the video are due gimbal servos. I am using nicoleto gimbal.

This setup are using default PID.

OBS: from 2:00 to 3:00 the video are post processed to remove some wooble.

Today the platform is much more stable and using high speed servos on the gimbal

octo - gimbal and stability test from Eduardo lavratti on Vimeo.

This idea has been around for a while I have seen it done before but this is a more elegant solution than the previous one.

Just imagine not thinking about a pan and tilt set up.

The Gorgon stare on a budget.

http://jonaspfeil.de/ballcamera

How to contribute on ArduCopter project.

There are a lot of great talents out there but how to get them involved on different projects is always a question. Chris already had few weeks ago a great overall post on "How to contribute to a DIY Drones project?". Here we concentrate more on ArduCopter project and issues related to it.

As many of you know ArduCopter is separated to two sub projects: ArduCopter multirotors and ArduCopter Traditional Heli. Both of them are using same codebase and libraries but as the devices are highly different it is easier , we need more people to test, program, give ideas and so on.

Now that all Arduxxxx software are under one single easily maintained repository under Google code on address http://code.google.com/p/ardupilot-mega/ is it easy for people to do Clones and start working on their own (Look under source / clones). After user is happy with their modifications, posting patches and code snippets to main code is easy from clone repository.

Current version management what whole project and project members are using is Git. If you are not familiar with Git, please take a look on following wiki pages on ArduPilot Mega wiki

• http://code.google.com/p/ardupilot-mega/wiki/Guide - Programming guide
• http://code.google.com/p/ardupilot-mega/wiki/Git - Introduction to Git
• http://code.google.com/p/ardupilot-mega/wiki/GitCLI - Using Git from command line
• http://code.google.com/p/ardupilot-mega/wiki/GitTortoise - Using Git on Windows

• Multi - means all ArduCopter multitorors
• TradHeli - means traditional helicopter

• 1) Multi - Automatic PID computations. How to teach correct or close to correct PID settings while flying
• 2) Multi - Failsafe conditions. How to recover from several failures and allow pilot to land with minimal damages on severe failures
• 3) Multi - Navigation tests and complex multi waypoint missions
• 4) Multi - Takeoff/land tests with and without external sensors
• 5) Multi - Scripted acro / stabile flying
• 6) Multi - Barometer/Z-axis accelerometer algorithms for better altitude hold
• 7) Multi - Verify proper operation on all conditions, throttle reversing, aileron/elevator reversing
• 8) Multi - Better failsafes for low battery/lost signal cases

• 1) TradHeli - Determine best PIDs for LOITER for Trex450 and add to standard conf...
• 2) TradHeli - Make a simulator available to ease tuning and reduce the danger of ...
• 3) TradHeli - Get tail control working sufficiently well to remove the need for a...
• 4) TradHeli - Add better control mixing
• 5) TradHeli - Allow full range of radio channel 3 (collective) to be used even wh...
• 6) TradHeli - Move swash properly when user is setting up swashplate movement ran...

• http://code.google.com/p/ardupilot-mega/ - ArduPlane and electronics issues
• http://code.google.com/p/arducopter/ - ArduCopter wiki pages
• http://code.google.com/p/ardupilot-mega/issues/list - ArduPlane issue tracker

We had a great time at the East Bay Maker Faire today, with Jason demoing autonomous ArduCopter functionality to constant crowds. Once the throng thinned out, he started doing stunts like this one, where he drags the ArduCopter away from home and lets it find its way back, terrain following the whole way, and then throws it away like a Frisbee and watches it stablize itself and return home. Later, he proved that it's possible to throw it a little too hard, but we'll save that for another day ;-)

Team,

The above picture shows an interesting side effect of magnetometer misalignment: complete reversal of the measured horizontal component of the earth's magnetic field.

The effect was discovered by Peter Hollands during his analysis of the data from one of Ric Kuebler's flights. Ric was using the UAV DevBoard (UDB) with MatrixPilot autopilot software. The airplane icons in the picture indicate the estimated orientation of the plane. The blue arrows indicate the estimated direction of the horizontal component of the measured magnetic field, in the earth frame of reference.

The magnetometer is mounted separately from the UDB. It turns out that there was a small roll misalignment of the magnetometer in Ric's setup. Ric aligned his magnetometer more carefully, and the flipping disappeared on subsequent flights. But there was a nagging issue.

Because of the large vertical component of the earth's magnetic field in many parts of the world, magnetometer-based yaw information is particularly vulnerable to misalignment. In my neighborhood, the vertical magnetic field is three times as large as the horizontal field. As a result, a little bit of mechanical misalignment of the magnetometer, and certain attitudes of the aircraft can cause complete flipping of the measured magnetic field.

It is not all that easy to align a separately mounted magnetometer. Even a 5 degree misalignment is too much. I wondered if there might be a way to solve the problem with software....

While I was analyzing the data from Ric's flight, on a hunch, I plotted the measured horizontal magnetic field against the heading:

The plot told me two things. First, it told me that there was a misalignment issue. But it also told me how much the misalignment was. If that could be determined from the flight data from a post-flight analysis, it should be possible to figure it out in flight as well. So I set out to find a way to determine magnetometer misalignment in flight, and automatically compensate for it. The theory, implementation, and testing are reported here.

The method works much better than I originally thought it might. It will automatically and exactly compensate for any amount of roll, pitch, and yaw misalignment between a magnetometer and its partner IMU, including 180 degrees.

Best regards,

Bill Premerlani