Uses two Align Trex 800s, back to back, with Pixhawk controlling everything. 

Not good.. Not good at all and why make the noice..

http://www.liveleak.com/view?i=ac3_1435080329&use_old_player=0

Can't embed the video.

Hello all! 

  I´m happy to announce the new edition of the Msc program in development and experimentation in Unmanned Aerial System: 

http://www.unia.es/component/option,com_hotproperty/task,view/id,1440/Itemid,445/

  In this master you will learn from design&construction to fly test of an unmanned aerial system. 

So you thought Lithium Polymer battery was good with its 150 Wh/Kg?

Well, there's a new battery on the scene which boasts 11,000 Wh/Kg! Lithium - Air!

Polypos has only gone and done the impossible!

Can you imagine 11,000 Wh/Kg?

Let me put that into perspective:

• If you put it on a Multirotor with a 15 minute flight time you'd have, 17 hours of flight time!
• If you put it on a plane with 2.5 hours flight time... It'd give you over a week flight time! I mean these arn't even the most efficient times, think of a plane with 4 hours flight time, now it'd be half a month of flight time!
• If you put one of these onto a Tesla car with it's 200 mile range.... It'd give you over 14 thousand miles range! That's nearly around the world! 

The idea behind Lithium Air batteries is nothing new. Not having to carry half the battery around and just using the air is a great idea, especially with one of the lightest battery materials - lithium; but actually doing it - that's something else. There was always the problem of the electrodes being destroyed, however Polypos has found a way to protect the electrodes. 

Wikipedia Lithium-Air Battery - if you want to know the exact chemistry and the problems!

Okay I'm hyping it up a bit much, it's going to be a long way off before we see these for sale, and at the moment they're getting no where near the theoretical 11,000 Wh/Kg - still over 1,000 Wh/Kg though! Plus I reckon PolyPos will be holding their Lithium air batteries close to heart, and it'll be the military who get's them first of course.

But look at what happened with lithium polymer batteries?

It's exciting!

For the moment, what we'll probably realize first is Lithium - Sulfur batteries. These boast 2500 Wh/Kg - still pretty awesome! 

Check out more at The Polypos Website.

Also here's a really interesting article about these batteries. 

Polypos Batteries Article

Hope you found this interesting, and thanks for reading!

There has been a lot of interest in autonomous mission planning and mapping using Solo since release.

Good news: mission planning with Solo is exactly the same as it was with IRIS+ or any PixHawk powered vehicle.

Better news: the tools just keep getting better.

Mapping used to involve a truck full of computers, masts, antennas, and mobile hotspots and quite a bit of brain damage sorting out logs, images, and stitching after returning to the office. Now the same work can be done with the contents of a backpack and a minimal amount of computer, drone, and GIS aptitude.

What follows is a quick guide to mapping with Solo and nothing more than the contents of a backpack. The workflow is smooth enough now that I’m confident anyone can follow along and make a map with minimal effort and expense.

Step one is to show up to your site with with a backpack filled with Solo, a GoPro (ideally with a 5.4mm flat lens installed), a handful of batteries (at 80% sidelap I get about 30 acres per flight at 350 feet), a patch antenna (if the area to be mapped is longer than a half a mile), an Android tablet, and a Windows laptop. I typically begin by popping powering on Solo and the transmitter, so everything is ready to go as soon as my mission planning is complete.

Next, I whip out Tower and plan my mission. While full fledged mission planning used to require desktop applications, Tower has evolved into a very capable mobile solution and offers essentially all of the functionality of its desktop counterparts. Additionally, the 3DR team has recently written up some excellent guides to using Tower that are worth checking out for even the veteran.

There's no reason to duplicate work, but, briefly, my order of operations for mission planning is as follows:

1) Connect Tower to Solo using the WiFi setting in Android

2)Open the Editor and tap the squiggly line and select “Survey”

3) Draw a perimeter around the area of interest

4) Tap the green square in the lower righthand corner to bring up the survey details. Here you select the camera lens (GoPro with a 5.4mm lens has approximately the FOV of an S100), altitude, and sidelap. I’ve found 80% sidelap to be more than sufficient for most areas. Solo can typically cover around 30 acres at 80% sidelap flying 15 m/s at 350 feet. The survey tool also provides important information related to the quality of the survey.

5) Upload the mission to Solo by tapping on the three dots in the upper righthand corner.

Next, turn on the GoPro and sync the GoPro time to the tablet time using the wrench icon in the GoPro app. This step is critical, but does not need to be repeated every flight. The images will be geotagged by matching the timestamp on the image with the flight log, so as the GoPro clock deviates from the tablet clock, accuracy is diminished.

After synchronizing the clocks, set the intervalometer to take a picture every two seconds. There is clearly room for experimentation here, but for most areas flying at 15 m/s and shooting every 2 seconds gives plenty of overlap (~75%, depending on altitude). This step will be eliminated when the Solo gimbal is released and camera control is built into Tower, but for now remains manual.

After the GoPro is shooting and the mission is uploaded, arm Solo and send her on the autonomous mission, sit back on your cushy backpack, and enjoy a marg. Once the mission is completed and Solo lands, stop the camera and power cycle the tablet to write the logs to the permanent memory.

Next, here is where you will really enjoy the backpack seat, open your laptop and start Agribotix Field Extractor (I believe you must create an account to download this piece of software). In the very near future, this entire process will be mobile only, but for now a Windows laptop is still in the loop.

Grab the SD card from the GoPro, plug it into the laptop, and connect the tablet to the laptop. Open the Agribotix Field Extractor and follow these instructions. The key piece here is that the GoPro already has its clock synced to the tablet, so the time offset is 0.

After importing and geotagging the images, Field Extractor generates a rough .kmz file that tiles the images in Google Earth locally immediately and generates a .zip file on the desktop of geotagged images. If you are an Agribotix customer and pay $49/month for image stitching in the cloud, like me, the images are automatically uploaded and stitched in around an hour. If you are not and prefer to use your own software like Pix4D, Photoscan Pro, AutoDesk ReCap, or something else entirely, you will have a nice folder of geotagged images on your desktop taken by Solo and GoPro.

While there are a lot of words above, the entire workflow is very smooth and makes mapping quite accessible to anyone interested is basic drone-based GIS and photogrammetry. Geotagging using the Agribotix Field Extractor by far the smoothest way to inject geotags onto images taken using a PixHawk controlled vehicles and image stitching in the Agribotix cloud takes all the brain damage out of using photogrammetry software. Give it a rip and post your Solo maps up here! I would love to hear feedback.

One of mine is below.

Progress on VTOL for the PX4 Flight Core: Full forward and back transitions now with tailsitters and tilt-rotors.

We have now full VTOL support for tilt-rotors, in addition to tailsitters, which were introduced six months ago (video). People interested in flying these can find contact details and build logs on this page. You can follow us on G+ or on Twitter for general PX4 platform updates.

A Demo of Helical Turns with an EasyStar in HILSIM / X-Plane 10 from Pete Hollands

A few days ago William Premerlani posted the theoretical maths behind a new control algorithm for MatrixPilot called Helical Turns.

This post shows a practical demonstration of flying MatrixPilot Helical Turns using an Easy Star in Hardware In The Loop Simulation (HILSIM).

Recent developments in using single-frequency dual-satellite navigation system for RTK application (L1 GPS + L1 GLONASS, or L1 GPS + B1 Beidou), with more satellites overhead at any given time resulting in much higher availability getting ambiguity fixed solution, it has brought lower-cost single-frequency centimeter-level accuracy RTK receiver closer to reality. Using GNSS Radar, below figures show what satellite availability might be like over a 12 hour satellite orbit period at different locations. 

In East Asia, Australia, and India, there are more GPS + Beidou satellites over the horizon than GPS + GLONASS satellites. In Europe and South Africa, slightly more GPS + GLONASS satellites than GPS + Beidou satellites. In North America and South America, number of visible Beidou satellites is low.

With goal of developing a small low-power single-frequency RTK receiver module, for ease of debugging, initial development of RTK software is done on a PC, with below recent results:

Although above image looks wobble a bit, the result on the athletic track should be good, considering it’s not easy to hold the antenna pole straight and perpendicular to the ground without shifting the antenna slightly.

For comparison, below is from jogging around campus, logged using Nike+ using Galaxy Note 3; four passes over a same route, with fifth path making the smaller round.

With more available satellites using two satellite constellations, time to resolve integer ambiguity achieving fixed RTK solution is much shorter than using single GPS constellation alone (90 sec with 7Km baseline in above example), and it has high availability at any time of day. Above test results show exciting promising potential for emerging applications requiring high position accuracy using lower cost single frequency RTK receiver.

A complete SMD receiver module prototype about the size of 25mm x 25mm will be developed, beginning schematic design next week. A separate interface adapter board will have accommodation for wider power input range, data logging, and other interface if needed. Now at beginning development stage of the target hardware, if there are developers interested in adding software support making this RTK solution workable with Pixhawk or Ardupilot, would be happy to try accommodating the needed hardware interface on the board design. Cheers!

During the first flight of this big hexa one of the six motors rotated about by 90° for a faulty clamp, really bad situation for the attitude, here's how the code and the pilot handle this emergency, with a perfect landing.
Although the drone had been higher i'm sure that the flight attitude would remain good, under control.
This result shows that the efforts of the development team were awarded the reliability.
Special thanks to the whole "APM:Copter Dev Team" for this reliable code, and to Lorenzo Franco (the cam operator).

Marco Robustini

("APM:Copter" Lead Tester)
 

Christmas already?  Yes, yes it is with the brand new state of the art code thanks to the huge effort by the ArduPilot development team and some great contributions from the community.  GO ROVER!

http://ardupilot.com/forum/viewtopic.php?f=112&t=12801

The ArduPilot development team has released version 2.50 of APM:Rover. This release is mostly a back-end improvement to ArduPilot but a few new features and bug fixes are included.

Re-do Accelerometer Calibration
Due to a change in the maximum accelerometer range on the Pixhawk all users must re-do their accelerometer calibration for this release.

Only 3D accel calibration
The old "1D" accelerometer calibration method has now been removed, so you must use the 3D accelerometer calibration method. The old method was removed because a significant number of users had poor experiences.

Changes in this release are:

• CLI_ENABLED parameter added so the CLI can now be accessed in Rover
• PID logging for the steering controller. It its now possible to graph what the P, I and D are doing as your driving the rover around to enable much better tuning of the vehicle.
• Transition from .pde file to .cpp files for improved development.
• GIT Submodules created for PX4Firmware, PX4Nuttx and uavcan git repositories for improved development.
• Followme mode now works for Rover
• GUIDED mode significantly improved. If you have a GCS which is in Followme mode if the user then changes mode with the RC transmitter to HOLD or anything else then the Rover will STOP listening to the
• Followme updated guided mode waypoints.
• When going into GUIDED mode the rover went into RTL - this is fixed.
• Added EKF_STATUS_REPORT MAVLink message
• 64-bit timestamps in dataflash logs
• Numerous EKF improvements
• Added support for 4th Mavlink channel
• Added support for raw IMU logging
• Updated Piksi RTK GPS driver
• Improved support for GPS data injection (for Piksi RTK GPS)
• The SITL software in the loop simulation system has been completely rewritten for this release. A major change is to make it possible to run SITL on native windows without needing a Linux virtual machine. (thanks Tridge)

ENJOY!

First of all, thanks to Peter Hollands, who produced the above picture of a helical flight trajectory from one of his HILSIM test flights of the latest version of fixed wing flight controls for the open source MatrixPilot project, also known as the UAVDevBoard. For the last year or so, Peter has been helping me develop a "helical turn control" for MatrixPilot, starting last summer when I decided to start over on the MatrixPilot fixed wing flight controls, using basic principles. One goal of the new controls was to be able to fly an arbitrary helical trajectory. Peter had some fun producing the above trajectory using XPlane-10 and HILSIM, running the new controls.

The theory of helical turn controls is described in the following three attached documents:

The first document, HelicalTurnPart1Conditions.pdf, describes the conditions that need to be satisfied to achieve a coordinated helical turn.

The second document, HelicalTurnPart2Controls.pdf, describes a simple controller, relying mainly on feedforward and proportional feedback, for satisfying the turn conditions, using matrix-vector computations.

The third document, HelicalTurnPart3AoA.pdf, describes a method for accounting for angle of attack and variation of elevator trim with wing loading and airspeed. Required model parameters are computed automatically from flight data using a program that Peter Hollands wrote.

Helical turn controls has been thoroughly flight tested for over a year, and has been found to perform quite well, including the following advantages, for example:

1. Tight, smooth, aggressive turns in both normal and inverted flight. For an airplane with ailerons, the controls can put the aircraft into a turn in less than 1/4 second, and can provide stable control with a turn rate up to the limits of the ranges of the gyros and accelerometers.
2. Level flight during a 180 degree roll over from normal to inverted flight.
3. Easier low speed hand launches because the controls automatically adjust angle of attack and elevator trim for changing airspeed.
4. Projection of earth frame pitch control onto body frame control surfaces, so pitch control is maintained in any orientation, including knife edge, or during a slow roll.
5. Elimination of the need for integral feedback. Using helical turn control, a combination of feedforward and proportional feedback performs better than conventional PID feedback control. This simplifies the selection of gains. The controls work well over a wide range of proportional feedback gain settings.

Here are a few pictures from recent actual flight testing with my EasyStar. First, a few circuits around a rectangle in waypoint mode are shown. Please note that some of the flight segments and turns were flown inverted:

Next, a close up of the tracks through waypoint 4. Note that there are many tracks and they are all within a few feet of the waypoint, in all three directions:

Finally, a view of a 180 degree roll over from normal to inverted. Note that the controls automatically account for the reversal in sign of the wing loading and adjust the angle of attack and elevator trim to maintain level flight. You can see that the plane quickly pitches up a bit once it becomes inverted:

By the way, one problem I ran into during inverted flight was that the EM506 GPS that I was using stopped working when it was pointed toward the ground. A friend of mine at our flying field, Robert Pixley, suggested a solution that I did not think would work, but it did: mount the GPS vertically instead of horizontally:

What I found was that with a horizontally mounted GPS, there were typically 10 or 11 satellites in view during normal flight, and at most 4 in view during inverted flight. With the vertical mount, there were 8 or 9 satellites in view all of the time.

Finally, a thanks to all of the MatrixPilot developers and users who helped me with this, and a few links to those of you who might be interested in the MatrixPilot project:

MatrixPilot project home page.

UAVDevboard available from SparkFun.

Helical turn controls firmware.

Best regards,

Bill Premerlani

We recently tested our Structure from Motion (SfM) and Virtual Surveying approach in a road survey scenario. The only significant manual work in the field was to survey ground control and check points. Image acquisition (with a Pixhawk equipped quad copter and a 24Mp camera) as well as SfM processsing was a highly automated exercise that quickly produced BIG data. To extract the essential data, Virtual Survey Tools was used to bring conventional field work to the safe and comfortable office environment. For more details see http://drone2gis.com/new-tools-for-accurate-and-safe-road-surveying/

We've been working on a laser scanner that is light enough to be carried by a small drone. Click on the image above to see a short video of the scanning action. This prototype is based on the SF30/C and an extremely lightweight motor drive. Four slip rings are carrying power, alarm and an analog image that is updating at 2000 readings per second. The unit gives saturated laser coverage to detect even narrow obstacles.

The 'scope trace below shows the distance (yellow) and alarm (blue) outputs for a 360 degree scan. Straight forwards is in the middle of the trace.

The alarm has been set to pick up the four narrow poles spaced around the center of the scan. The unit can measure out to a radius of 100m and draws less than 500mA at 5V during operation. Interfacing is easily done by either monitoring the digital alarm or collecting analog results in order to draw SLAM maps.

This scanning laser can be used for accurate positioning in complex indoor or outdoor environments or for obstacle detection whilst the drone is operating close to the ground.

We will be packaging this prototype over the next few months and plan to release it with a retail price of US$999.00

Been having a lot of fun with the Mako wing & Arduplane (APM), here's a short video of the build & some FPV flying. Really happy to see Tridge keep APM support in 3.3!

Params: mako autotune params

High res images of fuselage:

From Hackaday:

KATSU, Dan Moore, and Adafruit’s Becky Stern are trying to perfect a flying can of spraypaint, and they’ve met with some success and surely many broken props.

The team used an Iris+ for this project instead of the Phantom used by [KATSU] earlier this year, but the principle of the entire endeavor remains the same: fly up against a wall, flick a switch, and watch paint come out of a spray gun. To get the can spraying paint, they modified a can gun to accept a micro servo. This servo is connected to the trigger mechanism of the can gun, and the entire unit is slung under the quad.

Getting a quadcopter to put paint exactly where you want it is hard, even indoors. Luckily, the Pixhawk inside the Iris has sensor inputs and an ‘altitude hold’ mode that can accept a sonar sensor and can be programmed to stay a set distance away from a wall. These sensors are susceptible to interference, and a proper, shielded cable had to be made, but the sensor did work.

Flying the quad did not go as smoothly. The swinging can of paint changes the center of gravity of the quad, and even flying indoors proved difficult. Still, if you’d like to give it a go, [Becky] put up the instructions for their build. You can see the hover attempts in the video below.

Hi ALL!

We are introducing PRO-X1 Drone. It's a drone made for work, with a full ABS 3D printed, CNC aluminium and Carbon Fiber frame parts and structure.

Development, Design and  high quality manufacture from Bolivia to the world. The flight controller is an ATMEGA 2560 with a Multiwii code modification. Comes with a Ublox customized GPS, Tarot 2D Gimbal and 5.8 Ghz FPV TX/RX 200mw.

PRO-X1 is an OpenHardware Drone and OpenSource under Creative Commons licences. It's will available for preorder in http://drone.bo if you want a fully PRO-X1's Kit and Production.

Follow US on Facebook: Drone.bo

Channel on Youtube: DRONEBO_TV

Hi everyone,

(We wrote a post on the 3DR blog about the gimbal development - check it out if you are interested to get some insight into how it is going. I'm also posting the same content from the post over here at DIYD.)

Inside 3DR: A look at the gimbal development proces

At 3DR we are big believers in open—both in terms of software development and in terms of communication with our community. We’ve lately been hearing lots of questions about the Solo Gimbal—when will it be out? why isn’t it out yet? what can it do? how good is it?—so we thought we’d open the doors and share some insight into how this complicated product is progressing.

We will be keeping these doors open until we ship the gimbal—you can expect updates from us on about a weekly basis, posted to the 3DR blog. Our goal is here isn’t to answer every question (we wish we could), but to share more about the product development process of something as complex as a 3-axis, super-advanced gimbal.

We’ll tackle some initial questions now in this post.

HOW GOOD IS OUR GIMBAL?

Here’s two links to sample footage from the gimbal. First, one of our flight test folks, Terrence Williams, shot recently on a prototype Solo and prototype gimbal:

Solo in Oakland Video (With Adobe Premiere Warp Stabilizer set on Position, Scale, Rotation at 25%.)

Second, here’s a video of Solo’s Smart Shot modes that we filmed with the gimbal in one flight, with one battery, in Cabo—zero post-stabilization on this one.

We are pretty happy with these! We’re working on more improvements in software, but we believe we’re off to a good start.

WHO IS DOING THE WORK?

Designing something this complex at high volume is a big effort.

In our case, the core engineering is being done in Berkeley and San Francisco, partnered with a firm in Austin, and with 3DR engineers flung across the globe, from Brazil to Australia. We’re producing the gimbals at a super nice factory in Guangzhou, China.

WHERE ARE WE NOW? AND HOW DOES PRODUCT ENGINEERING WORK?

We currently have fixes for a variety of issues, which we’re testing now in California and soon in our factory in China. We are also working hard with the GoPro team to ensure the GoPro control from the mobile app works great.

In terms of schedule, the Solo Gimbal is set to enter a “DVT2” phase that will quickly turn into “PVT.”

…let’s next explain what those acronyms mean!

Most hardware product development processes follow a similar pattern. Whether you go to Apple, Fitbit or 3DR, you’ll usually see the same acronyms—DVU, EVT, DVT, PVT. Generally, this process takes between 12 and 24 months, from first concepts to products ready on shelves.

Early on in the product development process, the core engineering and design team will work on a series of prototypes. At some point, the team feels confident that they have a design they’re ready to release to manufacturing—this is usually called the DVU (“Design Validation Unit”).

At this point, you begin to invest heavily in manufacturing tools—plastic injection molds, inventory and so on—so you need to be confident in your design. There is a long waiting period—8 weeks is common—while these tools are built, so during this time the engineering team will focus on work in software and electrical.

Once the factory is able to produce its first units, you see a series of prototypes called EVT, DVT and PVT. In the EVT (Engineering Validation Test) phase, the factory will attempt to reproduce the DVU—generally there are lots of things that don’t quite work about the EVT unit, so this is a big learning experience for the company and the manufacturer. These issues are addressed with the next step, the DVT (Design Validation Test), which corrects many of the issues discovered in the EVT; the DVT also provides the first opportunity to try out the mass production assembly line, including test fixtures and so on. At this point, the goal is for the DVT unit to look like and work like the product spec pretty closely. Finally, in the PVT (Production Validation Test) phase, the company and manufacturer make a limited run of products that are actually sellable units.

For complex products, a fourth or sometimes fifth iteration is introduced (e.g., EVT2 or DVT2) to reduce risks that crop up during the development process. The Solo vehicle, for example, had a DVT2 phase to help us fine tune things like the antenna design.

DVT gimbal being tested

 

The 3DR team is currently testing some fixes in the gimbal DVT2. These include an issue in which about 2% of the units built to date will occasionally over-current the motors. Again: We have a fix for this issue in place, and we want to test it thoroughly before releasing the gimbal to the public. We understand that 2% doesn’t seem like a lot—many products would launch with a yield this high (98%)—but we are laser focused on increasing the quality of the user experience so we want to eliminate even risks of this size.

Another issue we’ve solved is making sure that the flex cable—the flexible cabling connecting the control signals and HDMI from the GoPro to the Solo—are properly spec’d (impedance matched, in the case) so that we have stronger guarantees on long-term quality. So far, the gimbals we have work well with regard to both controls and video, but we need to be pretty specific about these details so that we can reduce the risk on long-term issues for our customers.

We’ll talk more about our problem solving in future posts, but we hope that this taste of product engineering gives you a sense of the size and complexity of issues that companies making mass scale products must address in order to ship a product to customers with the highest confidence.

Hi guys,

I and Phil Kocmoud are proud to announce the new ACSP3 - current/voltage sensor with analog and I2C interface.

Here are some device features:

• Vin max = 42VDC ( 10S )
• Ishunt current = 90A
• Vout = 5.4V
• Ioutmax = 2.25A with 3A burst
• Ultra low noise/ripple <10-12mV
• Analog + I2C interface
• Dimensions - 30x30mm

The new current/voltage sensor uses INA169 for analog current readings and dual I2C ADC for digital readings. The ultra low noise DC-DC Buck ( LT8609 ) makes the device one of the most silent. The board comes with 2x4 0.1" presoldered header.

A simple Arduino code attached showing an example of I2C voltage data readings.

Now we're performing the usual current/voltage stress tests and hope the device will be ready for the market very soon.

Some more pictures attached.

Best regards

Nick Arsov