Sometimes bad software is all that is holding good hardware back. [Michael Melchior] wanted to scavenge some motors and propellers for another project, so he bought an inexpensive quadcopter intending to use it for parts. [Michael] was so surprised at the quality of the hardware contained in his $100 drone that he decided to reverse engineer his quadcopter and give the autopilot firmware a serious upgrade.
Upon stripping the drone down, [Michael] found that it came with a flight management unit based on the STM32F405RG, an Inertial Measurement Unit, magnetic compass, barometric pressure sensor, GPS, WiFi radio, camera with tilt, optical flow sensor, and ultrasonic distance sensor, plus batteries and charger! The flight management unit also had unpopulated headers for SWD, and—although the manufacturer’s firmware was protected from reading—write protection hadn’t been enabled, so [Michael] was free to flash his own firmware.
We highly recommend you take a look at [Michael]’s 10 part tour de force of reverse engineering which includes a man-in-the-middle attack with a Raspberry Pi to work out its WiFi communication, porting the open-source autopilot PX4 to the new airframe, and deciphering unknown serial protocols. There are even amusing shenanigans like putting batteries in the oven and freezer to help figure out which registers are used as temperature sensors. He achieves liftoff at the end, and we can’t wait to see what else he’s able to make it do in the future.
Most amateur high altitude balloon payloads descend back to earth with a simple non-steerable parachute and can land hundreds of kilometers from the launch site in inaccessible areas. [Yohan Hadji] experienced this first-hand during a balloon launch conducted by his high school, which inspired him to R2Home, a GPS-guided parachute recovery system.
[Yohan]’s first challenge was to create a steerable parachute that can deploy reliably, so he started doing tests with a borrowed scale model paragliding wing. He quickly learned that a canopy aspect ratio of below two was needed for reliable deployment, so he started sewing his own canopies. Steering a parachute involves pulling on a pair of brake lines, one for each side of the parachute. A control stroke of about 20 cm was required, and [Yohan] found that RC sailboat winch servos work perfectly for this application. The entire system is designed to fit in a 7×40 cm tube, and the parachute is deployed with the help of a small drogue chute and a servo-operated release mechanism.
[Yohan] is working on a custom flight controller, built around a Teensy 4.1, GPS receiver, and digital compass. A possible alternative is Ardupilot, which we’ve seen used on several autonomous drones, gliders, and rovers. While this system might not be possible to return to the launch point, it could certainly close the gap, and land safely in a designated area.
So far [Yohan] has done a series of test drops from a drone at low altitude to test deployment and steering, using an RC controller. The project is open source, and the mechanical design files and control code is up on GitHub. As with most 16-year-olds, [Yohan]’s resources are limited, so feel free to drop him some financial help on the R2Home GoFundMe page. See the videos after the break for a development montage and project presentation. Continue reading “GPS Guided Parachutes For High Altitude Balloons”→
The new software update further extends the capabilities of Tesla vehicles to drive semi-autonomously. Despite the boastful “Full Self Driving” moniker, or FSD for short, it’s still classified as a Level 2 driving automation system, which relies on human intervention as a backup. This means that the driver must be paying attention and ready to take over in an instant, at all times. Users are instructed to keep their hands on the wheel at all times, but predictably, videos have already surfaced of users ignoring this measure.
Currently, if you want to use the Autopilot or Self-Driving modes on a Tesla vehicle you need to keep your hands on the wheel at all times. That’s because, ultimately, the human driver is still the responsible party. Tesla is adamant about the fact that functions which allow the car to steer itself within a lane, avoid obstacles, and intelligently adjust its speed to match traffic all constitute a driver assistance system. If somebody figures out how to fool the wheel sensor and take a nap while their shiny new electric car is hurtling down the freeway, they want no part of it.
So it makes sense that the company’s official line regarding the driver-facing camera in the Model 3 and Model Y is that it’s there to record what the driver was doing in the seconds leading up to an impact. As explained in the release notes of the June 2020 firmware update, Tesla owners can opt-in to providing this data:
Help Tesla continue to develop safer vehicles by sharing camera data from your vehicle. This update will allow you to enable the built-in cabin camera above the rearview mirror. If enabled, Tesla will automatically capture images and a short video clip just prior to a collision or safety event to help engineers develop safety features and enhancements in the future.
But [green], who’s spent the last several years poking and prodding at the Tesla’s firmware and self-driving capabilities, recently found some compelling hints that there’s more to the story. As part of the vehicle’s image recognition system, which usually is tasked with picking up other vehicles or pedestrians, they found several interesting classes that don’t seem necessary given the official explanation of what the cabin camera is doing.
If all Tesla wanted was a few seconds of video uploaded to their offices each time one of their vehicles got into an accident, they wouldn’t need to be running image recognition configured to detect distracted drivers against it in real-time. While you could make the argument that this data would be useful to them, there would still be no reason to do it in the vehicle when it could be analyzed as part of the crash investigation. It seems far more likely that Tesla is laying the groundwork for a system that could give the vehicle another way of determining if the driver is paying attention.
One of the biggest problems of owning an older boat (besides being a money pit – that is common to all boats regardless of age) is the lack of parts and equipment, and the lack of support for those parts if you can find them at all. Like most things, this is an area that can benefit greatly from some open source solutions, which the Open Boat Projects in Germany has been able to show. (Google Translate from German)
This group has solutions for equipment problems of all kinds for essentially any sized boat. At their most recent expo, many people were interested in open source solutions for situations where there is currently only an expensive proprietary option, such as support for various plotting devices. This isn’t the only part of this project, though. It includes many separate projects, like their solutions for autopilot and navigation. There are even complete hardware packages available, all fully documented.
Open source solutions for large, expensive things like this are often few and far between for a number of reasons. There are limited options for other modes of open source transportation too, as it seems like most large companies are not willing to give up their secrets easily. Communities like this, however, give us hope that people will have other options for repairing their vehicles without having to shell out too much money.
It’s probably one of the first lessons learned by new drivers: if you see a big, red fire truck parked by the side of the road, don’t run into it. Such a lesson appears not to have been in the Tesla Autopilot’s driver education curriculum, though – a Tesla Model S managed to ram into the rear of a fire truck parked at the scene of an accident on a southern California freeway. Crash analysis reveals that the Tesla was on Autopilot and following another vehicle; the driver of the lead vehicle noticed the obstruction and changed lanes. Apparently the Tesla reacted to that by speeding up, but failed to notice the stationary fire truck. One would think that the person driving the car would have stepped in to control the vehicle, but alas. Aside from beating up on Tesla, whose AutoPilot feature seems intent on keeping the market for batteries from junked vehicles fully stocked, this just points out how far engineers have to go before self-driving vehicles are as safe as even the worst human drivers.
The tech press is abuzz today with stories about potential union-busting at Kickstarter. Back in March, Kickstarter employees announced their intent to organize under the Office and Professional Employees International Union (OPEIU). On Thursday, two of the union organizers were fired. Clarissa Redwine, who recently hosted a Hack Chat, was one of those released; both she and Taylor Moore are protesting their terminations as an illegal attempt to intimidate Kickstarter employees and keep them from voting for the union. For their part, Kickstarter management says that both employees and two more were released as a result of documented performance issues during the normal review cycle, and that fourteen employees who are in favor of the union were given raises during this cycle, with three of them having been promoted. There will no doubt be plenty more news about this to come.
Would you pay $900 for a Nixie clock? We wouldn’t, but if you choose to buy into Millclock’s high-end timepiece, it may help soften the blow if you think about it being an investment in the future of Nixie tubes. You see, Millclock isn’t just putting together an overpriced clock that uses surplus Russian Nixies – they’re actually making brand new tubes. Techmoan recently reviewed the new clock and learned that the ZIN18 tubes are not coming from Czech Republic-based Dalibor Farný, but rather are being manufactured in-house. That’s exciting news for Nixie builders everywhere; while Dalibor’s tubes are high-quality products, it can’t hurt to have a little competition in the market. Nixies as a growth industry in 2019 – who’da thunk it?
We ran across an interesting project on Hackaday.io the other day, one that qualifies as a true hack. How much house can you afford? A simple question, but the answer can be very difficult to arrive at with the certainty needed to sign papers that put you on the hook for the next 30 years. Mike Ferarra and his son decided to answer this question – in a circuit simulator? As it turns out, circuit simulators are great at solving the kinds of non-linear simultaneous equations needed to factor in principle, interest, insurance, taxes, wages, and a host of other inflows and outflows. Current sources represent money in, current sinks money paid out. Whatever is left is what you can afford. Is this how Kirchoff bought his house?
And finally, is your parts inventory a bit of a mystery? Nikhil Dabas decided that rather than trying to remember what he had and risk duplicating orders, he’d build an application to do it for him. Called WhatDidIBuy, it does exactly what you’d think; it scrapes the order history pages of sites like Adafruit, Digi-Key, and Mouser and compiles a list of your orders as CSV files. It’s only semi-automated, leaving the login process to the user, but something like this could save a ton of time. And it’s modular, so adding support for new suppliers is a simple as writing a new scraper. Forgot what you ordered from McMaster, eBay, or even Amazon? Now there’s an app for that.
Self-driving cars have been in the news a lot in the past two weeks. Uber’s self-driving taxi hit and killed a pedestrian on March 18, and just a few days later a Tesla running in “autopilot” mode slammed into a road barrier at full speed, killing the driver. In both cases, there was a human driver who was supposed to be watching over the shoulder of the machine, but in the Uber case the driver appears to have been distracted and in the Tesla case, the driver had hands off the steering wheel for six seconds prior to the crash. How safe are self-driving cars?
Trick question! Neither of these cars were “self-driving” in at least one sense: both had a person behind the wheel who was ultimately responsible for piloting the vehicle. The Uber and Tesla driving systems aren’t even comparable. The Uber taxi does routing and planning, knows the speed limit, and should be able to see red traffic lights and stop at them (more on this below!). The Tesla “Autopilot” system is really just the combination of adaptive cruise control and lane-holding subsystems, which isn’t even enough to get it classified as autonomous in the state of California. Indeed, it’s a failure of the people behind the wheels, and the failure to properly train those people, that make the pilot-and-self-driving-car combination more dangerous than a human driver alone would be.
You could still imagine wanting to dig into the numbers for self-driving cars’ safety records, even though they’re heterogeneous and have people playing the mechanical turk. If you did, you’d be sorely disappointed. None of the manufacturers publish any of their data publicly when they don’t have to. Indeed, our glimpses into data on autonomous vehicles from these companies come from two sources: internal documents that get leaked to the press and carefully selected statistics from the firms’ PR departments. The state of California, which requires the most rigorous documentation of autonomous vehicles anywhere, is another source, but because Tesla’s car isn’t autonomous, and because Uber refused to admit that its car is autonomous to the California DMV, we have no extra insight into these two vehicle platforms.
Nonetheless, Tesla’s Autopilot has three fatalities now, and all have one thing in common — all three drivers trusted the lane-holding feature well enough to not take control of the wheel in the last few seconds of their lives. With Uber, there’s very little autonomous vehicle performance history, but there are leaked documents and a pattern that makes Uber look like a risk-taking scofflaw with sub-par technology that has a vested interest to make it look better than it is. That these vehicles are being let loose on public roads, without extra oversight and with other traffic participants as safety guinea pigs, is giving the self-driving car industry and ideal a black eye.
If Tesla’s and Uber’s car technologies are very dissimilar, the companies have something in common. They are both “disruptive” companies with mavericks at the helm that see their fates hinging on getting to a widespread deployment of self-driving technology. But what differentiates Uber and Tesla from Google and GM most is, ironically, their use of essentially untrained test pilots in their vehicles: Tesla’s in the form of consumers, and Uber’s in the form of taxi drivers with very little specific autonomous-vehicle training. What caused the Tesla and Uber accidents may have a lot more to do with human factors than self-driving technology per se.
You can see we’ve got a lot of ground to cover. Read on!