Over at RCgroups, user [Cesco] has shared a very interesting project which uses the ever-popular ESP8266 as both a transmitter and receiver for RC vehicles. Interestingly, this code makes use of the ESP-Now protocol, which allows devices to create a mesh network without the overhead of full-blown WiFi. According to the Espressif documentation, this mode is akin to the low-power 2.4GHz communication used in wireless mice and keyboards, and is designed specifically for persistent, peer-to-peer connectivity.
Switching an ESP8266 between being a transmitter or receiver is as easy as commenting out a line in the source code and reflashing the firmware. One transmitter (referred to as the server in the source code) can command eight receiving ESP8266s simultaneously. [Cesco] specifically uses the example of long-range aircraft flying in formation; only coming out of the mesh network when it’s time to manually land each one.
[Cesco] has done experiments using both land and air vehicles. He shows off a very hefty looking tracked rover, as well as a quickly knocked together quadcopter. He warns the quadcopter flies like “a wet sponge”, but it does indeed fly with the ESP’s handling all the over the air communication.
To be clear, you still need a traditional PPM-compatible RC receiver and transmitter pair to use his code. The ESPs are simply handling the over-the-air communication. They aren’t directly responsible for taking user input or running the speed controls, for example.
How does one go about programming a drone to fly itself through the real world to a location without crashing into something? This is a tough problem, made even tougher if you’re pushing speeds higher and high. But any article with “MIT” implies the problems being engineered are not trivial.
The folks over at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have put their considerable skill set to work in tackling this problem. And what they’ve come up with is (not surprisingly) quite clever: they’re embracing uncertainty.
Why Is Autonomous Navigation So Hard?
Suppose we task ourselves with building a robot that can insert a key into the ignition switch of a motor vehicle and start the engine, and could do so in roughly the same time-frame that a human could do — let’s say 10 seconds. It may not be an easy robot to create, but we can all agree that it is very doable. With foreknowledge of the coordinate information of the vehicle’s ignition switch relative to our robotic arm, we can place the key in the switch with 100% accuracy. But what if we wanted our robot to succeed in any car with a standard ignition switch?
Now the location of the ignition switch will vary slightly (and not so slightly) for each model of car. That means we’re going to have to deal with this in real time and develop our coordinate system on the fly. This would not be too much of an issue if we could slow down a little. But keeping the process limited to 10 seconds is extremely difficult, perhaps impossible. At some point, the amount of environment information and computation becomes so large that the task becomes digitally unwieldy.
This problem is analogous to autonomous navigation. The environment is always changing, so we need sensors to constantly monitor the state of the drone and its immediate surroundings. If the obstacles become too great, it creates another problem that lies in computational abilities… there is just too much information to process. The only solution is to slow the drone down. NanoMap is a new modeling method that breaks the artificial speed limit normally imposed with on-the-fly environment mapping.
Increasingly these days drones are being used for urban surveillance, delivery, and examining architectural structures. To do this autonomously often involves using “map-localize-plan” techniques wherein first, the location is determined on a map using GPS, and then based on that, control commands are produced.
A neural network that does steering and collision prediction can compliment the map-localize-plan techniques. However, the neural network needs to be trained using video taken from actual flying drones. But generating that training video involves many hours of flying drones at street level putting vehicles and pedestrians at risk. To train their DroNet, Researchers from the University of Zurich and the Universidad Politecnica de Madrid have come up with safer sources for that video, video recorded from driving cars and bicycles.
For the drone steering predictions, they used over 70,000 images and corresponding steering angles from the publically available car driving data from Udacity’s Open Source Self-Driving project. For the collision predictions, they mounted a GoPro camera to the handlebars of a bicycle and drove around a city. Video recording began when the bicycle was distant from an object and stopped when very close to the object. In total, they collected 32,000 images.
To use the trained network, images from the drone’s forward-facing camera were fed into the network and the output was a steering angle and a probability of collision, which was turned into a velocity. The drone remained at a constant height above ground, though it did work well from 1.5 meters to 5 meters up. It successfully navigated road lanes and avoided moving pedestrians and bicycles. Intersections did confuse it though, likely due to the open spaces messing with the collision predictions. But we think that shouldn’t be a problem when paired with map-localize-plan techniques as a direction to move through the intersection would be chosen for it using the location on the map.
As you can see in the video below, it not only does a decent job of flying down lanes but it also flies well in a parking garage and a hallway, even though it wasn’t trained for either of these.
The props are a fairly simple 3-bladed design, which were printed in both PETG and PLA. No major difference is noted between the two materials, and the quadcopter under test is able to fly with either. It was noted that the props perform particularly poorly in a crash, with all props failing even in the softest of crashes. We would recommend some eye (and body) protection when spinning these props up for the first time.
If you’re keen to try them out yourself, the STL file can be had here. The video notes that when printing 4 props, 2 must be reversed in the Y-axis to print a counter-rotating set of 4. The instructions used for creating propellers in Fusion3D are available here.
It’s a worthy experiment, and something we’d like to see more of. With a 3D printer, it’s possible to experiment with all manner of propeller designs, and we’d love to see the best and worst designs that are still capable of flight. We’ve also seen 3D printed props before, like this effort from [Anton].
It’s a trope of horror movies that demonic foes always return. No sooner has the bad guy been dissolved in a withering hail of holy water in the denoeument of the first movie, than some foolish child in a white dress at the start of the next is queuing up to re-animate it with a careless drop of blood or something. If parents in later installments of popular movie franchises would only keep an eye on their darn kids, it would save everybody a whole lot of time!
(d) RESTORATION OF RULES FOR REGISTRATION AND MARKING OF UNMANNED AIRCRAFT
.—The rules adopted by the Administrator
of the Federal Aviation Administration in the matter of registration
and marking requirements for small unmanned aircraft (FAA-2015-
7396; published on December 16, 2015) that were vacated by the
United States Court of Appeals for the District of Columbia Circuit
in Taylor v. Huerta (No. 15-1495; decided on May 19, 2017) shall
be restored to effect on the date of enactment of this Act.
This appears to reverse the earlier decision of the court, but does not specify whether there has been any modification to the requirements to prevent their being struck down once more by the same angle of attack. In particular, it doesn’t change any of the language in the FAA Modernization Act of 2012, which specifically prevents the Agency from regulating hobby model aircraft, and was the basis of Taylor v. Huerta. Maybe they are just hoping that hobby flyers get fatigued?
We took a look at the registration system before it was struck down, and found its rules to be unusually simple to understand when compared to other aviation rulings, even if it seemed to have little basis in empirical evidence. It bears a resemblance to similar measures in other parts of the world, with its 250 g weight limit for unregistered machines. It will be interesting both from a legal standpoint to see whether any fresh challenges to this zombie law emerge in the courts, and from a technical standpoint to see what advances emerge from Shenzhen as the manufacturers pour all their expertise into a 250 g class of aircraft.
The main idea was to create a drone that could autonomously follow a target which provided GPS data for the drone to follow. [Ryan] planned to implement this by having a smartphone provide GPS coordinates to the drone over WiFi, allowing the drone to track the user.
As this was a university project, he had to take a very carefully considered approach to the build. Given likely constraints on both money and time, he identified that the crux of the project was to develop the autonomous part of the drone, not the drone itself. Thus, off-the-shelf parts were selected to swiftly put together a drone platform that would serve as a test bed for his autonomous brain.
The write up is in-depth and shares all the gritty details of getting the various subsystems of the drone talking together. He also shares issues that were faced with altitude control – without any sensors to determine altitude, it wasn’t possible to keep the drone at a level height. This unfortunately complicated things and meant that he didn’t get to complete the drone’s following algorithm. Such roadblocks are highly common in time-limited university projects, though their educational value cannot be overstated. Overall, while the project may not have met its final goals, it was obviously an excellent learning experience, and one which has taught him plenty about working with drones and the related electronics.
As a British voter with some interest in the matter, I decided to write to my Member of Parliament about it, and since my letter says what I would have written to cover the story anyway it stands below in lieu of the normal Hackaday article format. If you are a British multirotor flier this is an issue you need to be aware of, and if you have any concerns you should consider raising them with your MP as well. Continue reading “The British Drone Law Reaches Parliament”→