Blogs

Dear Friends and Developer,

in this video is possible to see the result of integration of VR Spark on board companion computer to video Payload.

Actually we implemented the integration with GoPro and Sony . In this demostration is possible to see how we decide to implement the Pilot user interface. Instead to copy the approach did with 3DR Solo we prefer to implement quite different approach instead to use the Smartphone or Pad with our VR Pad Station application only , we prefered to use the compannion computer to control the status of 4 switch on Taranis Radio and configure it with more usefull functionality.

On the 4 switch we assigned control of video , photo , near , standard and wide field of view and video resolution 1080P , 2.7 K , 4K.

On the VR Spark we have a standard osd and analog switch between FPV Camera and Payload camera. 

All this kind of configuration available on standard GoPro App is possible to assign to 4 switch. 

In the next video i'll show you integration in the PAD and digital stream video with low latency :) 

For more information about Spark you can see this link : 

http://www.virtualrobotix.it/index.php/en/shop/multirotori-rtf/spark2015-detail

Best

Roberto 

We are very happy to introduce our new development "World Drone Viewer".

Drone World Viewer is a monitoring service drones, use our GPRS communication module specifically developed to allow communication with APM2.X, PIXHAWK and all those systems that handle the MAVLINK protocol.

The device is very easy to install, for example 3DRobotics IRIS is only necessary to connect 4 wires ( vcc, gnd, tx, rx )
It has a very low current to avoid sacrificing time of flight (25mA on Tx). The refresh is done approximately every 2 ~ 3 seconds (depending on the cellular network) .Currently its sending only lat, long, alt, flightmode, speed, voltage and remaining battery.

Our website is: WorldDroneViewer where you can see the vehicles that are up in the database.
The site is still in development and we expect in late June have our version 2.0 of pcb for better installation.
Meanwhile, we continue to update the product and connecting more vehicles to the system.
If someone is interested on this project pls let us know at wdroneviewer@gmail.com

3DR is proud to announce that today we’re opening the source code for the Solo flight controller. Solo is a consumer product, aimed at simplifying the process of getting great aerial footage. As a development story, true to 3DR’s open spirit, Solo was developed not just by us at 3DR, but in concert with the ardupilot core development team and contributors around the world. Solo’s flight characteristics, performance and robustness are a testament to the power and adaptability of APM:Copter, which is why we’re so pleased today to officially open that source code to the world at large: The repository with full history is now available for download on GitHub, the first of many development doors that we’ll be opening on Solo.

In addition to opening Solo source, we are today publishing the set of guiding principles that went into developing all of Solo’s subsystems--3DR’s Open Source Policy. The policy, developed by the 3DR software engineering team in conjunction with the the community, addresses key questions: How do we do development? What do we choose to open? Why do we do it in the first place? For 3DR, the policy represents a set of guiding principles on how we plan on doing development, and we feel it important to, in turn, open to the broader community for clarity, accountability and, well, because we’re excited to share it!

Solo: Open for development

We placed open source hardware and software at the core of Solo and view it as essential to our development and platform strategy. But it doesn't stop with the source! We strive to put powerful tools in the hands of developers. In some cases this means source code, and we plan on opening other parts of Solo, including much of SoloLink. In all cases this means making Solo the number one development platform, which means great APIs and developer tools. We plan on deepening DroneKit integration into Solo, so that developers can easily add new shots in Python and apps on Android, with new language bindings for other platforms coming soon.

The word ‘platform’ is getting quite a bit of traction these days. However, we believe it’s not enough to call something a platform ahead of building it. A platform isn’t an over-engineered airframe, coincidentally exposed cables or slides in a presentation; it’s a bolt pattern, a pinout, an API and a source code that exists in the real world with engineers to support it. So rather than pay lip service to the term, we chose to place the world’s leading autopilot development platform--APM:Copter--at the heart of Solo, running on the new Pixhawk 2. Connected to the flight controller we have SoloLink, which brings the power and flexibility of Linux computing onboard a consumer vehicle for the first time and appeals to an even broader set of developers. We also added an accessory port, 3DRBUS, on the bottom so that kickstarter projects, academics and businesses can easily integrate their own hardware. We developed DroneKit for use on Solo so that web and mobile developers can build businesses on top of this hardware and software. Most important, we know a great platform gets better with time, and we plan on supporting Solo for years to come.

This is the Solo Developer road map. Let us know what you think. Help us build Solo into the premiere drone platform, and the best home for developers around the world.

From Hackaday:

Kerbal Space Program, the game that teaches engineers at JPL and SpaceX the basics of rocket design and orbital mechanics, recently had a giant update. There are now science contracts that require you to fly Kerbals all over their tiny globe, collect data, and transmit it back to the Kerbal Space Center. As would be expected, this is a grind for XP, and the contracts sometimes don’t make sense – you need to collect data from cliff faces and mountain tops. Landing a Kerbal jet at these places is hard.

[Matt Thiffault] wanted to do these science contracts more efficiently. The best way to get to a remote location without a landing strip would be a helicopter, but a harrier jump jet would do just as well. This isn’t supported in the stock game, so [Matt] wrote a complete control system for four engines to control a hovering Kerbal jet.

[Matt]’s work is built on kOS, a scriptable autopilot mod for Kerbal that was originally intended to be something like the Apollo Guidance Computer. People have been using it to make computerized skycranes andautomated rendezvous and docking programs, but these are actually relatively simple examples; there’s far more math involved in flying a quadcopter than there is getting into orbit.

To build his automated hovering harrier, [Matt] needed an aircraft. His Kerrier has parts from the Kerbal Aircraft Expansion, B9, and Infernal Robotics mods for KSP, but this is only half the problem. Anyone can put four tilt jets on an airplane, and it takes a real wizard to force a control system to hover. Hover control of the Kerbal harrier is accomplished with a complete control system for a four-engined aircraft, with proper PID control loops and code updating at 20Hz.

With kOS, the proper plane, and the right software running on this emulated guidance computer, [Matt] is able to park his plane in mid-air, have a Kerbal descend the ladder, perform some science, and return to base. It’s an impressive amount of work for a video game. A good thing, too: [Matt] is looking to get into controls engineering professionally. Whether this will go on his resume is another question entirely.

A new Beta Release of APM Planner 2.0 has been released. Notable fixes in the release are

- Google Maps API update.

- TCP/UDP displayed in Toolbar - Connections over TCP/UDP are now shown in the toolbar.

- UDP Client Connection - sends packets to a known host.

- Extended Tuning updated to support AC3.3-dev

- Accel Calibration udpated to new method

- Elevation Widget fixes

- Basic Joystick Support (experimental) (It does not remember setting over restart TODO)

- Radio Calibration works again with 6CH Radios 

More details here

Download from http://firmware.diydrones.com/Tools/APMPlanner/beta/ or enable the beta option in AP2 Config View 

DJI have released a detect sense and avoid system with their Guidance unit and a new quad in the Matrice 100

Nothing too earth shattering about them. The new developers and ideas that might flow in DJI’s direction is interesting though.

Not quite so many DJI systems are being used by universities and research institutions as other open source projects. By their very nature open source autopilots can be fiddled with and changed to suit whatever is being researched. That code is fed back into the eco system and the open source autopilots gets cleverer.

A rising tide lifts all ships.

DJI need a hand keeping up.

Video : https://www.youtube.com/watch?v=P2Xdf0iEQ6A

Credits to Gary Mortimer from SuasNews : 

http://www.suasnews.com/2015/06/36475/dji-matrice-100-and-guidance/

Landing on your back porch? In close proximity to trees? And near your grandmother? :) 

We produced documentation regarding the 'Precision Landing' developments (link). The primary intent of this development is to enable more industrial use-cases for multi-copters, namely, fully automated systems with auto re-charge capabilities. However, it is also useful for assisting manual landings in tight spaces. I typically would not attempt to land on my patio, near a house, under a tree, and on a table. 

The assisted landing uses a Sensor/Beacon system (link) to center the IRIS+ over the IR Beacon when in Loiter or Land flight modes. In the above video, we are using a modified version of AC3.2.1 which uses readings from the Sensor/Beacon system. In short, if the Sensor detects the Beacon, the copter will hover over the Beacon. If the Beacon is not detected, the copter operates as expected in Loiter/Land.

Loitering over a Beacon is demonstrated in the video below.

Randy shot a very nice video of a precision landing. This development will not be in the AC3.3 master. We are still experimenting .... Also, note that the 3.3-based version (demonstrated below) is somewhat different than the 3.2.1 version. You can read more about it here (link). 

I am also curious about the use-cases for fixed wings. We have had requests about this, but my knowledge on the matter is limited. Feel free to shoot me a message (thomas at irlock dot com), or reply below. 

As you may have read from my previous blogs - I’m experimenting with an autonomous pilot system that is able to guide several vehicles in a coordinated fashion. Each vehicle is outfitted with a transmitter that sends telemetry information back to the main computer, and the main computer sends back guiding commands.

The telemetry is based on 3DR serial link radios (915 mHZ version). I did however find that the normal dipole antenna was heavy and was often “in the way” of propellers, airflow and just a general nuisance.

I discovered that Molex was producing an antenna for the same frequency band, that was quite different from the normal dipole and decided to try it out.

The antenna weighs less than 1 gram and has a self adhesive side which make it perfect for mounting it directly on to the fuselage or the wing - a short wire then connects to the radio through a cmx connector.

The advantage is that you can easily place the antenna somewhere on the body or wing and because of the light weight, it will not upset the balance of the plane nor create any drag.

Testing it out

I decided to mount the antenna on the wing of my trusted Z-84 also known as UTV-3 - It has become the workhorse of many experiments and has the most flying hours.

I flew in increasing distance and height and monitored the signal strength and telemetry errors.

This is by no means a thorough scientific test and comparison to the standard dipole antenna, but I experienced very little error (<1%) and I flew as high and far as the law allows.

I definitely will use this kind of antenna on my next builds because of their low weight and ease to stick on the fuselage or wing.

I'd like to invite the diydrones members to participate in a project I started on github: Project Ion on github

The control of uav's have improved a whole lot in the past couple of years and you can now pretty much put one in the air and wait for the results to come back, whether these are videos or images. There are numerous posts and videos of people who show how they made orthomosaics, 3D models, point clouds and digital elevation models.

I started Project Ion with that motivation in mind; thinking from the perspective of your customer (or your own needs), how do you grab the orthomosaic / DEM you just created and start to answers the real questions that end users have and answer those questions in a visually compelling way?  Not every office contracts a bunch of engineers to work with ortho and DEM data.

The work above was done with a team of experienced surveyors. In this case I played a supporting role to provide them with the orthomosaic, which was for visualization purposes. They used the geo-referenced ortho themselves to validate their collected data points. Since I have my own methods to derive an accurate set of control points, you get two disjoint data sets which have no dependency on one another. Here, I'm just demonstrating how the ortho could be annotated with help of some of their survey points to better visualize the land and the boundaries. In many cases, surveyors provide an iconic diagram of the land made in autocad and they don't have acces to a recent ortho. So it makes sense to also think towards support roles for uav in surveys, where the orthomosaic is just used as a means of cross validation and visualization of the results.

Another thing that came up is that the area had recently been leveled. They were interested in the accuracy of this leveling. With a contour map, you can easily process the DEM to extract these contour lines at any interval. Of course, everything can be exported to CAD tools for further processing.

All images above were made with the help of QGIS, now starting to become a very powerful GIS application with a bunch of plugins for many different purposes.

So I'm looking for contributors to set up this knowledge base. Not everything has to be written as a tutorial on the wiki, the idea is to link to existing content, link to videos and just show what others have done, generate ideas and make it a wiki that you can browse to find really cool applications that go further than orthomosaics from pix4d/photoscan, then explain how such resuls are achieved, etc. I'm not excluding that the project develops some of its own scripts and tools to faciliate in that process.

How to become a collaborator? Send me a privmsg on diydrones if you're interested and your github username so I can add you as a collaborator on github. If you don't have a github account and want to send me a cool link to some video or tutorial on how uav data is being used or applied, feel free to send this in a privmsg as well.

Finally was able to get the project back into the water after a 2 month hiatus. I have been trying out different props. One is the standard manufacturers issue and the other has more torque. I launched during a flood tide with winds out of the East at 10 to 15 mph. Max speed was around 7mph with the tide (the wind probably wasn't much of a factor since the boat has practically no profile).  The higher torque prop requires more Amps in the midrange, but gives a higher speed and also has more bite against the tide.

After launch I will begin to receive telemetry via satellite. Does anyone know of any non-profit organizations that would be interested in the data? Just post it to twitter?

• Location
• Apparent wind speed
• Wind direction
• Air Temp
• Bar pressure
• Water temp
• Water PH

Last time I posted an update someone asked for a video, here it is in action.

The first Solo's are now arriving, and reviews are great (you can now order it here). The next thing to arrive, in a few weeks, will be the custom 3DR gimbal, with integrated GoPro control, HDMI video down the app and smart autopilot control.  But the main thing people want to know is how good is the video? This good!  

From the team:

We’ve received so many requests for footage from the Solo gimbal, we took a break from some time out filming with Brainfarm in Cabo to shoot a quick example of Solo’s Smart Shots, shot from one of our Solo gimbals in final testing. This is footage straight from a GoPro Hero 4 Black shot at 1920 x 1080 at 60 FPS with no post-processing for fisheye removal. You can look forward to even better footage with your Solo gimbal as we lock in changes from final tests and begin shipping!

Now live in the iOS and Android app stores!

The full list of supported devices is here:

It has been a while since my last article about Andruav.

Now Andruav has version 1.0.51. Some nice features have been added to Andruav -most of them were part of the road map-.

Andruav is originally seen as a system that allows multiple GCS & Drones to communicate with each other. Multiple GCS should be able to track multiple drones simultaneously, even drones should be able to communicate track each others, and form a fleet. And moreover, is to try to accomplish this on different drone types with different flight boards.

Andruav is neither intends to be a drone firmware nor a complete GCS where you can set PIDs for your board, it is a big brother -or high level controller- for the originally installed flight control boards.

Enough Talking for future :)

I want to mention some new features and technical challenges that Andruav had to solve. Andruav used to be able to act as a 3G/4G telemetry between flight control board "FCB" and a GCS software such as mission planner or EZ-GUI for multiwii. Now Andruav took another step, it is self aware of the existence of a FCB.

Andruav can communicate with flight control boards, either APM or Multiwii.
           1- It can detects "automatically" what type of board is connected.
           2- Distinguishes the type of vehicle, and firmware versions.
           3- Gets IMU data from FCB

Andruav-drone can switch intelligently between mobile built-in IMU and a connected flight control board IMU when available. So when you open the FPV screen of Andruav-GCS mobile you no longer see IMU of Andruav-Drone mobile sensors, but you see FCB IMU data -if exists-.

You can also change flight modes from Andruav, with no help from a third party GCS, this is limited to APM for the current version.

As above image shows, You can even use on-screen RC to control your drone -considering 3G delays you should wisely select the flight mode-. RC sticks can work on both Multiwii & APM although the logic of controlling is different between Multiwii & APM. The first uses a time out approach, while the second uses a release approach to release sticks and get back to TX.

Another challenge is that multiwii IMU data is different in type and scale from APM. This has been solved via constructing a shared model representation for the vehicle, that is independent from FCB and protocol specs. Yes this means some details might be hidden, on the other hand, you have a generic system where hybrid vehicle types, equipped with different system can communicate and work together.

This unified view is what differs this version from the old 1.0.30+ version that has a telemetry option to enable third party application with no actual understanding of what is being sent.

Next step is to enhance some GUI especially in FPV to enable sensor fusion between FCB & Drone mobile sensors, also a drone-to-drone communication is coming soon.

This post analyzes the latest commercial drone forecasts and debunks some prevalent myths and hype. 

---

Have you noticed the growing number of market forecasts for the commercial drones industry?  I have.  Not a week goes by that a new one doesn’t hit my radar.  I’m currently tracking about 15.  Each in one way or another delivers growth projections for the drone or unmanned aerial system (UAS) sector that are nothing short of phenomenal.  But are they, really?

In this post, I’m going to share three secrets to help you understand forecasts better, unpack the hype and diversity of market reports, and hopefully leave you skilled enough to ‘cry foul’ when you see a new report that is, well, questionable. At the end, I’ll give you my personal take on the most popular forecast reports.

THREE SECRETS

Read more here: http://droneanalyst.com/2015/06/04/diversity-and-hype-in-commercial-drone-market-forecasts/

Flight testing the latest APM Copter by iUAS aka Walkera.  x350 Premium, this one with 2 cameras (with OSD) and dual GPS/GLONASS satellites.   NASA Spaceship looking design, 350 size.

Researchers at ETH Zurich have developed a new algorithm for robustly controlling a tailsitter flying machine in hover position.

Read more on Robohub

Great news (thanks to Chris Miser from Falcon Unmanned for the tip):  the US government has started requiring open source technology in its UAV purchases. See this RFP from the US Department of the Interior for example (pages 8, 10 and 12). Right now it's just the ground station software that needs to be open, but how soon until it's the whole stack?

The US Government (including the Department of Defence) already uses a lot of open source software (see this FAQ), but I think the extension of this policy to UAVs is new. Anybody know of other examples?

One other cool thing open source datapoint: DARPA awarded a half-million dollar contract to our DroneCode partners the Open Source Robotics Foundation for swarm research, including with drones!

I know we've all been a bit Kickstartered-out of late, but this latest one seems more interesting than most since it's designed to be an easy programming environment. It uses the Intel Edison module and the PX4 flight code, which is a good choice for power and ease of use:

Assemble Eedu: Eedu is a drone that can be quickly assembled using the included tools. It is compatible with Arduino shields and other open source hardware.

Enter Forge: Once put together, Eedu is ready to be synced to Forge, the software part of the kit. Forge is a Robotics Development Environment (RDE) that runs on your web browser in the cloud. It brings together the best of ground control, community interaction, and code development. It will even teach you how to code! It is the world’s first complete community integrated development environment for drone applications. Best of all, it’s all open source, so anyone can contribute.

Fly your app: Once your app is built, it will compile on Eedu, and you are ready to try out your very own “homebrew!”

Click here to skip the commentary and just see the vehicle flying.

The video above shows my first attempt (which was successful) to fly APM:Copter using a Linux board (the NAVIO+ shield + RaspberryPi2 from emlid.com).  Ardupilot and APM:Copter have flown before on Linux computers (Tridge flew ArduPlane Aug 2014, and Victor Mayoral first flew APM:Copter using an Erle-Brain board) but it was a first for me and is still fairly rare.

Compared to the Pixhawk the NAVIO+/RPi2 has enormous amount of CPU power (quad core 900Mhz) meaning it should be good for vision applications like red balloon popping, visual follow-me, precision landing and maybe wifi broadcast for real-time video all without the need for an extra companion computer.  We also hope the extra CPU will allow 4kHz sampling of the IMU which will nearly eliminate aliasing and the need for vibration isolation (we currently sample at 1kHz).

We don't yet take advantage of that extra computing power within ardupilot though so it flies much like an APM2 or Pixhawk with all the same flight modes and most of the same features.  A few things are not supported yet including the safety switch, external LEDs, buzzer and Optical Flow.

The setup for the board is more difficult than the Pixhawk, in particular upgrading to the latest version of APM:Copter involves logging into the RPi2 and then downloading and installing a package.  Alternatively you can download the firmware directly from the ardupilot github repo and compile it right on the board.  The emlid site has good documentation on this procedure.

During the setup I had some specific problems:

• I did not use an external compass and the internal compass's offsets were huge (1000 on Y axis!) which required disabling the compass arming check.  Surprisingly though the IRIS flew fine even in Loiter and Auto modes.
• The RC receiver is not powered from the NAVIO+ board meaning a BEC must be used (or I hacked an I2C cable and connected it to the servo rail) which is inconvenient for bench testing.  I hope in future versions of the board this is changed.
• The two-board sandwich is taller than an APM2 or Pixhawk which meant I had to bend some pins to make it fit within the IRIS case (see pic below).  Perhaps a future version could include right angle headers.

On the software side there's still some work we need to do to improve the Linux experience so if there are developers out there who would like to help us with this, please contact the dev team on gitter or on drones-discuss@googlegroups.com.  Linux is the future and we've got a lot of fun work to do!

Note: in the video I incorrectly say SBUS isn't support but it is supported!