Congrats to Timothy Chung, Michael Day and Michael Clements at the Naval Postgraduate School, whose work on APM-based swarming has now reached 30 aircraft in the air. News here and great coverage from NPR:
At a restricted airfield at a quiet National Guard base in central California, researchers from the Naval Postgraduate School have loaded a drone they call a flying wing onto what looks like a giant sling shot.
The drone soars up into the air and settles into a racetrack pattern. It's up so high it's hard to see, but the sound is inescapable — like a buzzing bee. With the launch of several more, the buzz grows louder as they all settle into that racetrack pattern.
The aim is to get 24 drones into a swarm and have it behave like one.
"In our context, swarming means a large collection of aerial robots working together to do something meaningful or interesting," says Timothy Chung, who is heading up this project for the Naval Postgraduate School. "The one behavior that we're testing out today is a leader follower behavior where the aircraft talks amongst themselves."
The drones talk to each other over WiFi. Once up in the air, they are programmed to determine who the leader is and the other drones follow 50 meters behind.
"And so those types of algorithms make it a lot smarter, more intelligent than what we typically think of as just drones," says Chung.
It's why he prefers to call them unmanned aerial vehicles or UAVs. Although a pilot is on standby to take over if needed, the UAVs are autonomous: The last moment of direct human contact with these UAVs is the launch.
The point of today's experiment is to get as many UAVs swarming as possible and do it cheaply. Each costs about $1,000. The idea is to go for the expendable rather than the exquisite.
"There are some tasks where you are going to want something small cheap and maybe even disposable," says P.W. Singer, a strategist at the New America Foundation, a think thank in Washington, D.C.
For example, out at sea, where he says a swarm could spread out and be in more places at once, searching for an enemy fleet, perhaps.
"Or maybe it's not just about finding the enemy but doing something about it," says Singer. "With swarming you can surround an enemy, target and overwhelm its defenses, so that even if they were able to shoot down 90 percent, that last 10 percent can still cause damage or even sink you."
There could be civilian uses too. Swarms could monitor large agricultural fields or help add eyes in the sky to a search and rescue operations.
But the technology still faces challenges.
Some are political, such as following air traffic rules and concerns about privacy. And some issues are technical, such as withstanding high winds, or having enough power to stay in the air for long periods of time.
Chung is one of several researchers across the country working on swarm technology because the military has identified it as a priority.
At the end of this experiment the drones land, one by one.
"Our intent is to keep pushing. To be able to have these technologies mature enough to be able to deploy up to 50 in the near future," Chung says.
He believes his team holds the world record for the largest swarm. After getting 20 in the air back in May, they tried again just last week and got 30.
We have seen recent press announcements of big names investing lots of effort and money in package delivery using drones: Amazon, Google, Nasa (Flirtey), DHL, etc... These organizations are spending huge sums of money, as a non-public private research, to carry drone deliveries, and this for a few years. In the meantime, our modest diydrones community, that means you, have got all the means to build a drone delivery system. It is impressive how since a couple of years that I am active in this community so much has been produced and gathered in competence, skills, developments of open source hardware & open source software.
Especially, a big thanks to diydrones community developers, 3DR for promoting it and also ETH Zurich/3DR who have produced a very reliable Pixhawk autopilot, building up competences and skills to levels that even Amazon and/or Google would dream of internalizing. That's the magic of open source: you get better team work and results with free willing motivated volunteers in comparison with typical corporate organizations.
This blog synthesizes hardware, software configuration information in an attempt to explain how to make a drone delivery, fully autonomous, mission.
II - Delivery mission’s preparation:
II.1 - Safety message:
This video does not intend to promote an illegal nor reckless use of drones. So first thing is ensuring you are in legal order to execute such a delivery mission in accordance to your local regulatory authorities. The mission is here executed fully above privately owned properties with agreement of their owners, in a rural non populated area, keeping permanent line of sight, either from the departure or arrival location (two operators are prepositioned at departure and arrival sites for precaution and take manual control over in case of emergency.
II.2 - Analysis of the delivery mission’s path:
A careful analysis is required of the delivery path the drone will follow in order to: avoid obstacles as we do not have any technologies to detect them yet real time in flight (such as electrical lines for ex), fly around any populated areas to avoid them, take into account the terrain’s topology along the way to avoid hitting hills, mountains, trees,...
To take into account the topography, you have two options in current’s mission planner:
you can plan you waypoints at different altitudes, taking into account the relative altitude differences between waypoints (manual altitude offset management – that is the method that was chosen for this mission as described further);
you could plan your waypoints as usual in mission planner and check the “verify height” checkbox in mission planner’s flight plan window. In this case, the google map ground altitude for each waypoint is added to your waypoint desired altitude. This is theoretically a safer way to go than first method; however we noticed in our tests a few issues: mission planner’s ground altitudes are not the same as google earth altitudes (strange discrepancy) with differences of a few meters (enough to crash!) and google altitudes are incorrect (sometimes also by a few meters);
A future third method will be the best of all, once ready for use: in a next release(s) of APM:Copter, terrain following will be made possible (already available in APM:Plane 3.x). That consists in storing, on Pixhawk’s autopilot microSD card, a terrain database which gives the terrain height in meters above sea level for a grid of geographic locations. Terrain following is different than the current “very height” method as the autopilot will permanently check the topology’s height variations to correct the drone’s altitude (versus the verify height method that only checks the altitude at waypoints, but not between them).
For this current delivery mission, the following manual topology analysis has been done, preferring to calculate and plot the terrain’s height variations manually. The following picture and graph shows the altitude (in meters) of the delivery mission’s path, with departure location (“Home” point) on the left and the arrival location on the right (“delivery target”). The intended delivery mission paths, roundtrip, is a little bit more than 1,5km long (or about 1 mile long for non-MKSA countries):
The picture shows a visual Google Earth representation of the full delivery mission and the ground’s altitude topology along its way.
From such a graph, we now know that:
Home altitude is 265 meters
Target altitude is 298 meters
By difference, an offset of 33 meters must be added to the destination’s waypoints altitudes; further add a safety margin of a few extra meters in order to take into account of :
Pixhawk’s barometer drift issue (that we have discussed already a few times on diydrones) when flying more than a few minutes.
the Google Earth altitude precision errors
your own eventual calculation precision errors!
Total ground travel distance is 765 meters, one way. Be aware that, when flying, your drone will also spend some “travel distances” vertically between waypoints to reach desired altitudes (that has an impact on your batteries/autonomy calculations!)
In this example, there are no higher obstacles above 298 meters. There could be towers, electrical lines, etc…DO NOT FORGET to add a safety margin on your waypoints altitudes to mitigate these eventual obstacles! The only good way to do this is a ground survey at destination. Do NOT RELY solely on Google satellite images as they may date from few years (and in the meantime some pylons, towers and trees may have grown J).
Thus make a thorough terrain reconnaissance, not only at departure and arrival points. Check google map data and complete its imprecisions with a field survey.
III - Hardware & Software configuration:
III.1 – UAV ship hardware selection
For such a delivery mission a reliable ship must be used. It must at least comply with the following requirements:
its lift capacity must exceed with a margin the all-up-weight including payload;
must have an autonomy that exceeds with a margin the total flight’s duration;
must have longest range as possible telemetry for command & control capabilities (+RC transmitter as a backup);
must have redundancy on all critical components for a safe auto mission: redundant motors, two GPS, external compass, etc…
These minimum requirements de facto exclude the use of drone toys or quadcopters. Do not use a drone that is designed for video/pictures applications (such as an IRIS, a Solo, a DJI phantom) to deliver packages: they will not have the required level of safety, nor the capacity to do it.
Being a custom drone builder, AirbotServices chose its X8 model as briefly described in pictures below:
III.2 - Package lock/drop mechanism:
The transported package must be securely fixed to the drone and a release mechanism must be triggered automatically by the autopilot. A good way to do this, limited to packages lighter than one kg, is using Nicadrone’s electro permanent magnet (EPM). A newer EPM version is said to carry heavier payloads but I can’t confirm it. The principle of EPM is a magnet that can be activated and deactivated dynamically by a commanding signal.
The EPM has four mounting screws to be fixed to the drone. A standard PWM servo cable is plugged on one side on the PWM EPM input, and on the other side on one of Pixhawk’s AUX1 (RC9) to AUX4 (RC12) outputs. Actually, for a reason explained further in the trigger mechanism, only RC9 to RC11 can be used with current stable APM:Copter 3.2.1 firmware.
A metal plate such as this,
is fixed to the package. This iron plate matches the magnetized square surface of the EPM device. Although EPM holding strength has been tested by others to maximum 1 Kg of payload, I recommend to mechanically block any “yaw” movement of the metal plate against the EPM magnetized surface; indeed the strength of such magnet is in the vertical Z direction, not in the X or Y directions, where the payload can slip very easily. In this particular case, four little aluminum blockers were glued parallel and against the four metal plate edges. In a way such that any yaw movement of the payload versus the EPM base is avoided.
Furthermore, as a lesson learned the hard way during testing sessions, be careful not to fix the metal plate directly on a metallic package: indeed the magnetization flux is dispersed outside the fixing plate and the overall resulting locking strength is weakened doing so!
Attachment point and vibrations considerations:
A package adds a large surface area to your drone that will as a consequence catch more wind than usual. Furthermore, vibrations of your transport ship will be affected by the added mass and the way it is fixed (how rigid it is) to it.
APM:Copter is sensitive to vibrations and to keep vibrations low is critical for a safe flight as it impacts the compasses, among other things. Without a working compass, a flyaway is guaranteed…In future 3.3 version, vibrations management has been improved but for now, keep them low. It is thus a good idea to dampen and isolate the transported package from the part of your ship’s frame carrying the Pixhawk autopilot. It is even better if you can fix the package to a vibration free zone of your ship you use usually for your cameras.
During testing sessions, it was found that a “hard screw” fixing was the least reliable solution to secure the package and mitigate vibrations; with package losses due to forces exceeding the 1kg holding force of EPM. Reliable results were found with rubber bobbins (secured enough in tensile strength but still offering some elasticity between the payload and the ship’s structure).
On the side of the package fixing point, where the metal plate is fixed, various methods were tried from simple scotch tape to hot glue, etc.. Best method was simply…Velcro. Velcro does not melt under the sun (as would hot glue during a summer delivery mission) and offers some elasticity and vibration isolation.
III.3 – EPM lock/drop control configuration:
The EPM gripper works by sending three different PWM values to its servo input:
a neutral value of 1500 us when the EPM gripper is at rest. This rest state does not consume any power so it is best to leave EPM’s state at neutral when it is not in the action of locking or dropping the payload;
a low value below 1100 us to drop the payload;
a high value above 1800 us to lock the payload.
So the functioning sequence becomes:
to lock the payload : set the PWM signal high for a duration of about one second (the EPM secures best when it is able to cycle a few times its magnet. This takes a bit of time. One second is typically good). Then set the PWM value to neutral.
to drop the payload : set the PWM signal to low for a duration of one second. Then set the PWM signal back to neutral.
According to APM:Copter online documentation EPM PWM signal may bet set via a consecutive pair of DO_SET_SERVO commands. However this did not work in practice as these commands do not allow to maintain the commanded PWM values for a predefined duration (ideally one second). Apparently the default duration of these commands is too short to reliably command the EPM gripper.
Instead, the DO_DIGICAM_CONTROL command is used. This command offers the advantage that it works reliably, reduces the number of commands from two to one and allows to define precisely the PWM signal duration (by tenths of a second). This is how to configure it:
Connect a servo cable between EPM and one of the AUX1 (RC9) to AUX3 (RC11) ports of Pixhawk (AUX4 can’t be used as it is not displayed in mission planner camera trigger dop down list). Lets’ assume RC11 for this example.
Open and connect mission planner to Pixhawk. Go to the initial setup / optional hardware/Camera gimbal menu. Set the shutter option to RC11, set the shutter pushed value to 1900 when you want to lock the payload to EPM; or set it to 1100 when the payload is already fixed to EPM and you’re ready for the drop mission. As shown in pictures below:
Picture above : RC11 configured as the Pixhawk AUX EPM commanding port. Shutter pushed value set to 1900 to lock the payload.
Picture above : Shutter configured to 1100 value (unlock or drop value)
Open then the config/tuning “Extended tuning” window to set the Ch7 option to “Camera trigger”, as shown in image below:
To test the setup is functional,
To test payload lock: follow the steps above by setting the RC11 “pushed” value to 1900; then go in the main flight data screen; hold the payload against EPM; right click on the map to have thr drop down action list displayed and select “Trigger camera now”. You should hear a few clicks from the EPM indicating that the payload is secured.
To test payload drop: same steps as above except the “Pushed” value must be set to 1100. A right click on “Trigger camera now” should release your payload.
IV – Essential APM:Copter parameters to setup:
All parameters are describe in details in various APM:Copter documentation pages. We provide below a list of the critical ones for a delivery mission.
IV.1 – Failsafe parameters:
In a delivery mission it is most probable you’ll loose intermittently or permanently your manual RC control link and your GCS telemetry link. There are different setup choices of failsafe actions in these conditions but the obvious way to go is: “failsafe action and continue with Auto mission”.
In such a delivery mission you probably do not want the ship to land in the middle of the woods once batteries are exhausted. So the first obvious action is to double check your batteries are functioning properly and are fully charged. To verify your batteries are functioning properly and that all LiPo cells look good, we strongly advise to use a battery resistance meter (this check function is integrated in good battery chargers). The measured resistance of all battery cells should be around a few milliOhms and about the same value for all cells. If some cells have a significant higher resistance, do not use these batteries for such delivery missions! (use these batteries for bench tests or less hazardous uses). If a battery is puffed, do not use it!
About the battery failsafe action, you can choose ether for land or return to launch. It is a matter of opinion but I would advise in the context of such a delivery mission to use the return to launch action; it is indeed better to permanently damage your batteries than having your expensive ship landing in the middle of a forested area.
IV.2 – Geofencing:
Do setup the maximum allowed range (i.e. the radius of a circle whose center is the arming location) and altitude in accordance to the delivery mission’s profile. Doing so, check the RTL altitude to make sure it is higher than any obstacle on the mission’s path so that your ship will not return to home through trees…
During test sessions, try a geofence breach to verify it is working as expected. Geofence parameters and breach actions are setup in mission planner / config-tuning tab / Geofence menu.
V – Ground control resources and initial checks before launching the auto mission:
According to the topology of the terrain, the mission length, it might be required to organize more than one ground control team. At least a ground control station must be installed at departure’s location (“Home”). Its job will be to setup, verify and control parameters, ensure the ship is flying correctly in GPS mode before launching the auto mission. It will also ensure the returning ship lands properly.
A second team is organized at target’s destination. This second team will be given means to take over an eventual required manual control of the ship in case of emergency. This manual control can be direct or indirect via the home point’s team.
In this delivery mission, the remote team (at destination) keeps permanent GSM voice contact with the control team @home. Furthermore a video downlink is organized in such a way that both teams keep permanent video monitoring from onboard camera(s).
The ground control team is also responsible to check that the environmental conditions allow for a safe UAV flight. The following site : www.uavforecast.com is an excellent resource for doing so. It provides, per location, information about:
-wind speeds at the altitudes the drone will be flying. For AirbotServices X8 model, a maximum wind speed of 40km/h is fine.
-Kp satellite indicator, giving an indication of the GPS signals quality. It should be under 3.
-Visible sats : higher the better. 8 is a strict minimum. With a M8N, such as the one used on AirbotServices’s X8 model, a fix with more > 12 sats is the norm. It provides an HDOP around 1 ! (2 is the maximum for HDOP for flying an auto mission)
-Temps
-Cloud cover & eventual rain. You should not fly under rain and heavy cloud cover as this may produce important GPS glitches (and eventual material damages on your electronics if not at least IP67 compliant or above).
VI - Pre-flight/initial flight checks considerations:
The RC transmitter is used to launch the mission, by first taking-off in stabilize mode. This is indeed the only way to verify and “feel” that the ship behaves as it should. If during the short stabilize mode checkup, an unusual behavior and/or parameter(s) are noticed, mission should be aborted until problem is identified and fixed. If the stabilize phase passes successfully, the pilot switch for a short moment to “PosHold” mode. The objective is to verify that the GPS and compasses are working fine. If PosHold is not behaving perfectly, abort the mission. And again identify and solve the issues before launching the auto mission.
If Poshold phase has passed successfully, then the pilot may switch the ship to Auto mode, where the delivery mission really begins with the first waypoint, etc.
VII – Mission execution and results:
As shown in the attached youtube video above in this post, the mission was very successful, especially in a surprising target drop location’s precision, under a meter. This might be due to simple luck but certainly partly due to the use of a high precision GPS based on a M8N Drotek model which has an extra-large shield of 8cm x 8cm which is totally compliant to Ublox’s M8 GPS chip ideal antenna configuration.
VIII - Lessons learned/improvements to consider:
It has already been pleaded by me and others: a better altitude measurement solution than a single barometer chip on Pixhawk. We do not know what the answer could be but maybe using a LIDAR, maybe using some yet undeveloped technology. But something must be improved on that domain as it becomes a very limiting safety and reliability factor for professional uses.
A fix to the DO-SET-SERVO command which did not work in our case and we wish for a functional evolution for this command to be able to set a duration of the produced PWM signal (similarly to DO_DIGICAM_CONTROL)
The possibility in APM:Copter and Mission planner to program flight plans where land commands could be used in the middle of a mission; not only as the a final’s mission command
A mission planner integrated AUX outputs test application able to simulate camera trigger configs, EPM configs and any other aux devices configs. At the moment testing is quite awkward and requires creativity to simulate effective behavior in flight.
-…
There you have it, a package delivery auto mission !
Within the natural gas industry, gas leak detection is one of the crucial tasks in order to operate safely and economically. The high demand for an easy and cost-efficient method to address this issue led Pergam to the development of the Laser Methane Copter (LMC).
The gas sensor isbased on a practice-proven handheld detector that is already widely used in the gas industry. An eye-safe laser with a filter in the bandwidth where methane has a high absorption along with an algorithm measures the gas emissions in parts per million multiplied by meter (ppm*m). With methane being the main component present in natural and other gases, methane detection is a reliable method for leak detection. An on-board data grabber records the flight path together with the gas concentration and stores it onboard. The leak data are available immediately after the flight in a standard format (XLS) to create a comprehensive report. This report can be used as proof of inspection and to indicate areas with high emissions / leaks.
Due to its 600 gram weight, a battery life exceeding five hours coupled with an independent operating system, the sensor can be easily integrated in a wide range of UAVs. At a later stage, a ready-to-go package including UAV will be available. From production, processing through transport and distribution, an impressive number of applications can be realized with the utilization of this sensor. Landfill emission monitoring as well as surveys in difficult to access areas that previously required scaffolding are further examples of usage.
International research institutes have successfully tested the solution in the forefront. The first orders will be delivered at the end of July 2015. A limited number of loaner units are available for test and integration purposes.
About Pergam
Pergam is a multinational corporation with core competencies in remote gas detection and a wide range of nondestructive testing methods (NDT). The headquarters are in Switzerland. A sales and support office in Seattle, WA is dedicated to the needs of the North American market. Pergam provides cutting edge products and inspection services to the natural gas industry. With its unique and patented ALMA and SELMA systems, Pergam is a pioneer in laser based gas leak detection.
In the spirit of DIY Drones, here's a short clip of two HooperFly flying robots flying a tandem autonomous mission lift-off to landing. One is a hexacopter and the other a quadcopter, each outfitted with a Lisa/MX autopilot and PaparazziUAV software. It's an interesting feeling to have multiple aircraft in the air and to see them perform fairly sophisticated behaviors without any human inputs. Any anxiety related to flying an aircraft is quickly shifted to monitoring and verifying flight systems. Multiple fail-safes for reliably landing or terminating any of the aircraft missions is important and should be thoroughly tested before flying multiple aircraft scenarios. There are no less than 10 different mechanisms for dealing with unexpected flight behavior. That being said, the flights, so far, have been flawless. It's very gratifying to work with flying robots. Upward and onward.
Our Kickstarter campaign will launch in August 2015 and we would greatly appreciate your support. In this campaign we will be raising funds for two of our current products. The first product is the Kahone 3-Axis Gimbal for drones and the second is the Kahone Handheld. The renderings of these two products are posted below.
The Humanitarian UAV Network (UAViators) recently organized a 3-day Policy Forum on Humanitarian UAVs. The mission of UAViators is to promote the safe, coordinated and effective use of UAVs in a wide range of humanitarian settings. The Forum, the first of it’s kind, was generously sponsored and hosted by the Rockefeller Foundation at their conference center in Bellagio, Italy. The aerial panoramic photograph below was captured by UAV during the Forum.
UAViators brought together a cross-section of experts from the UN Office for the Coordination of Humanitarian Affairs (OCHA), UN Refugee Agency (UNHCR), UN Department for Peacekeeping Operations (DPKO), World Food Program (WFP), International Committee of the Red Cross (ICRC), American Red Cross, European Commission's Humanitarian Aid Organization (ECHO), Medair, Humanitarian OpenStreetMap, ICT for Peace Foundation (ICT4Peace), DJI, BuildPeace, Peace Research Institute, Oslo (PRIO), Trilateral Research, Harvard University, Texas A&M, University of Central Lancashire, École Polytechnique Fédérale de Lausanne (EPFL), Pepperdine University School of Law and other independent experts. The purpose of the Forum, which I had the distinct pleasure of running: to draft guidelines for the safe, coordinated and effective use of UAVs in humanitarian settings.
Five key sets of guidelines were drafted, each focusing on priority areas where policy has been notably absent: 1) Code of Conduct; 2) Data Ethics; 3) Community Engagement; 4) Principled Partnerships; and 5) Conflict Sensitivity. These five policy areas were identified as priorities during the full-day Humanitarian UAV Experts Meeting co-organized at the UN Secretariat in New York by UAViators and OCHA (see summary here). After 3 very long days of deliberation in Bellagio, we converged towards an initial draft set of guidelines for each of the key areas. There was certainly no guarantee that this convergence would happen, so I’m particularly pleased and very grateful to all participants for their hard work. Indeed, I’m reminded of Alexander Aleinikoff (Deputy High Commissioner in the Office of UNHCR) who defines innovation as “dynamic problem solving among friends.” The camaraderie throughout the long hours had a lot to do with the positive outcome. Conferences typically take a group photo of participants; we chose to take an aerial video instead:
Of course, this doesn’t mean we’re done. The most immediate next step is to harmonize each of the guideline documents so that they “speak” to each other. We’ll then solicit internal institutional feedback from the organizations that were represented in Bellagio. Once this feedback has been considered and integrated where appropriate, we will organize a soft public launch of the guidelines in August 2015. The purpose of this soft launch is to actively solicit feedback from the broader humanitarian community. We plan to hold Webinars in August and September to invite this additional feedback. The draft guidelines will be further reviewed in October at the 2015 Humanitarian UAV Experts Meeting, which is being hosted at MIT and co-organized by UAViators, OCHA and the World Humanitarian Summit (WHS).
We’ll then review all the feedback received since Bellagio to produce the “final” version of the guidelines, which will be presented to donors and humanitarian organizations for public endorsement. The guidelines will be officially launched at the World Humanitarian Summit in 2016. In the meantime, these documents will serve as best practices to inform both humanitarian UAV trainings and missions. In other words, they will already serve to guide the safe, coordinated and effective use of UAVs in humanitarian settings. We will also use these draft guidelines to hold ourselves accountable. To be sure, humanitarian innovation is not simply about the technology; humanitarian innovation is also about the processes that enable the innovative use of emerging technologies.
While the first text message (SMS) was sent in 1992, it took 20 years (!) until a set of guidelines were developed to inform the use of SMS in disaster response. I’m relieved that we won't have to wait until 2035 to produce UAV guidelines. Yes, the evidence base for the added value of UAVs in humanitarian missions is still thin, which is why it is all the more remarkable that forward-thinking guidelines are already being drafted. As several participants noted during the Forum, “The humanitarian community completely missed the boat on the mobile phone revolution. It is vital that we not make this same mistake again with newer, emerging technologies.” As such, the question for everyone at the Forum was not whether UAVs will have a significant impact, but what what guidelines are needed now to guide the impact that this new technology will inevitably have on future humanitarian efforts.
The evidence base is necessarily thin since UAVs are only now emerging as a potential humanitarian technology. There is still a lot of learning and documenting to be done. The Humanitarian UAV Network has already taken on this task and will continue to enable learning and catalyze information sharing by convening expert meetings and documenting lessons learned in collaboration with key partners. The Network will also seek to partner with select groups on strategic projects with the aim of expanding the evidence base. In sum, I think we’re on the right track, and staying on the right track will require a joint and sustained effort with a cross-section of partners and stakeholders. To be sure, UAViators cannot accomplish the above alone. It took 22 dedicated experts and 3 long days to produce the draft guidelines. So consider this post an open invitation to join these efforts as we press on to make the use of UAVs in humanitarian crises safer, more coordinated and more effective.
In the meantime, a big thanks once again to all the experts who joined us for the Forum, and equally big thanks to the team at the Rockefeller Foundation for graciously hosting us in Bellagio.
SmartAP Autopilot is getting its own Ground Control Station, it's called SmartAP GCS. This software package includes mission planning interface and built-in configuration tool. The general features are: Flexible and user-friendly interface One-click commands for high-level control Status information display Major flight information display Mission planning using the waypoints Customizable waypoints' settings Flight logging support Realtime plot of all parameters Integrated log analyzer Points of interest selection and control Terminal window
This video shows an ODROID U-3 single-board computer running a Python program that talks to a an AcroNaze32 flight controller (FC) over USB. The Python program uses MSPPG, our Multiwii Serial Protocol Parser Generator library, to serialize up/down/up/down MSP_SET_RAW_RC messages to the FC. By polling the incoming R/C receiver channels using an MSP_RC message, we were able to have the Python program switch the autopilot on and off without the need for an additional microcontroller. The ODROID is powered by the clean 5v ESC output on the FC.
The app is called Tynker and it works with the Parrot Rolling Spider drones:
This is a quick start guide to program your Parrot drone with the Tynker App. Parrot has a number of videos that you can watch to unbox and setup the drone. Review the user guide and setup your drone.
Compatibility
Drone – Parrot Rolling Spider minidrone
Tablet – Your tablet should support Bluetooth 4.0 in order to pair with the drone. Please refer to the list of compatible devices listed on Parrot’s web site.
Tynker App – v3.0.2 and higher
Download Tynker
The Tynker App is supported on iPads and Android-enabled tablets. Note that in addition to Tynker, you can also download Parrot’s Free Flight App to connect to the drone.
Learn to program drones
“Crash Course” trains you on the usage of drone-specific commands in Tynker. The same code blocks that you use to command the virtual drone in the the puzzles program the actual drone once you pair with the real drone.
Create your first drone program
Select the “Create” section and start a new blank Project Add an Actor to represent the drone. You do this by selecting “+” to add an Actor, choosing the “Connected Device” category and selecting the Drone as an Actor. Once added, you’ll see that it comes with some default code.
Pairing
Now we are ready to pair the tablet with the drone. Simply turn on the drone and wait for it to pair. The pairing should be automatic. Once paired, you will see a green indicator on the drone Actor in Tynker. The lights on the drone should also be green.
Running your first program
Place the drone on the ground in an area with sufficient clearance. Press the Orange Play button to run the default program. The drone should execute take off, fly forward a few feet, turn around, fly back and land.
Drone code blocks
All the connected device blocks appear in the new “Library” category of code blocks.
Program ideas
Flip [Beginner]
Start with simple programs where you automate the drone’s flight path by modifying the default code. Make it flip on demand. For example, in this program, the drone flies up when you start the program and hovers. Each time you touch the drone actor, the drone flips. When you stop the program, the drone falls to the ground.
Flappy Drone Game [Beginner]
Use the pre-built template under “Game Kits” to make this simple Flappy bird style game. You can even add physical obstacles like hula hoops and fly the drone through them!
Air Controller [Intermediate]
Use this pre-built template to make your own custom drone controller using all the commands you’ve learned. Try to integrate the tilt block that uses the tablet accelerometer.
Troubleshooting
Pairing
Make sure that the drone is fully charged.
If there are multiple drones in the vicinity, select your specific drone under “Properties” of the drone Actor.
You will be able to see the Bluetooth scanning and pairing status under Properties.
If you are still unsuccessful, restarting the drone and then restart the Tynker app.
Built-in Controller
Use the built-in remote to pilot your drone, from under Properties.
Safety Precautions
The parrot mini-drone is not recommended for children under 14.
Please make sure that there is an adult at all times.
The User guide has a detailed list of precautions while flying indoors and outdoors.
Help and Support
If you need to repair your drone or replace parts, Parrot has helpful tutorials and videos on their web site.
Every few years, someone creates another smartphone-based autopilot (I did my first back in 2007!). And because smartphones get better each year, so do the smartphone autopilots. They haven't yet been as good as dedicated autopilots (which increasingly use the same smartphone chips, but used with better sensors), but it's a very useful experiment regardless. Here's the latest one, from the University of Nottingham.
Imagine you’re a farmer trying to grow a crop under drought conditions. Up-to-the-minute data on soil moisture can help you to decide where and when to irrigate, which directly affects your crop yield and your bottom line. More sensors would mean more data and a better spatial picture of conditions, but the cost of wired soil sensors would be crippling. Wireless sensors that tap into GSM or some sort of mesh network would be better, but each sensor would still need power, and maintenance costs would quickly mount. But what if you could deploy a vast number of cheap RFID-linked sensors in your fields? And what if an autonomous vehicle could be tasked with the job of polling the sensors and reporting the data? That’s one scenario imagined in a recent scholarly paper about a mobile Internet of Things (PDF link).
In the paper, authors [Jennifer Wang], [Erik Schluntz], [Brian Otis], and [Travis Deyle] put a commercially available quadcopter and RC car to the hack. Both platforms were fitted with telemetry radios, GPS, and an off-the-shelf RFID tag reader and antenna. For their sensor array, they selected passive UHF RFID tags coupled to a number of different sensors, including a resistance sensor used to measure soil moisture. A ground-control system was developed that allowed both the quad and the car to maneuver to waypoints under GPS guidance to poll sensors and report back.
Beyond agriculture, the possibilities for an IoT based on cheap sensors and autonomous vehicles to poll them are limitless. The authors rightly point out the challenges of building out a commercial system based on these principles, but by starting with COTS components and striving to keep installed costs to a minimum, we think they’ve done a great proof of concept here.
The Wall Street Journal reports on Flirtey's FAA-approved drone delivery trial (Pixhawk-powered hexacopter):
A pop-up health clinic in rural Virginia received deliveries of medicine from a drone Friday, the first government-approved drone delivery in the U.S.
But the orchestrated event also highlighted the hurdles that remain before such deliveries become everyday occurrences in U.S. skies, as envisioned by Amazon.com Inc.and Google Inc.
A manned aircraft carried the packages most of the way, and the flight plan originally called for the drone to make six round trips to carry a total of 10 pounds. But after two successful deliveries, officials decided to send the rest of the payload in one flight.
“It was absolutely a Kitty Hawk moment,” Matthew Sweeny, head of the drone-delivery startup Flirtey Inc., which carried out Friday’s deliveries, said in referring to where the Wright Brothers achieved the first successful airplane flight in North Carolina.
The drone carried medications prescribed by doctors at the annual Remote Area Clinic, a facility in Wise County, Va., that serves 3,000 patients one weekend a year.
Typically, the clinic is limited in which medications it can prescribe, since they are stocked ahead of its opening. The clinic’s supplying pharmacy is in Oakwood, Va., about 35 miles away as the crow flies, or roughly 90 minutes by car over winding roads.
Teresa Gardner, director of the pop-up clinic, said the drone was helping to get medicine to patients who often have to wait for days for their prescriptions, if they receive them at all, because of the long drive. “There are at least 30-something patients that will directly benefit from these deliveries,” she said.
A larger aircraft first ferried the medication on a 20-minute flight from Oakwood to Lonesome Pines Airport in Wise County. That aircraft, the Cirrus SR-22, is an experimental craft owned by the National Aeronautics and Space Administration and designed to function like a drone in tests. On Friday, a pilot helped the SR-22 take off and land, but it was largely piloted from the ground.
In Wise County, Flirtey’s drone took the medicine the final mile from the airport to the clinic, about a three-minute trip on the drone, not counting the time it took to load and unload the device.
Most commercial drones can’t yet fly the entire 35-mile trip. Mr. Sweeny said his company’s drones can carry 5.5 pounds as far as 20 miles before their batteries die.
Delivery drones also generally lack Federal Aviation Administration permission. The FAA gave Flirtey, NASA and Virginia Tech special approval for Friday’s demonstration, but it effectively bans drone deliveries. The FAA’s proposed drone rules, expected to be made final next year, prohibit flights over people, in cities and beyond sight of the drone’s operator. The rules would also prohibit drones from carrying objects.
Several companies, including Google and Deutsche Post DHL AG, have tested drone deliveries outside the U.S.
But the first authorized U.S. delivery could help change perceptions of drones as either playthings or weapons systems.
“What we’re trying to do is not only develop the technology, but [develop] the public’s trust in the technology,” said Frank Jones, deputy director of NASA Langley’s Research Services Directorate.
Delivering medical supplies in a rural area is the scenario many industry observers say is most likely for drone manufacturers to pursue in the near term because the need is high and the risk is low, said Colin Snow, an independent analyst who tracks the drone industry.
But Mr. Snow added that complicated logistics for Friday’s demonstration illustrate how the technology remains years away. “That doesn’t seem efficient to me. Couldn’t you just drive it?”
Mr. Sweeny rejected criticisms that the deliveries don’t mark a watershed moment. “Isn’t that like saying the moon landing wasn’t significant because we didn’t have the technology to get to Mars?” he said.
We are currently working on a DGPS solution for UAVs to improve precision up to centimeter levels. Our architecture is the following, we use two Ublox GPS with raw data activated, one for the base station, the other one for the rover. The rover GPS is connected to the Intel Edison breakout board that also receives the base station GPS signal through a telemetry (for the moment, we are also focusing on a 2G/3G/4G solution that would remove all range problems). Then, the Intel Edison runs the RTKLIB code that outputs a DGPS solution to the DroPix flight controller with Ardupilot 3.2.1 firmware.
We have been running tests with GPS mounted on cars and dataloggers. The logs were post-processed afterwards with the library in order to obtain DGPS solutions.
Results were quite good in areas with wide sky views, worse in places with a high number of obstacles (trees or houses), where the solution became float or even single and the precision was completely lost. The high precision, when available, can tell exactly on what lane the car is and can even report the movements inside the road.
The static solution has a precision of less than 2 centimeters.
Mounted on a drone, the GPS has no line-of-sight problem and we get the fix solution most of the time.
This process also works in real time (no datalogger/post-processing), except that the flight controller does not get the signal. The Edison outputs NMEA sentences ($GPGSA $GLGSA $GPGSV $GLGSV $GPRMC $GPGGA) that are routed to the FC via serial communication (the TX of the Edison is connected to the RX GPS port of the Dropix, both other cables remain unconnected). We have been trying changing baudrates, frequencies and messages but in no way the FC would get the message. Does someone know how to communicate with the FC without having to convert the NMEA messages into UBlox binary protocol?
Recently several cases were designed for Navio+ and Raspberry Pi 2 by community members and we would like to share them in one blog post. Now you have what to choose from. We would also like to thank designers for their great work. So pick one you like and make sure to share the results with us!
Having a flat bottom or even special brackets for vibration dampeners they simplify mounting and will as well protect barometer on your Navio+ from sunlight and air streams
A very nice low profile case with ventilation slots and camera ribbon cut out. Designer: Mauro Cancino Technology: 3D Print Link: click!
Case with antenna cable channel and mounting brackets for vibration dampening. It even includes a logo! Designer: Pedro Alves Technology: 3D Printing Link:click!
If you do not have a 3D printer, make sure to check out this case made from an Adafruit Raspberry Pi case. Designer: Al_B Technology: Modification Link:click!
Ordering 3D printing is easy thanks to services like Shapeways.
You can also design your own case using Navio+ STL model. Feel free to join the discussion about the designs.
From Gizmag, the latest on Flirtey, whose Pixhawk-powered drones are the first to be approved for drone delivery trials in the US:
One weekend each July, 1,500 people from rural area of Wise County, Virginia descend on the local fairgrounds for a once yearly medical clinic. Here they seek attention for conditions that go untreated for the rest of the year due to lack of access to proper healthcare. In years gone by, medical supplies would be brought into the town by truck, but this year things will be working a little differently. Startup Flirtey has teamed up with NASA to conduct a Federal Aviation Administration (FAA) approved exercise to deliver some of these items by drone. This is a good news for a startup trying to spread its wings, but even better news for rural folk who instead of waiting days for medication will have their prescriptions filled in just half an hour. And as Flirtey CEO Matt Sweeney tells Gizmag, it could be the "Kitty Hawk" moment the drone delivery industry has been longing for.
Much of the buzz surrounding UAV deliveries over the past two years has come from the direction of Amazon's Prime Air drones, which are still undergoing testing.Google and numerous startups around the world are also looking to get in on the action, though the industry has been made to play the waiting game while the FAA rejigs its regulations for unmanned flight.
But as the agency irons out the details of this important reform, Flirtey has been getting busy. It first emerged with a proposal to deliver schoolbooks by drone in Australia in 2013. Then last year it started to think big, expanding to an office at the University of Nevada Reno to develop its technology at one of six FAA-approved drone testing sites in the US.
These baby steps have grown into large strides, with Flirtey now partnering with NASA to carry out the first real-world demonstration of drone delivery as approved by the FAA. It is still technically a research rather than commercial exercise, but it is set to impact the wellbeing of real people.
"We started speaking to this community about what could make things better, they said that if there was a way they could receive the medication quicker that would help," Sweeney tells Gizmag. "So we brought drone delivery to Virginia and will cut the delivery time from a day or more to half an hour."
As attendees of the Wise County medical clinic are prescribed medications, the scripts will be sent to a large out-of-city pharmacy. The pharmacy fills the prescriptions and loads them onto a NASA fixed-wing aircraft which will be guided remotely to the Lonesome Pine airport. Here, Flirtey drones made from carbon fiber, aluminum and 3D printed parts will complete the last leg.
"We are aiming to deliver 24 packages of medicine for 24 people, four on each flight across six drone flights," says Sweeney.
Sweeney hopes this proof of concept whereby the benefits of drone delivery are realized, albeit on a small scale, will act as a catalyst for the delivery of everyday items. Revamped FAA rules are now not expected until at least June 2016 and are unlikely to permit flight over populated areas, a necessity for fully fledged drone delivery. But Sweeney is upbeat about the direction the industry and his company is headed nonetheless.
"The way drone delivery is going to roll out is it will be incremental," he says. "It will start with line of sight, in rural areas. Then it will advance to populated areas. But we don't have to wait, we can start rolling out now, it's not an all or nothing solution."
And on the possibility of being muscled out by the industry's bigger players, he was equally optimistic.
"If you look back at the history of tech, it's not usually the incumbents who win," he says. "By being a small and nimble startup we are uniquely placed to get out ahead of these bigger companies. Google is still searching for a solution and I don't think Walmart or eBay is going to use Amazon (for delivery). So there's a big opportunity for Flirtey to be the big independent drone delivery service in the US."
Due to its 600 gram weight, a battery life exceeding five hours coupled with an independent operating system, the sensor can be easily integrated in a wide range of UAVs. At a later stage, a ready-to-go package including UAV will be available. From production, processing through transport and distribution, an impressive number of applications can be realized with the utilization of this sensor. Landfill emission monitoring as well as surveys in difficult to access areas that previously required scaffolding are further examples of usage.
