[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.
Soon, perhaps even by the time you read this, the rules for flying remote-controlled aircraft in the United States will be very different. The Federal Aviation Authority (FAA) is pushing hard to repeal Section 336, which states that small remote-controlled aircraft as used for hobby and educational purposes aren’t under FAA jurisdiction. Despite assurances that the FAA will work towards implementing waivers for hobbyists, critics worry that in the worst case the repeal of Section 336 might mean that remote control pilots and their craft may be held to the same standards as their human-carrying counterparts.
Section 336 has already been used to shoot down the FAA’s ill-conceived attempt to get RC pilots to register themselves and their craft, so it’s little surprise they’re eager to get rid of it. But they aren’t alone. The Commercial Drone Alliance, a non-profit association dedicated to supporting enterprise use of Unmanned Aerial Systems (UAS), expressed their support for repealing Section 336 in a June press release:
Basic ‘rules of the road’ are needed to manage all this new air traffic. That is why the Commercial Drone Alliance is today calling on Congress to repeal Section 336 of the FAA Modernization and Reform Act of 2012, and include new language in the 2018 FAA Reauthorization Act to enable the FAA to regulate UAS and the National Airspace in a common sense way.
With both the industry and the FAA both pushing lawmakers to revamp the rules governing small remote-controlled aircraft, things aren’t looking good for the hobbyists who operate them. It seems likely those among us with a penchant for airborne hacking will be forced to fall in line. But what happens then?
Continue reading “Will Drones and Planes be Treated as Equals by FAA?”
We’re not entirely sure what to call this one. It’s got the usual trappings of a drone, but with only a single rotor it clearly can’t be called by any of the standard multicopter names. Helicopter? Close, but not quite, since the rotor blades are fixed-pitch. We’ll just go with “monocopter” for now and sort out the details later for this ducted-fan, thrust-vectored UAV.
Whatever we choose to call it — builder [tesla500] dubbed it the simultaneously optimistic and fatalistic “Ikarus” — it’s really unique. The monocopter is built around a 90-mm electric ducted fan mounted vertically on a 3D-printed shroud. The shroud serves as a mounting point for the landing legs and for four servos that swivel vanes within the rotor wash. The vanes deflect the airstream and provide the thrust vectoring that gives this little machine its control.
Coming to the correct control method was not easy, though. Thanks mainly to the strong gyroscopic force exerted by the rotor, [tesla500] had a hard time getting the flight controller to cooperate. He built a gimballed test stand to work the problem through, and eventually rewrote LibrePilot to deal with the unique forces on the craft and tuned the PID loops accordingly. Check out the results in the video below.
Some attempts to reduce the number of rotors work better than others, of course, but this worked out great, and we’re looking forward to the promised improvements to come.
Continue reading “Single-Rotor Drone: a Thrust-Vectoring Monocopter”
If you pay attention to airplane news — or you watched the film Sully — you know planes have problems with birds. Sully was about US Airways flight 1549 which struck a flock of geese and ditched in the Hudson river. Engineers at Caltech say that was the inspiration for them to develop a control algorithm that enables a single drone scarecrow to herd flocks of birds away from airports.
Airports have tried a lot of things to discourage birds ranging from trained falcons to manually-piloted drones. Apparently, herding birds is harder than you would think. If you fly the drone too far from a flock, it will ignore the threat. If you get too close, the flock will scatter making it both threaten a larger area and harder to control.
Continue reading “High Tech Drone Scarecrows Can Make Airports Safer”
Fair warning: [Paweł Spychalski]’s video is mostly him talking about how bad his “dualcopter” ended up. There are a few sequences of the ill-fated UAV undergoing flight tests, most of which seem to end with it doing a reasonable impression of a post-hole auger. We have to admit that it’s a pretty poor drone. But one can only truly fail if one fails to have some fun doing it, [Paweł] enjoyed considerable success, at least judging by the glee with which he repeatedly cratered the craft.
The overall idea seems to make sense, with coaxial props mounted in the middle of a circular 3D-printed frame. Mounted below the props are crossed vanes controlled by two servos. The vanes sit in the rotor wash and provide pitch and roll control, while yaw and thrust are controlled by varying the speeds of the counter-rotating props. [Paweł] knew going in that this was a sketchy aerodynamic design, and was surprised it performed as well as it did. But with ground effects limiting roll and pitch control close to the ground, the less-than-adequate thrust due to turbulence between the rotors, and the tendency for the center of mass and the center of gravity to get out whack with each other, all made for a joyously unstable and difficult to control aircraft.
Despite the poor performance, [Paweł] has plans for a Mark II dualrotor, a smaller craft with some changes based on what he learned. He’s no slouch at pushing the limits with multirotors, with 3D-printed racing quad frames and using LoRa for control beyond visual range. Still, we’re sure he’d appreciate constructive criticism in the comments, and we wish him luck with the next one.
Continue reading “Fail of the Week: Two Rotors Are Not Better Than Four”
I’ll admit it. I have a lot of drones. Sitting at my desk I can count no fewer than ten in various states of flight readiness. There are probably another half dozen in the garage. Some of them cost almost nothing. Some cost the better part of a thousand bucks. But I recently bought a drone for $100 that is both technically interesting and has great potential for motivating kids to learn about programming. The Tello is a small drone from a company you’ve never heard of (Ryze Tech), but it has DJI flight technology onboard and you can program it via an API. What’s more exciting for someone learning to program than using it to fly a quadcopter?
For $100, the Tello drone is a great little flyer. I’d go as far as saying it is the best $100 drone I’ve ever seen. Normally I don’t suggest getting a drone with no GPS since the price on those has come down. But the Tello optical sensor does a great job of keeping the craft stable as long as there is enough light for it to see. In addition, the optical sensor works indoors unlike GPS.
But if that was all there was to it, it probably wouldn’t warrant a Hackaday post. What piqued my interest was that you can program the thing using a PC. In particular, they use Scratch — the language built at MIT for young students. However, the API is usable from other languages with some work.
Information about the programming environment is rather sparse, so I dug in to find out how it all worked.
Continue reading “Hands-On: Flying Drones with Scratch”
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.
Continue reading “MIT Breaks Autonomous Drone Speed Limits By Not Sweating Obstacles”