A DIY Enclosed Motorcycle To Keep You Dry In The Rain

Motorcyclist’s vulnerability to bodily harm and weather has spawned several enclosed motorcycle designs over the years. Fascinated by the idea, [Meanwhile in the garage] finally got around to building his own. (Video, embedded below.)

The vehicle started life as a 125cc scooter, stripped of all the unnecessary bits, he welded a steel cockpit onto it. A windshield, doors, and side windows were also added. The ends of the handlebars were cut off and reattached at 90 degrees to fit inside the narrow cockpit. A pair of retractable “training wheels” keep the vehicle upright and at slow speeds.

Legalities aside, we can’t help but think that the first test drives should not have been on a public road. It almost ended in disaster when a loose axle nut on the front wheel caused steering oscillations which caused the vehicle to tip over. Fortunately, there were no injuries and only light cosmetic damage, so a more successful test followed the first.

While many companies have tried, enclosed motorcycles have never achieved much commercial success. Probably because they inhabit a no-mans-land between the rush and freedom of riding a motorcycle and the safety and comfort of a car.

For some less extreme conversion, check out this electric motorcycle, or a rideable tank track.

Continue reading “A DIY Enclosed Motorcycle To Keep You Dry In The Rain”

Hackaday Links: November 15, 2020

Now that we drive around cars that are more like mobile data centers than simple transportation, there’s a wealth of data to be harvested when the inevitable crashes occur. After a recent Tesla crash on a California highway, a security researcher got a hold of the car’s “black box” and extracted some terrifying insights into just how bad a car crash can be. The interesting bit is the view of the crash from the Tesla’s forward-facing cameras with object detection overlays. Putting aside the fact that the driver of this car was accelerating up to the moment it rear-ended the hapless Honda with a closing speed of 63 MPH (101 km/h), the update speeds on the bounding boxes and lane sensing are incredible. The author of the article uses this as an object lesson in why Level 2 self-driving is a bad idea, and while I agree with that premise, the fact that self-driving had been disabled 40 seconds before the driver plowed into the Honda seems to make that argument moot. Tech or not, someone this unskilled or impaired was going to have an accident eventually, and it was just bad luck for the other driver.

Last week I shared a link to Scan the World, an effort to 3D-scan and preserve culturally significant artifacts and create a virtual museum. Shortly after the article ran we got an email from Elisa at Scan the World announcing their “Unlocking Lockdown” competition, which encourages people to scan cultural artifacts and treasures directly from their home. You may not have a Ming Dynasty vase or a Grecian urn on display in your parlor, but you’ve probably got family heirlooms, knick-knacks, and other tchotchkes that should be preserved. Take a look around and scan something for posterity. And I want to thank Elisa for the link to the Pompeiian bread that I mentioned.

The Defense Advanced Research Projects Agency (DARPA)has been running an interesting challenge for the last couple of years: The Subterranean (SubT) Challenge. The goal is to discover new ways to operate autonomously below the surface of the Earth, whether for mining, search and rescue, or warfare applications. They’ve been running different circuits to simulate various underground environments, with the most recent circuit being a cave course back in October. On Tuesday November 17, DARPA will webcast the competition, which features 16 teams and their autonomous search for artifacts in a virtual cave. It could make for interesting viewing.

If underground adventures don’t do it for you, how about going upstairs? LeoLabs, a California-based company that specializes in providing information about satellites, has a fascinating visualization of the planet’s satellite constellation. It’s sort of Google Earth but with the details focused on low-earth orbit. You can fly around the planet and watch the satellites whiz by or even pick out the hundreds of spent upper-stage rockets still up there. You can lock onto a specific satellite, watch for near-misses, or even turn on a layer for space debris, which honestly just turns the display into a purple miasma of orbiting junk. The best bit, though, is the easily discerned samba-lines of newly launched Starlink satellites.

A doorbell used to be a pretty simple device, but like many things, they’ve taken on added complexity. And danger, it appears, as Amazon Ring doorbell users are reporting their new gadgets going up in flame upon installation. The problem stems from installers confusing the screws supplied with the unit. The longer wood screws are intended to mount the device to the wall, while a shorter security screw secures the battery cover. Mix the two up for whatever reason, and the sharp point of the mounting screw can find the LiPo battery within, with predictable results.

And finally, it may be the shittiest of shitty robots: a monstrous robotic wolf intended to scare away wild bears. It seems the Japanese town of Takikawa has been having a problem with bears lately, so they deployed a pair of these improbable looking creatures to protect themselves. It’s hard to say what’s the best feature: the flashing LED eyes, the strobe light tail, the fact that the whole thing floats in the air atop a pole. Whatever it is, it seems to work on bears, which is probably good enough. Take a look in the video below the break.

Continue reading “Hackaday Links: November 15, 2020”

Fail Of The Week: Roboracer Meets Wall

There comes a moment when our project sees the light of day, publicly presented to people who are curious to see the results of all our hard work, only for it to fail in a spectacularly embarrassing way. This is the dreaded “Demo Curse” and it recently befell the SIT Acronis Autonomous team. Their Roborace car gained social media infamy as it was seen launching off the starting line and immediately into a wall. A team member explained what happened.

A few explanations had started circulating, but only in the vague terms of a “steering lock” without much technical detail until this emerged. Steering lock? You mean like The Club? Well, sort of. While there was no steering wheel immobilization steel bar on the car, a software equivalent did take hold within the car’s systems.  During initialization, while a human driver was at the controls, one of the modules sent out NaN (Not a Number) instead of a valid numeric value. This was never seen in testing, and it wreaked havoc at the worst possible time.

A module whose job was to ensure numbers stay within expected bounds said “not a number, not my problem!” That NaN value propagated through to the vehicle’s CAN data bus, which didn’t define the handling of NaN so it was arbitrarily translated into a very large number causing further problems. This cascade of events resulted in a steering control system locked to full right before the algorithm was given permission to start driving. It desperately tried to steer the car back on course, without effect, for the few short seconds until it met the wall.

While embarrassing and not the kind of publicity the Schaffhausen Institute of Technology or their sponsor Acronis was hoping for, the team dug through logs to understand what happened and taught their car to handle NaN properly. Driving a backup car, round two went very well and the team took second place. So they had a happy ending after all. Congratulations! We’re very happy this problem was found and fixed on a closed track and not on public roads.

[via Engadget]

Quadcopter With Tensegrity Shell Takes A Beating And Gets Back Up

Many of us have become familiar with the distinctive sound of multirotor toys, a sound frequently punctuated by sharp sounds of crashes. We’d then have to pick it up and repair any damage before flying fun can resume. This is fine for a toy, but autonomous fliers will need to shake it off and get back to work without human intervention. [Zha et al.] of UC Berkeley’s HiPeRLab have invented a resilient design to do so.

We’ve seen increased durability from flexible frames, but that left the propellers largely exposed. Protective bumpers and cages are not new, either, but this icosahedron (twenty sided) tensegrity structure is far more durable than the norm. Tests verified it can survive impact with a concrete wall at speed of 6.5 meters per second. Tensegrity is a lot of fun to play with, letting us build intuition-defying structures and here tensegrity elements dissipate impact energy, preventing damage to fragile components like propellers and electronics.

But surviving an impact and falling to the ground in one piece is not enough. For independent operation, it needs to be able to get itself back in the air. Fortunately the brains of this quadcopter has been taught the geometry of an icosahedron. Starting from the face it landed on, it can autonomously devise a plan to flip itself upright by applying bursts of power to select propeller motors. Rotating itself face by face, working its way to an upright orientation for takeoff, at which point it is back in business.

We have a long way to go before autonomous drone robots can operate safely and reliably. Right now the easy answer is to fly slowly, but that also drastically cuts into efficiency and effectiveness. Having flying robots that are resilient against flying mistakes at speed, and can also recover from those mistakes, will be very useful in exploration of aerial autonomy.

[IROS 2020 Presentation video (duration 14:16) requires free registration, available until at least Nov. 25th 2020. One-minute summary embedded below]

Continue reading “Quadcopter With Tensegrity Shell Takes A Beating And Gets Back Up”

Tales From The Sysadmin: Impending Hard Drive Doom

It should have been another fine day, but not all was well in paradise. Few things bring a creeping feeling of doom like a computer that hardlocks and then refuses to boot. The clicking sound coming from the tower probably isn’t a good sign either. Those backups are up to date, right? Right?

There are some legends and old stories about hard drive repair. One of my favorites is the official solution to stiction for old drives: Smack it with a mallet. Another trick I’ve heard repeatedly is to freeze a hard drive before trying to read data off of it. This could actually be useful in a couple instances. The temperature change can help with stiction, and freezing the drive could potentially help an overheating drive last a bit longer. The downside is the potential for condensation inside the drive. Don’t turn to one of these questionable fixes unless you’ve exhausted the safer options.

For the purpose of this article, we’ll assume the problem is the hard drive, and not another component like a power supply or SATA cable causing problems. A truly dead drive is a topic for another time, but if the drive is alive enough to show up as a block device when plugged in, then there’s hope for recovering the data. One of the USB to SATA cables available on your favorite online store is a great way to recover data. Another option is booting off a Linux DVD or flash drive, and accessing the drive in place. If you’re lucky, you can just copy your files and call it a day. If the file transfer fails because of the dying drive, or you need a full disk image, it’s time to pull out some tools and get to work. Continue reading “Tales From The Sysadmin: Impending Hard Drive Doom”

Poor Maintenance Could Have Led To Fatal B-17 Crash

In October the Nine-O-Nine, a fully restored Boeing B-17G bomber owned and operated by the Collings Foundation, crashed with thirteen people on board. After landing hard and skidding into the de-icing tanks at the Bradley International Airport, all but the tail and port wing of the 74 year old WWII aircraft was destroyed. Seven lives were lost in the accident, including that of Pilot Ernest “Mac” McCauley, who was regarded as one of the most experienced B-17 pilots in the world.

While the National Transportation Safety Board (NTSB) investigation is still ongoing and hasn’t made a final determination as to what ultimately brought down the Nine-O-Nine, enough serious maintenance issues were uncovered while examining the wreckage that the Federal Aviation Administration (FAA) has decided to rescind the Collings Foundation’s license to conduct any more paid flights on their remaining WWII aircraft. While many have spoken out in support of these “living history” flights, the FAA says they must be conducted in such a way that they don’t hinder the safety of other air traffic.

With the vast majority of the B-17’s airframe gone, the NTSB investigation has focused on the four 1,200 horsepower Wright R-1820 “Cyclone” engines recovered from the crash site. Investigators found that hastily attempted repairs to engine number 4, which is believed to have failed in-flight, were actually hindering normal operation:

Regarding engine 4, to prevent the magneto “P” leads from separating from the
magnetos, someone had attempted to rig the magneto leads in place with safety wire.

Inspection and testing of engine 4 left magneto revealed the movement of the safety-wired lead caused grounding to the case, which rendered the magneto lead inoperative.

Further, all of the spark plugs in the number 3 and 4 engines were found to be fouled and had electrode gaps that were out of tolerance. From an examination of the aircraft’s maintenance records, it was also learned that an arcing and burned wire had been replaced without any investigative steps taken to find what caused the failure to begin with.

With basic maintenance tasks either not being performed or at least done incorrectly, the FAA has called into question the culture of safety at the Collings Foundation. The paper is careful not to directly accuse the Foundation or any of its staff with outright negligence, but the implication seems clear.

The loss of Nine-O-Nine hit especially close to home for Hackaday. Just a month prior to the crash we had the opportunity to tour the aircraft, and came away with a newfound respect for not only those who designed and built the iconic bomber but the brave young men who flew it. Losing such a rare and historically significant aircraft and its crew was already a tragedy, but to find that negligence may be to blame is truly inexcusable.

ESP8266 And ESP32 WiFi Hacked!

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks,  but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house?  Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!