Blogs

Hi,

 Just a quick update for the thrust vectoring coaxial drone project,

Config:

Maxxprod Himax contra-rotating brushless motor CR2805,

7x5 props replaced by T-Motor carbon fiber 9x3 resulting in more efficiency.

Flight time is about 15 minutes with Fatshark HD pilot and 12 minutes with a Gopro 3. Could be even better with a more adapted motor. The advantage of this system is to allow large props with little frame (the 3D printed frame of this coax weights less than 30 grams) resulting in a very good efficiency.

Flight controller is a CC3D revolution with a standard coaxial vehicle config.

The system seems to not accept too much the integral (often resulting in a counter pendulum effect during fast pitch forward translation but maybe it can be a variable overshoot??) but no pendulum effect with a simple P (no I nor D) for the inner loop (acro) and a simple P (no I) for the outer loop (attitude). With this config, the system reacts very good and is very stable and controllable even with wind.

Next step will be to remove the clevis in the commands because the system could maybe accept a direct servo in the roll and pitch plates and take advantage of a larger roll and pitch travel (-45°, +45° for ex) and more room in the frame (or a lighter one). CC3D will be replaced by a SP racing F3.

Thanks for your comments if you have!

Users feedback report around GCS software

Hello, everyone.

As many of you already know we are putting a strong effort on investigating possible improvements that could be done on Ground Control Stations interfaces. We would like to thank everyone who spared some time helping us with our 1st round survey (results can be seen on the link below).

1st Round - GCS Users Feedback 

By now, we prepared a 2nd round survey that aims to refine the results and gather more feedbacks and insights from the community. The new survey is on the link below.

2nd Round – Ground Control Stations – Detailed usage

We are extremely happy to share the results with the community, but we really need your help to spread the survey and gather as many user responses we can. So please, share the link with the world.

;)

Sorry to see this notice from AirDroids, who had launched the PocketCopter on Kickstarter, but glad to see their list of "lessons learned". Manufacturing is really, really hard, and they were not the first or last Kickstarter project to get in over their head in the process of going from prototype to product. 

Dear Drone Lovers,

We are writing to let you know that AirDroids, Inc. is ceasing operations. As of this week, we have sent out units for all the orders that we received addresses for. Our company ran out of money a few months ago, but we have been able to fulfill all orders through a recapitalization of the company funded by the projects creators taking out tens of thousands of dollars in personal loans.

In this message we want to answer two questions. First, how did a project that raised nearly a million dollars run out of money? Second, what does this mean for our Kickstarter® backers and customers?

There are three primary factors that led to significantly greater costs than we originally anticipated. Some of the issues that arose could not have been predicted, others were attempts to make things better for our customers.

First, the unprecedented success of our Kickstarter® campaign meant that we manufactured around 20 times more orders than we originally anticipated. To address this challenge and to make the product more durable for our customers, we decided to do a complete redesign of the system. After seeking advice on how to handle the higher production numbers, we engaged contract engineers who had more experience in designing for higher production runs and who were specialized in designing plastic parts for injection molding. The cost for their services cut significantly into our budget.

Second, since the redesign caused delays in the production schedule, we decided to minimize further delays by making our molds and doing assembly in the United States, rather than outsourcing production to China or Taiwan. This approach was intended to give us the flexibility that we needed to make course corrections and was also a great opportunity to support local businesses. However, this decision significantly increased our mold and tooling costs.

Finally, given the success of our Kickstarter® campaign, we ordered extra parts to be able to build more units for post campaign sales. Much to our disappointment, our Shenzhen suppliers did not consider orders for 2000 units to be sizable enough to give us a large volume discount. We were forced, therefore, to estimate our market demand and our “part failure” rates in order to get the pricing necessary. Further, when the parts arrived, the “dead on arrival” rate was higher than we anticipated.

These key decisions, combined with the already high bill of materials and Kickstarter® and Amazon Payments taking an 8% cut of total funds raised, left us with a minimal financial cushion. In addition to these expenses, the cost of assembly, packaging, shipping, and salaries for our small manufacturing staff caused us to be significantly in the red financially.

The company’s leadership did not receive any profits or distributions off of this project, and took on over $100,000 in personal debt to be able to contribute additional capital to the company in order to assemble and ship all the units that were ordered. Of course, this is all due to our own decisions and we are not soliciting sympathy. Our hope is to provide you, our backers, with some context for what happened and perhaps help other makers with Kickstarter® dreams avoid similar mistakes.

Our small staff has been notified that they are being laid off. Unfortunately, upon the completion of the final orders, the company has ceased operations and will not be able to receive returns or send out additional parts or units, as there is neither staff nor money to do so. We have sent out all orders that we received addresses for. A small group of Kickstarter® backers never provided addresses in response to the backer survey we sent out and we have not been able to ship those orders. Also, some of the packages that were sent out could not be delivered by UPS as the address and contact information provided was incorrect or the recipient did not follow up with customs to meet local import requirements. 

We are putting our design files on our website, which you can access at www.airdroids.com/files.html. You may attempt to use these to generate your own spare parts, although please be advised that results created from a 3D printer may differ significantly from what we created using injection molded plastics and we make no guarantees regarding the designs and their functionality. Please use them at your own risk. 

With The Pocket Drone®, we wanted to provide our customers with a powerful user-friendly tool to enhance exploration and preserve memories. We are deeply grateful for the support and forbearance of all of our backers and customers. We have also been impressed and humbled by the amazing community of people who came together to improve upon the designs we generated and support other users. We wish you safe flight, and hope you will all continue to enjoy the magic of being able to see the world from a new perspective.

Team AirDroids

The ELC/DroneCode conference is fast approaching. We are really looking forward to meeting many of you in San Jose next week!

We have put together a rough agenda for the 'unconference' and the first physical meeting of the Technical Steering committee on the Wednesday which you can see here:

How to Participate

You can participate in the unconference either by being there in person (if you are going to ELC) or by joining the discussions on mumble. We will use the DroneCode channel in mumble. There will be a microphone in the room and we will also be live streaming via hangouts on air. To actively participate in the discussions you should join the mumble channel. Please be careful to mute yourself when not speaking.

Rough Timetable

As an unconference the schedule tends to be quite loose, but it will be roughly:

8am to 9am: breakfast

9am welcome and introductions

9:15 first presentations and discussions

10:00 to 10:30 break

10:30 to 12:00 more presentations and discussions

12:30 Lunch.

2:00 to  4:00 pm.  afternoon presentations and discussions

If you have other ideas or suggestions for discussion topics please let us know

PID loops can be pretty confusing when you're first getting started with autopilots.

Here's my attempt at explaining them "intuitively", i.e. with no math.

I'm working on plugging in a physics engine into the demo. Two more videos in this series are planned:

- Understanding the math behind PID controllers.

- Tuning PIDs (using the physics engine as a testbed)

Anyways, this is my first go at this.  I'll probably make a second attempt in the future, so any feedback is appreciated!

(update) thanks for all the feedback! I'm getting ready to start part 2 which will decipher the math and show the basic simplicity of PID loop programming.

Joe and Justin give the Maker Faire 2013 crowd a demo of their new heavy-lift 12-rotor creation -- including an example of flying with only six motors operational. The downwash from this monster could be used for clearing leaves off the lawn or removing snow from the driveway, in addition to keeping a large camera aloft.

Having learned the hard way on a few things, I thought I'd put together a little video that shows some tips and tricks with the APM mission planner.
The first time I tried mission planning some things were a mystery, like how do you actually get into auto mode to fly a mission? I found something that looked like a way to do it from the APM software flight data tab, but that turned out to be a disaster because there was no way to get it out of auto mode and my quad went crazy and crashed into my house. Second fun one was when the mission started but didn't finish, so I had to trudge across 60 acres of mud to retrieve my quad. Lastly I almost lost my quad on a mission that went awry, for some unknown reason it did 2 way points, then took off in the wrong direction, into the fog.  I tried to take back control, but I couldn't see it in the fog, then soon after I couldn't hear it either.  Then the sinking feeling came over me, $600 down the tubes! But fortunately I remembered to setup a safety switch that would return to home. I flipped  the switch and waited for what seemed like forever, then that wonderful sound of buzzing bees emerged out of the fog and my quad flew itself back home.  Phew!!  Learn these tips and tricks by watching this video, it could save you some money.

Something like a beta version of my "startup" http://www.rcdetails.info
Website and database to search motors, servos, batteries etc by a different criterias.

You can check several items to compare all properties.

Right now DB contains info about products from HobbyKing.com and from GoodluckBuy.com, and i'm working on adding info from TowerHobbies.com

I would like to hear your advices, your critic, your comments: mr.pokryshkin@gmail.com
I hope it will be helpful.

Thanks.

The PX4 team is pleased to announce early availability of the PX4 autopilot platform, with hardware available immediately from 3D Robotics. 

The platform is a low cost, modular, open hardware and software design targeting high-end research, hobby and industrial autopilot applications.

PX4 is an expandable, modular system comprising the PX4FMU Flight Management Unit (autopilot) and a number of optional interface modules.

The PX4FMU autopilot features include:

• 168Mhz ARM CortexM4F microcontroller with DSP and floating-point hardware acceleration.
• 1024KiB of flash memory, 192KiB of RAM.
• MEMS accelerometer and gyro, magnetometer and barometric pressure sensor.
• Flexible expansion bus and onboard power options.

Expansion modules available at release include:

• PX4IOAR This module interfaces PX4 to the AR.Drone motor controllers, allowing a complete quadrotor to be assembled using an AR.Drone frame and motors.
• PX4IO A flexible interface module with support for eight PWM servo outputs, relays, switched power and more.

As an open hardware design, third-party and DIY expansion modules can be easily developed for specific applications, and more PX4 modules are in development.

In addition to the versatile hardware platform, PX4 introduces a sophisticated, modular software environment built on top of a POSIX-like realtime operating system. The modular architecture and operating system support greatly simplify the process of experimenting with specific components of the system, as well as reducing the barriers to entry for new developers.

Adding support for new sensors, peripherals and expansion modules is straightforward due to standardized interface protocols between software components. Onboard microSD storage permits high-rate logging and data storage for custom applications. MAVLink protocol support provides direct integration with existing ground control systems including QGroundControl and the APM Mission Planner.

Pricing of the PX4 components reflects more than a year of careful development and a strong commitment from our manufacturing partner.

• PX4FMU: US$149
• PX4IO: US$99
• PX4IOAR: US$89

This release is targeted at early adopters and developers looking for a more capable platform than existing low-cost autopilots. With more than an order of magnitude more processing power and memory compared to popular 8-bit autopilot platforms, PX4 is exceptional value for money and provides substantial room for future growth.

For more information about the PX4 autopilot platform, visit the project website at http://pixhawk.ethz.ch/px4/

PX4 modules can be purchased from our manufacturing partner, 3DRobotics.

ArduCopter now has experimental geo-fencing support, thanks to Andrew Tridgell's superb geo-fencing code for ArduPlane.

If you haven't heard of the geo-fencing features of ArduPlane, you are probably an ArduCopter user! Since December 2011, ArduPlane piltos have had the ability to build a virtual fence around an area and prohibit the aircraft from exit from the fence.

The details are in the GeoFencing wiki page.

So, now, this amazing feature is available for early-stage testing in ArduCopter. 

Why do I want geo-fencing?

All four of my quad crashes follow the same scenario: pilot error causes the quad to go a bit far. Attempts to bring it back make the situation worse. The quad gets caught by wind or moves too fast and starts getting away from the pilot and out -of-sight. Eventually, you have to force a crash by killing the motors while you can still see the quad.

Runaway Copter - no more

The images above show a software-in-the-loop simulation of Tridge's geo-fencing in action. The quad starts in the center of a large sports field, with a fence defined in a 50m radius around the center. A minimum altitude of 20m and a maximum altitude of 100m are set for the quad. 

In the simulation, the quad's throttle is turned up to 75% and left at that level. Then pitch is set to a very aggressive 20-deg forward angle. 

After liftoff, and once past the minimum altitude of the fence (20m), the fence is turned on by a switch on CH7 (preset in code).

The quad shoots straight up and right past the max altitude, because it has a lot of upward momentum. The fence triggers and switches the quad to guided mode to pull it back to the center (which is halfway altitude 100m-20m = 80m, and the point in the center of the fenced area). Because the throttle is still very high, the guided mode is able to stop it from climbing but can't quite pull it down. Easing off the throttle to about 45% makes the quad a bit more "tame". 

The quad then spends the next five hours screaming at 25m/s speeds towards the walls, while hovering just under the ceiling (at an average of 98m) and bouncing back and forth. The shape that is created makes the fence visible. 

Bottom line: Your quad cannot get away.

Get the code - Testing the geo-fence on ArduCopter (Experienced Coders)

As an experimental feature, you will need to be able to compile and upload code to the board without the Mission Planner (ie using Arduino IDE or command line). You will also need to (possibly) tweak some parameters to your liking.

Get the code using one of the following options:

• GIT - git checkout -b geofence_arducopter --track origin/geofence_arducopter 

• Patch - see geofence-arducopter.diff, patch on "latest" ardupilot-mega source (circa Apr 25).

A bit easier, you will still need to know how to upload code to the board

• Download and flash this ArduCopter.hex file 

One of the biggest challenges in an open source development project is getting the "architecture of participation" right. Like a great game, contributing should be easy to pick up but hard to master, giving people of all skills and experience an opportunity to engage. Right now we have scores of developers working on dozens of projects, but a lot of it is behind the scenes on private email lists, Skype calls and IM threads, Google Docs and 3D Robotics project trackers.  You can see the tip of the iceberg in the change logs, but that's just a hint of the activity that goes on every day.

If you'd like to get involved with the DIY Drones dev teams, here are a few places to start:

• The Dronecode Project (part of the Linux Foundation), which is the umbrella organization for the APM, PX4 and other DIY Drones software projects
• The DIY Drones Developers site
• The GitHub code repositories
• The Drones Discuss developers email list
• The Documentation Editors User Group
• The ArduCopter/Plane Issues List