From the ROS blog, a post by the Erle Robotics team announcing a simple programming toolkit for ROS and Dronecode-based robots.
For the last months we provided several training sessions on how to use our brains and robots based in ROS. While doing so we noticed that many people struggled at understanding ROS so we started exploring a way to make this process easier.
We prototyped different concepts and decided that ideally wanted to reach high schools students. At this point we removed the assumption of "coding skills" from the equation which made us look into systems like Scratch for robot programming. After taking inspiration from previous work we are happy to present robot_blocky: a multiplatform, web-based tool for programming robots and drones that use ROS.
Here's a short clip that introduces robot_blocky: Previously called ROSimple
I have been working to implement a plugin for STK (Systems Tool Kit) for importing a flight log, recreating the flight, altering some sensor models to depict the camera and camera mode (i.e. field of view). I can pull the flight data in, overlay the captured video from the flight, compare with a "simulated" view of modeled sensor in the software, and do some pretty cool analysis with other tools in the software (reports/graphs, propagate GPS satellites and analyze and/or predict DOP values, calculate distances to other objects/ areas/ volumes.... the list goes on.
I also have been working to put in a RealTime capability so i can link up to my 3DR radio and monitor the flight of my IRIS+. You can see some demonstration of what i have working so far here:
Let me know what you think! I am still trying to wrap my head around the whole MAVLINK world, but i have made some progress! Thanks to a few folks on here who have given some guidance as well.
I've had the pleasure of beta testing a new Android based Mapping/VR/Modelling GCS for 3DR Solo. In addition to Solo support it also supports both Pixhawk based fixed wing and multicopters. DJI Phanton3/Inspire 1 compatibility is likely to follow.
It is refreshing to see a GCS for Pixhawk that is as easy to use as my Sensefly eBee, requiring zero piloting skills, and 100% flown using a tablet PC. I recorded the above video yesterday during another test mission. The only time I touched the RC controller was to turn it on and off, otherwise, the app armed the motors, flew the solo, landed it, disarmed the motors, and then Geo-tagged all the photos, ready for upload for map processing.
Posted by Greg Dronsky on December 12, 2015 at 8:15am
How Elon Musk and Y Combinator Plan to Stop Computers From Taking Over
They’re funding a new organization, OpenAI, to pursue the most advanced forms of artificial intelligence — and give the results to the public
Asif the field of AI wasn’t competitive enough — with giants like Google, Apple, Facebook, Microsoft and even car companies like Toyota scrambling to hire researchers — there’s now a new entry, with a twist. It’s a non-profit venture called OpenAI, announced today, that vows to make its results public and its patents royalty-free, all to ensure that the scary prospect of computers surpassing human intelligence may not be the dystopia that some people fear. Funding comes from a group of tech luminaries including Elon Musk, Reid Hoffman, Peter Thiel, Jessica Livingston and Amazon Web Services. They have collectively pledged more than a billion dollars to be paid over a long time period. The co-chairs are Musk and Sam Altman, the CEO of Y Combinator, whose research group is also a funder. (As is Altman himself.)
Musk, a well-known critic of AI, isn’t a surprise. But Y Combinator? Yep. That’s the tech accelerator that started 10 years ago as a summer project that funded six startup companies by paying founders “ramen wages” and giving them gourmet advice so they could quickly ramp up their businesses. Since then, YC has helped launch almost 1,000 companies, including Dropbox, Airbnb, and Stripe, and has recently started a research division. For the past two years, it’s been led by Altman, whose company Loopt was in the initial class of 2005, and sold in 2012 for $43.4 million. Though YC and Altman are funders, and Altman is co-chair, OpenAI is a separate, independent venture.
Essentially, OpenAI is a research lab meant to counteract large corporations who may gain too much power by owning super-intelligence systems devoted to profits, as well as governments which may use AI to gain power and even oppress their citizenry. It may sound quixotic, but the team has already scored some marquee hires, including former Stripe CTO Greg Brockman (who will be OpenAI’s CTO) and world-class researcher Ilya Sutskever, who was formerly at Google and was one of the famed group of young scientists studying under neural net pioneer Geoff Hinton in Toronto. He’ll be OpenAI’s research director. The rest of the lineup includes top young talent whose resumes include major academic groups, Facebook AI and DeepMind, the AI company Google snapped up in 2014. There is also a stellar board of advisors including Alan Kay, a pioneering computer scientist.
OpenAI’s leaders spoke to me about the project and its aspirations. The interviews were conducted in two parts, first with Altman and then another session with Altman, Musk, and Brockman. I combined the interviews and edited for space and clarity.
How did this come about?
Sam Altman: We launched YC Research about a month and a half ago, but I had been thinking about AI for a long time and so had Elon. If you think about the things that are most important to the future of the world, I think good AI is probably one of the highest things on that list. So we are creating OpenAI. The organization is trying to develop a human positive AI. And because it’s a non-profit, it will be freely owned by the world.
Elon Musk: As you know, I’ve had some concerns about AI for some time. And I’ve had many conversations with Sam and with Reid [Hoffman], Peter Thiel, and others. And we were just thinking, “Is there some way to insure, or increase, the probability that AI would develop in a beneficial way?” And as a result of a number of conversations, we came to the conclusion that having a 501c3, a non-profit, with no obligation to maximize profitability, would probably be a good thing to do. And also we’re going to be very focused on safety.
And then philosophically there’s an important element here: we want AI to be widespread. There’s two schools of thought — do you want many AIs, or a small number of AIs? We think probably many is good. And to the degree that you can tie it to an extension of individual human will, that is also good.
From Scientific Aerospace, makers of the Cyberquad, comes a new product that makes great use of the Solo platform: Same Solo controller and internals, but repackaged in a powerful Enterprise mapping platform.
NOTE : Experimental. To avoid formulas visualization issues we've setup a free Newsletter. Once subscribed you will receive a pdf with the article. http://www.basicairdata.eu/newsletter.html
In this short article we will make an effort to calculate the flow rate of a volume of air via \(n\) multiple velocity measurements at a selected pipe section. Velocity profiles are useful when evaluating small DIY wind tunnels and nozzle designs. Although this article doesn't reflect any particular technology, the reader can imagine that velocity measurements themselves are carried out with a Pitot tube or with a Pitot rake placed at the section in question. There are different industrial standards that cover the topic, such as the ISO 3966: Measurement of fluid flow in closed conduits - Velocity area method using Pitot static tubes. In the following test we will not follow any particular standard. Still, those standards are interesting readings.
We are interested in calculating the volumetric flow rate, \(Q\). The volumetric flow rate is the volume \(\Delta V\) that flows across a predefined surface in an arbitrary interval of time \(\Delta t\), \(Q=\frac{\Delta V}{\Delta t}\).
Figure 1 - Sectioned pipe and flowing fluid
Refer to Figure 1; A section perpendicular to the pipe axis defines a circular surface of area\(s\). On the assumption that the axial velocity at every point of the section is constant and equal to \(V_c\), then \(Q=V_c\cdot s\). An animation of the system at hand can be seen in the following video
Video 1 - Volumetric Flow rate
The fluid velocity is constant over the section and time. A flow rate of 4.4e-6 \(m^3/s\) is equal to the red cylinder volume, 13.2e-6 \(m^3\), divided by the transit time through the section plane, 3\(s\).
However, in the real world the velocity is not constant across the section. The interaction of the fluid with the pipe surface generates a non-negligible velocity gradient. In general, it stands that \(Q=\int v(x,y,)dt\). Bibliography comes handy and we will use a power-law velocity profile. With this model, we will build a reference pipe numerical model, which represents the pipe and the flow rate which we will measure. The real-world pipe is replaced by a numeric simulation. The commonly used model does not separate the viscous sublayer nor the transition layer; in fact it is discontinuous at the surface of the pipe and on the symmetry axis. Since we are not treating a particular real-word case we're not concerned about the uncertainty introduced by the power-law model. Details about the viscous sublayer and the transition layer can be found in this link.
We end up using a fully developed turbulent axial flow model at high Reynolds number. The viscous layer is expected to be thin in typical cases (like a hair) and it is not calculated in this example. You can find a Scilab script in this file that will calculate the power-law velocity profile for you. The result is visible in the next figure.
The resulting velocity profile is dependent solely on the distance from the axis. You can see that the velocity gradient, as expected, is high near the pipe wall and low along the center line.
Now it is time to measure the flow rate. Refer to Figure 3. We assume having access to velocity measurements at \(n\) stations. Each station is at a different distance \(r(n)\) from the pipe center line. For the sake of simplicity, we divide the radius in \(n\) equal segments. For each segment we measure the velocity \(v(n)\) at its midpoint.
Figure 3 - Velocity measurements position into the measurement section
We make the assumption that the velocity remains constant along each segment of the radius and, by extension due to axial symmetry, over the whole corresponding annular ring. The total volume that passes through the ring surface is the product of velocity with the annulus area. Iterating the calculation for all the segments we calculate the volumetric flow rate as \[Q=\sum_{i=1}^n v(n)\pi(r_{ext}^2(n)+r_{int}^2(n))\], where
\(i\) is the annular ring index
\(v(n)\) is the velocity of \(i\) ring
\(r_{ext}\) is the outer ring radius of \(n\) ring
\(r_{int}\) is the inner ring radius of \(n\) ring
Figure 4 - Velocity profile reconstructed by 10 measurements
Figure 4 visualizes the velocity profile as reconstructed by our measurements. It is evident from the profile steps that we have a coarse approximation. There is a simple way to get better flow rate measurements: we can use the model to calculate the velocity profile within each annulus. In such a way, using our simulation data, we will get exactly the flow rate produced by our reference model. Driven by this result, we can even try to use only the data from one single measurement, for example at the center line. Doing so we will bring the very same result predicted by our reference model. Unfortunately the accuracy is constrained to the ability of the model to capture the real world with all accuracy. For that reason, in actual applications, in general, the accuracy should be expected to be higher when using multiple simultaneous measurements rather than model interpolations. But let's leave this problem to the professionals, for now.
In this article we have explored the basics of volumetric flow rate measurement with the velocity-area method. This topic is quite relevant to basic air data processing because it shows the impact of the flow pattern on simple calibration instruments like small size / DIY size wind tunnels.
Talk about a game changer. A fully integrated FLIR camera with gimbal. Opens up a wide variety of uses and eliminates the need for a hodge podge of different components to install a FLIR/Gimbal on one of the most frequently used UAS systems for commercial work.
We are glad to announce the release of UgCS 2.7. This version features many improvements and changes over the previous version.
Mapping with UgCS is now easier than ever, the Area scan now a flag called “additional waypoints” which helps to reduce the number of generated waypoints. This is very useful for DJI autopilots in which the number of waypoints per mission is limited. Futhermore, we have made the geotagging tool easier to use since now it has added progress bars and a photo preview. Also the new DJI X5 camera has been added to payloads in UgCS.
UgCS 2.7 now supports the newest ArduCopter firmware – 3.3.1, available for APM and Pixhawk autopilots.
We have also improved the way fixed wing aircraft work with UgCS by adding new landing parameters and changing the default waypoint acceptance radius to 10 meters for fixed wing aircraft.
UgCS 2.7 can be downloaded from our site here: www.ugcs.com
Last year at this time, I reflected back on the news and trends of the commercial drone markets of 2014 and wrote about the mixed state of affairs in the U.S. Back then, drones got considerable media hype and you would have thought that drones could do anything from guide your car in the wilderness, to save the planet from starvation. In reality, we were just beginning to see the very first FAA grants of regulatory exemptions for commercial activity—which was nothing more than filming on closed sets.
Contrast that with this year, one in which we’ve seen more than 2,500 Section 333 grants for all kinds of commercial activity and the press’s narrative that ‘drones are cool’ turned to ‘drones are a headache’. Even so, there’s more going on than just public consternation.
In this post, I’ll review what I think were the six most significant commercial market trends for drones in 2015 set in the context of movies and myths. Enjoy.
Casino Royale: Venture Capital
In the 2006 movie Casino Royale, James Bond attempts to bankrupt a terrorist financier by beating him in a high-stakes poker game. The plot twists and the tournament culminates in a $115-million winning hand for Bond—who discovers later the woman he fell in love with has stolen the winnings.
Unmanned Aerospace Systems (UAS) – Key Concepts for New Users Free Course about Drone or UAS safety and Operation In January, Embry-Riddle Worldwide will offer its fifth MOOC (Massive Open Online Course) to anyone with an Internet connection and a desire to learn about aviation. And it is free! The course, “Unmanned Aerospace Systems (UAS) - Key Concepts for New Users,” runs from Jan. 11 to 24. Register now. The increasing popularity of UAS or recreational drones has created new safety challenges within the National Airspace System (NAS). Led by Embry-Riddle Worldwide faculty, the MOOC will address airspace issues - along with UAS basics, UAS operating environment and the do’s and don’ts of UAS / recreational drone operations. The primary goal is to educate new UAS users about effective operating procedures that foster safe UAS operations. This MOOC, Unmanned Aerospace Systems (UAS) – Key Concepts for New Users, is expected to be followed by more free online courses from Embry-Riddle professors specializing in other aviation and aerospace fields. So if learning about unmanned aerospace systems does not interest you, there is bound to be a MOOC that piques your aerospace interest in coming months.
Posted by Simon D. Levy on December 8, 2015 at 9:52am
In my last post I showed a Flip32 flight controller talking to a PX4Flow unit using the I^2C protocol. Once that was working, I wanted to mount the PX4Flow to a vehicle and make a more permanent cable connection.
For the mount, I used Tinkercad to design a simple rectangular plate with four recessed screw holes, plus a small rectangular hole to pass the I^2C cable through. Four M3 nylon machine screws and standoffs, both 5mm size, fit snugly into the holes, after which I mounted the plate permanently on the rear bottom plate of my 250mm H-quad using E6000 adhesive.
To make the cable, I soldered one end of the four-position cable from 3R to a four-pin jumper cable from Sparkfun. To keep the color-coding sensible, I covered the red jumper wire with black heat-shrink tubing, making it the ground (leftmost) of the four I^2C pins on the Flip32. Then the orange wire was +5V, the yellow SCL, and the green SDA:
Once the PX4Flow unit was mounted and wired, I found that the vehicle's legs were too short. So I designed and printed some extra-long legs, allowing the unit plenty of ground clearance:
My ultimate goal is to modify the Flip32's Baseflight firmware so it uses the sonar and optical-flow readings from the PX4Flow to perform altitude- and position-hold. Before doing that, I plan to collect in-flight data from the PX4Flow, by attaching a Bluesmirf modem to the Flip32's UART pins and sending a new MSP message from the Flip32 to a Python program on my laptop.
Posted by Ramon Roche on December 7, 2015 at 2:17pm
Big news: DroneKit-Python has just hit its next major release! 2.0 is now available via pip and Github. With 2.0, we took the time to do some major architecture changes targeting performance, extensibility, and ease of use. We have started internally testing and porting these enhancements to major projects that depend on DroneKit-Python.
Please report any bugs through Github or the DroneKit Forums. Also, please give us a shout if you are developing any projects using DroneKit-Python! We would love to hear about all the awesome projects you are working on.
Many thanks to all the people involved in creating and testing 2.0 (Sorry if we omit any!) @tcr3dr, @hamishwillee, @geeksville, @mrpollo, @will, @eliao, @djnugent, @squilter, @stephendade, @franknitty69, @mikerob, @atomictom, @jmachuca77
Changelog (edited):
New Features
Renamed the actual package name to “dronekit” (previously droneapi)
Dronekit now runs standalone (removed MAVProxy dependency)
Multiple vehicle support
MAVLink message listeners
Major Feature Updates
local_connect refactored as a single connect() method (can connect to multiple vehicles!)
Removed .set_mavrx_callback in favor of the new on_message callbacks
Moved RC channels to .channels object
Split location information into local_frame, global_frame and global_relative_frame
Removed need for .flush() for most commands (now renamed commands.upload())
Renamed commands.goto and commands.takeoff to simple_goto and simple_takeoff
A migration guide is available that covers how to fix your code if you are depending on certain features that we removed. The migration guide is also available on the DroneKit docs site, just search for Migrating to DKPY 2.0
DroneKit-Python 1.5 EOL
Finally, with the 2.0 release we would like to address 1.5 EOL. We will no longer be shipping new features on the 1.5 branch, and are expecting to end support and maintenance updates on Q1 2016. Starting Q2 2016 the DroneKit Core Team can no longer guarantee any support for 1.5.
Posted by Jimmy Oliver on December 7, 2015 at 9:04am
In the aftermath of the Zano disaster a new micro drone has popped up boasting most of the features of the failed Zano.
There is a pre-sale tomorrow for $179 with final prices at around $200. The web site is light on information. There is no app that I can see. There is a highly suspect video that has been posted that looks recycled from some previous footage. There was a big push and Facebook for this drone.
Although this is not a crowdfunded project, the pre-sale aspect could have the same results.
At my previous post, I have presented the willing of Erle Robotics of programming APM based vehicles using blocks.
Notice that the official name of this tool has changed to Robot Blockly, in order to meet OSRF naming criterium.
Today I want to show a small example of how this new tool can move an APM based Rover. In this example, I have used a block that controls the direction and throttle of the rover. This block has overwrite the output channel 1 and 3, using a MAVROS service.
This new functionality comes integrated in our latest product, Erle-Brain 2. You could find it in the image called "blanco", which is based on Debian Jessie.
Right from the beginning UgCS was designed not only as an out of the box ground station software for end users, but also as a platform for custom and integration projects.
By now a number of different custom projects have been implemented using UgCS as the basis for them - integration with perimeter security systems, object surveillance systems, ATC, C&C center integration, UI customizations and others. Moreover, one of our partners has even created custom ground control software for their drone using our SDK.
Below is an under-the-hood diagram of UgCS and the architecture, which makes it all possible:
UgCS has 3 main layers:
- UCS – universal control server
- HCI – human control interface – interface for the user of UgCS
- VSMs – vehicle specific modules
In addition to the aforementioned layers UgCS also has the following components – video server, geoserver, ADS-B receiver module and vehicle emulator.
All components are implemented as separate processes (.exe in case of Windows, etc.) and communicate to each other using TCP protocol. This allows the components to be deployed on separate machines in distributed configuration.
HCI - Human Control Interface
UgCS has a standard client application, which is already well known to the industry. If you have not seen UgCS client before you can see it here -
UgCS can have different client applications with different user interfaces. For example, for one of our integration projects we implemented very simple UI for security officers.
Now we are developing a special version of UgCS UI for tethered drones. It will be a separate application that connects to UCS server and will only have the basic controls for the drone and the camera (drone up/down, camera direction, start/stop recording).
Interesting is the fact that UgCS can serve multiple operators with different clients simultaneously. For example – an operator of a tethered drone can use the simplified UI. If he sees something interesting using the tethered drone camera, he can set a landmark on the map in UgCS. This landmark will be available for the second operator of a “traditional” drone in a standard UgCS client which will be connected to the same server. The second operator can then send the drone for close surveillance of the landmark. Tethered drone operator will see the second drone on the map along with the video stream from the second drone and will be able to provide directions for the operator of the second drone.
Standard UgCS client is written in C# on top of Unity 3D platform. We are working on .Net UCS Interaction SDK and will write a separate article about it soon.
UCS - Universal Control Server
This is the core of UgCS. UCS is responsible for all communications inside of UgCS and core functions such as data storage, route calculation, telemetry processing and event generation, access management etc.
UCS (in Pro version) can serve multiple clients, allowing for multi-operator deployment. UCS also allows user access control based on user roles.
UCS is written in Java.
Furthermore UCS plays the most significant role for integration projects. We have published our server API with samples here - https://github.com/UgCS/ucs-java-client. It is possible to use this API in almost any integration because inside of UgCS the same API is used. We are happy that one of our partners has completed an integration project with video surveillance system without the need for any significant help from our engineers.
VSM - Vehicle Specific Module
Simply put, VSM is the driver for a particular autopilot and their communication channel(s).
For example Ardupilot VSM can serve APM/Pixhawk compatible autopilots and communicate to them using 3DR compatible radios, WiFi or XBee modems.
Out of the box we provide VSMs for the most popular autopilots. But in case one needs to use UgCS with custom autopilot it’s possible to use our VSM SDK and samples (https://github.com/UgCS) and create a VSM for any autopilot. For instance one of our partners created their VSM for their highly customized Ardupilot firmware.
VSMs are written in C++ language.
It is an important goal of ours to make UgCS a convenient platform for custom ground control software developments. We will be glad to address your questions about the architecture of UgCS, existing and planned SDKs.
This is all for the first post about UgCS internals. In future posts we will describe in details different components and functions. We hope that this was an interesting read for you.
You can find more information about UgCS on our site: www.ugcs.com
Interesting post from Patrick Meier at iRevolutions:
Recent scientific research has shown that aerial imagery captured during a single 20-minute UAV flight can take more than half-a-day to analyze. We flew several dozen flights during the World Bank’s humanitarian UAV mission in response to Cyclone Pam earlier this year. The imagery we captured would’ve taken a single expert analyst a minimum 20 full-time workdays to make sense of. In other words, aerial imagery is already a Big Data problem. So my team and I are using human computing (crowdsourcing), machine computing (artificial intelligence) and computer vision to make sense of this new Big Data source.
For example, we recently teamed up with the University of Southampton and EPFL to analyze aerial imagery of the devastation caused by Cyclone Pam in Vanuatu. The purpose of this research is to generate timely answers. Aid groups want more than high-resolution aerial images of disaster-affected areas, they want answers; answers like the number and location of damaged buildings, the number and location of displaced peoples, and which roads are still useable for the delivery of aid, for example. Simply handing over the imagery is not good enough. As demonstrated in my new book, Digital Humanitarians, both aid and development organizations are already overwhelmed by the vast volume and velocity of Big Data generated during and post-disasters. Adding yet another source, Big Aerial Data, may be pointless since these organizations may simply not have the time or capacity to make sense of this new data let alone integrate the results with their other datasets.
We therefore analyzed the crowdsourced results from the deployment of ourMicroMappers platform following Cyclone Pam to determine whether those results could be used to train algorithms to automatically detect disaster damage in future disasters in Vanuatu. During this MicroMappers deployment, digital volunteers analyzed over 3,000 high-resolution oblique aerial images, tracing houses that were fully destroyed, partially damaged and largely intact. My colleague Ferda Ofli and I teamed up with Nicolas Rey (a graduate student from EPFL who interned with us over the summer) to explore whether these traces could be used to train our algorithms. The results below were written with Ferda and Nicolas. Our research is not just an academic exercise. Vanuatu is the most disaster-prone country in the world. What’s more, this year’s El Niño is expected to be one of the strongest in half-a-century.
According to the crowdsourced results, 1,145 of the high-resolution images did not contain any buildings. Above is a simple histogram depicting the number of buildings per image. The aerial images of Vanuatu are very heterogeneous, and vary not only in diversity of features they exhibit but also in the angle of view and the altitude at which the pictures were taken. While the vast majority of the images are oblique, some are almost nadir images, and some were taken very close to the ground or even before take off.
The heterogeneity of our dataset of images makes the automated analysis of this imagery a lot more difficult. Furthermore, buildings that are under construction, of which there are many in our dataset, represent a major difficulty because they look very similar to damaged buildings. Our first task thus focused on training our algorithms to determine whether or not any given aerial image shows some kind of building. This is an important task given that more than ~30% of the images in our dataset do not contain buildings. As such, if we can develop an accurate algorithm to automatically filter out these irrelevant images (like the “noise” below), this will allows us focus the crowdsourced analysis of relevant images only.
While our results are purely preliminary, we are still pleased with our findings thus far. We’ve been able to train our algorithms to determine whether or not an aerial image includes a building with just over 90% accuracy at thetile level. More specifically, our algorithms were able to recognize and filter out 60% of the images that do not contain any buildings (recall rate), and only 10% of the images that contain buildings were mistakingly discarded (precision rate of 90%). The example below is an example. There are still quite a number of major challenges, however, so we want to be sure not to over-promise anything at this stage. In terms of next steps, we would like to explore whether our computer vision algorithms can distinguish between destroyed an intact buildings.
The UAVs we were flying in Vanuatu required that we landed them in order to get access to the collected imagery. Increasingly, newer UAVs offer the option of broadcasting the aerial images and videos back to base in real time. DJI’s new Phantom 3 UAV (pictured below), for example, allows you to broadcast your live aerial video feed directly to YouTube (assuming you have connectivity). There’s absolutely no doubt that this is where the UAV industry is headed; towards real-time data collection and analysis. In terms of humanitarian applications, and search and rescue, having the data-analysis carried out in real-time is preferable.
This explains why my team and I recently teamed up with Elliot Salisbury & Sarvapali Ramchurn from the University of Southampton to crowdsource the analysis of live aerial video footage of disaster zones and to combine this crowdsourcing with (hopefully) near real-time machine learning and automated feature detection. In other words, as digital volunteers are busy tagging disaster damage in video footage, we want our algorithms to learn from these volunteers in real-time. That is, we’d like the algorithms to learn what disaster damage looks like so they can automatically identify any remaining disaster damage in a given aerial video.
So we recently carried out a MicroMappers test-deployment using aerial videos from the humanitarian UAV mission to Vanuatu. Close to 100 digital volunteers participated in this deployment. Their task? To click on any parts of the videos that show disaster damage. And whenever 80% or more of these volunteers clicked on the same areas, we would automatically highlight these areas to provide near-real time feedback to the UAV pilot and humanitarian teams.
At one point during the simulations, we had some 30 digital volunteers clicking on areal videos at the same time, resulting in an average of 12 clicks per second for more than 5 minutes. In fact, we collectively clicked on the videos a total of 49,706 times! This provided more than enough real-time data for MicroMappers to act as a human-intelligence sensor for disaster damage assessments. In terms of accuracy, we had about 87% accuracy with the collective clicks. Here’s how the simulations looked like to the UAV pilots as we were all clicking away:
Thanks to all this clicking, we can export only the most important and relevant parts of the video footage while the UAV is still flying. These snippets, such as this one and this one, can then be pushed to MicroMappers for additional verification. These animations are small and quick, and reduce a long aerial video down to just the most important footage. We’re now analyzing the areas that were tagged in order to determine whether we can use this data to train our algorithms accordingly. Again, this is far more than just an academic curiosity. If we can develop robust algorithms during the next few months, we’ll be ready to use them effectively during the next Typhoon season in the Pacific.
In closing, big thanks to my team at QCRI for translating my vision of Micro-Mappers into reality and for trusting me well over a year ago when I said we needed to extend our work to aerial imagery. All of the above research would simply not have been possible without MicroMappers existing. Big thanks as well to our excellent partners at EPFL and Southampton for sharing our vision and for their hard work on our joint projects. Last but certainly not least, sincerest thanks to digital volunteers from SBTF and beyond for participating in these digital humanitarian deployments.
Posted by earthpatrol on December 4, 2015 at 8:02pm
It's great to see folks doing real science with open-source UAV systems.
ENAC UAV Lab team and Meteo-France (CNRS-GAME and ENM) teams have spent several days at the Atmospheric Research Center of Lannemezan (in the south of France) in order to perform experiments for simultaneous meteorological measurements through multi-UAV flight.
NicaDrone is announcing the 3rd generation of electro permanent magnet developed with Zubax Robotics with a bunch of new features.
First a crappy video:
Overview
The OpenGrab EPM v3 is an electropermanent magnet, combining the advantages of electro and permanent magnets. The device creates a very strong magnetic contact with a ferrous target. It supports UAVCAN, RC PWM and push button operation. OpenGrab EPM v3 has been developed by NicaDrone in cooperation with Zubax Robotics.
Theory of operation
The NXP LPC11C24 MCU drives a mosfet connected to a transformer in a flyback configuration to charge the main PET capacitors up to 475 V.
A thyristor bridge is used to discharge the capacitor in either direction through the winding inside the AlNiCo material. This results in a short, 20 us 300 A pulse creating a 100 kAm field in the AlNiCo material. This causes the magnetic domains in the AlNiCo magnets to align in a particular orientation to form a magnetic circuit with a ferrous target.
An ON command results in the charging and discharging the capacitors 3 times to achieve full magnetization.
An OFF command results in charging and discharging the capacitors several times with changing direction and decreasing amplitude, effectively degaussing the AlNiCo material.
Applications
Cargo lifting in UAV and robotic applications.
Robot workholding.
Education, demonstration of magnetic properties.
Features
Steady state power under 50 mW
Short cycle time
Variety of interfaces:
RC PWM
UAVCAN
Push button
Open source firmware and hardware
5 V supply voltage, can be powered via RC PWM connector or via UAVCAN port
Mechanical properties
The bottom surface of the magnet should be kept clean, because dirt or metal shavings can be crushed into the surface when the magnet is turning on, causing an insulation breakdown.
The diagrams below document the mechanical arrangement and dimensions (click to enlarge):
Characteristics
Symbol
Parameter
Minimum
Typical
Maximum
Unit
Tcycle(ON)
Time to complete one cycle
0.75
s
Tcycle(OFF)
Time to complete one cycle
1.2
s
Fmax
Max holding force
200
N
Vsupply
Operating voltage
4.75
5.0
5.5
V
Isteady
Steady state current draw
10
mA
Ipeak
Peak current draw during cycle execution
1000
mA
m
Mass of the device
65
g
toperating
Operating temperature
-40
+70
°C
RHoperating
Operating humidity (non-condensing)
0
75
%
Developers
For debugging we recommend the Zubax DroneCode Probe, a multi-purpose debugger for STM32 and other Cortex-M based microcontrollers. It allows one to test and debug firmware on the microcontroller and is compatible with majority of IDEs (Eclipse and derivatives, CodeBlocks, etc.). Zubax DroneCode Probe is equipped with DroneCode-approved connectors which enables seamless compatibility with DroneCode projects such as Pixhawk and NicaDrones EPM V3.
Posted by Denis Krylov on December 4, 2015 at 5:00am
Hello everyone,
I would like to share with you my latest project. Currently I am at the crossroads and would appreciate any feedback.
The main goal was to design a truly portable drone that fits into a backpack. I was unhappy with the foldable frames on the market, as they were all too large. The ones which fold in horizontal plane still have a problem with landing gear, and in umbrella-type frames you need to sacrifice the space for electronics. I ended up with such requirements:
Compactly folding core
Arms fixed with a screw (no plastic clips)
Detachable legs
I've decided to use two 16 mm tubes as a frame core in order to make it strong and flexible. I've made two modules for front and rear arms. PMMA plastic is used to reduce the prototype costs (however, 3mm plates are surprisingly strong), later I am planning to switch to carbon fiber. The most compact folding is achieved when arms are above each other.
Firstly I was attaching legs to the core tubes (PVC plastic). But then I realized that they can be fixed with the same screw as arms. And this shortens the assembly time. Legs can have different length, mine are short just because I ran out of tubes.
Following the modern trend I added a vibration isolated plate. The number of damping balls can vary depending on the load. Some balls have flexible position in order to fit to different core sizes.
My current frame size is 710mm and it folds into ~ 370x170x120 mm, which is less than 8L volume.
While the weather was not good for flying I decided to collect my thoughts. The frame is portable and also turned out to be quite flexible. Several holes can be drilled for the arm-fixing screw -> several square frames can be build from the same parts.
I started to dream about "Lego" for drones. The main point about "Lego" is that from the same parts one can build various things. There are some plastic analogues like RotorBits, however I was considering only carbon fiber and aluminum parts. Currently with my friends we are working on such set of universal parts for multirotors. Here are the characteristics we implemented in the kit:
Even my large 710 mm drone fits into a backpack. The frame is easily customizable: in order to change the size one simply slides the arm-modules, also variable parts can be attached to core tubes or to the center plate.
At this point I would like to hear your opinion. Did you also think about a truly portable DIY drone? Which characteristics would be the most important?
