We were concerned when we saw [Brick Experiment Channel] test a drone propulsion pod made with Lego. After all, the thrust generated was less than the weight of the assembly. But a few tweaks got enough lift to overcome the assembly weight, as you can see in the video below.
The next step was to build three more pods and add some lightweight avionics and a battery. The first flight was a little dicey because the sensor orientation was off. Then there was some more software tuning before things really got airborne.
Small hobby aircraft and light plastic parts go hand in hand, and a 3D printing pen makes lightweight plastic things without the overhead of CAD work and running a 3D printer. So could a 3D pen create useful plastic bits for small quadcopters? [Michael Niggel] decided to find out by building his drone parts with a 3D pen loaded with ABS plastic. He mostly discovered that the created objects could politely be said to look like they were sketched by a toddler, but that’s not all he learned.
He found that in general creating an object was harder than the marketing materials implied. As soon as the filament exits the pen’s nozzle, the thin little molten line of plastic cools rapidly and does two things: it has a tendency to curl, and loses its desire to stick to things. [Michael] found the whole affair worked much less like ‘drawing in thin air’ and rather more like piping frosting, or caulking.
An almost functional micro quad frame. The arms aren’t rigid enough to hold the motors vertical when under power.
Nevertheless, [Michael] sought to discover whether a 3D pen could be used to make quick and dirty parts of any use. He created two antenna brackets and one micro quad frame. All three are chaotic messes, but one antenna bracket was perfectly serviceable. The 3D pen was indeed able to create a strangely-shaped part that would have been a nightmare to CAD up. The other antenna part worked, but didn’t do anything a zip tie wouldn’t have done better. The rapid cooling of the plastic from the 3D pen has an advantage: extrusions don’t “droop” like a glob of hot glue does before it hardens.
By now, [Michael] agreed that the best way to create a plastic part of any complexity whatsoever seemed to be to draw sections flat, build them up in layers, then use the pen to weld the pieces together and add bulk. The micro quad frame he made in this way doesn’t look any nicer than the other attempts, but it did hold the parts correctly. Sadly, it would not fly. Once the motors powered up, the arms would twist and the flight controller was unable to compensate for motors that wouldn’t stay straight. This could probably be overcome, but while the end result was dirty it certainly wasn’t quick. The 3D pen’s niche seems restricted to simple, unstressed parts that aren’t permitted to gaze up themselves in a mirror.
When it comes to robotic navigation, the usual approach is to go as technically advanced and “smart” as possible. Yet the most successful lifeforms that we know of follow a completely different approach. With limited senses and cognitive abilities, the success of invertebrates like ants and honeybees lie in cooperation in large numbers. A joint team of researchers from TU Delft, University of Liverpool and Radboud University of Nijmegen, decided to try this approach and experimented with a simple navigation technique to allow a swarm of tiny flying robots to explore an unknown environment.
The drones used were of-the-shelf Crazyflie 2.0 micro quadcopters with add-on boards. Sensors consisted of it’s onboard IMU, simple range finding sensors on a Multi-ranger deck for obstacle detection, and a down pointing optical flow sensor, on a Flow deck, to keep track of the distance travelled. To navigate, the drones used a “swarm gradient bug algorithm” (SGBA). Each drone in has different preferred direction of travel from takeoff. When an obstacle encountered, it follows the contour of the obstacle, and then continues in the preferred direction once the path is clear. When the battery drops to 60%, it returns to a wireless homing beacon. While this technique might not be the most efficient, it has the major advantage of being “lightweight” enough to implement on a cheap microcontroller, an STM32F4 in this case. The full research article is available for free, and is a treasure trove of information.
The main application researchers have in mind is for search and rescue. A swarm of drones can explore an unstable or dangerous area, and identify key areas to focus rescue efforts on. This can drastically reduce wasted time and risk to rescue workers. It is always cool to see complex problems being solved with simple solution, and we are keen to see where things go. Check out the video after the break. Continue reading “Tiny Drones Navigate Like Real Bugs”→
Power is the bane of drone pilots. You’d like to fly longer which means a bigger battery. But a bigger battery will weigh more which leads to less flight time. You have to strike a balance and for most consumer drones that balance is about 20 minutes of flight time, more or less. Researchers at Berkeley have a different idea: don’t use a bigger battery, but simply replace the battery in flight.
The idea isn’t completely new. After all, many planes refuel in flight — a technically sophisticated operation, but it occurs every day. The scheme here is to have a primary battery and a secondary battery. When the secondary battery is low, the drone ejects it while running on the primary battery. Another secondary battery flies to the drone and docks with it becoming the new main power source.
Regular Hackaday readers will have noted a succession of stories following the reports of drones in the air over British airports and in proximity to aircraft. We’ve consistently asked for a better quality of investigation and reporting into these cases, because so far the absence of reported tangible evidence of a drone being present casts doubt on the validity of the official reaction. For too long the official records of air proximity incidents have relied upon a shockingly low standard of proof when apportioning blame to drone operators, and this situation has contributed to something of a panic over the issue.
It seems that some members of the British drone flying community are on the case though. Airprox Reality Check are a group analysing air proximity reports and linking them to contemporary ADS-B and weather records to identify possible explanations. They have devised a rating system based upon a number of different metrics in an attempt to quantify the reliability of a particular report, and they are tabulating their analysis of air proximity reports on a month by month basis. This includes among many analyses such gems as Airprox Report #2019046, in which an Embraer 170 flying at 9000 feet and 20 km offshore reported a drone in close proximity. The Airprox Reality Check analysis points out that no known drone could manage that feat, and refers to a passing Boeing 737 revealed through ADS-B data as a more likely culprit.
Their latest news is that they have made a Freedom of Information request to the Air Proximity Board, asking for what evidence the Board has of a drone having been involved in any of the over 350 incidents in UK airspace having been reported as involving drones. The official response contains the following quote:
in all cases UKAB has no confirmation that a drone has flown close to an aircraft other than the report made by the pilot(s). Similarly, other than from the report of the pilot(s), UKAB has no confirmation that a drone was involved.
This confirms the view of the multirotor and drone community that has been reported by Hackaday in the past, that the whole British drone panic has been based upon unreliable and uncorroborated reports from eyewitnesses with little direct experience of multirotors. If any irresponsible drone operator is flying into close proximity with aircraft or otherwise into protected airspace then it goes without saying that they should be prosecuted, yet it seems that the community is being punished as though this had happened when the reality is that no such acts are proven to have occurred.
[Tim Schumacher] got a Crazepony Mini quadcopter and has been reprogramming it “bare metal” — that is to say he’s programming the STM32 without using an operating system or do-it-all environment. His post on the subject is a good reference for working with the STM32 and the quadcopter, too.
If you haven’t seen the quadcopter, it is basically a PC board with props. The firmware is open source but uses the Keil IDE. The CPU is an STM32 with 64K of program memory. In addition, the drone sports a wireless module, a digital compass, an altimeter, and a gyro with an accelerometer.
Although the post is really about the quadcopter, [Tim] also gives information about the Blue Pill which could be applied to other STM32 boards, as well. On the hardware side, he’s using a common USB serial port and a Python-based loader.
On the software side, he shows how to set up the linker and, using gcc, control output ports. Of course, there’s more to go to work the other peripherals, and Tim’s planning to investigate CMSIS to make that work easier. Our earlier post on STM32 prompted [Wassim] over on Hackaday.io to review a bunch of IDEs. That could be helpful, too.
We’ve been occasionally exploring examples of what could be the killer application for self-driving vehicles: autonomous freight deliveries, both long-haul and local, as well as some special use cases. Some, like UAV delivery of blood and medical supplies in Kenya, have taken off and are becoming both profitable and potentially life-saving. Others, like driverless long-haul trucking, made an initial splash but appear to have gone quiet since then. This is to be expected, as the marketplace picks winners and losers in a neverending quest to maximize return on investment. But the whole field seems to have gotten a bit sleepy lately, with no big news of note for quite a while.
That changed last week with Amazon’s announcement of Scout, their autonomous delivery vehicle. Announced first on Amazon’s blog and later picked up by the popular and tech press who repeated the Amazon material almost verbatim, Scout appears at first glance to be a serious attempt by Amazon to own the “last mile” of delivery – the local routes that are currently plied by the likes of UPS, FedEx, and various postal services. Or is it?
