If you’re really interested in aircraft and flying, there are many ways to explore that interest. There are models of a wide range of sizes and complexities that are powered and remote-controlled, and even some small lightweight aircraft that can get you airborne yourself for a minimum of expense. If you’re lucky enough to have your own proper airplane, though, and you’re really into open source projects, you can also replace your airplane’s avionics kit with your own open source one.
Avionics are the electronics that control and monitor the aircraft, and they’re a significant part of the aircraft’s ability to fly properly. This avionics package from [j-omega] (who can also be found on hackaday.io) will fit onto a small aircraft engine and monitor things like oil temperature, RPM, coolant temperature, and a wide array of other features of the engine. It’s based on an ATmega microcontroller, and has open-source schematics for the entire project and instructions for building it yourself. Right now it doesn’t seem like the firmware is available on the GitHub page yet, but will hopefully be posted soon for anyone who’s interested in an open-source avionics package like this.
The project page does mention that this is experimental as well, so it might not be advised to use in your own personal aircraft without some proper testing first. That being said, if you’ve heard that warning and have decided just to stay on the ground, it’s possible to have a great experience without getting in a real airplane at all.
[Leo Sampson Goolden] is a boatbuilder and Sailor. He’s a prime example of a dwindling group of shipwrights who build sailing vessels the traditional way. In 2017, he was given the opportunity to buy Tally Ho, a Yacht built back in 1910. Once a proud ship, Tally Ho now sat as a shell under a shrink-wrap tarp. Her deck was rotted, her keel cracked. Any sane person would have moved on. Thankfully [Leo] is not quite sane, and began a quest to bring this history ship back to its former glory.
Tally Ho isn’t just an old boat. She is a 48-foot long gaff cutter yacht designed by the famous Albert Strange and built in Sussex, England. Tally Ho won the 1927 Fastnet Race (corrected time) when rough seas caused all but two boats to bow out.
To say [Leo] has his work cut out for him would be an understatement. Tally Ho lived a hard life, from racing to fishing. A complete restoration was needed. In fact, it would have been cheaper and easier to build a replica rather than restore the original. [Leo] wanted to save Tally Ho though, so he bought the boat for one dollar, and began to put all his time, effort, and funds into restoring her. This work includes carefully documenting each piece as it is removed.
Some of the tools and materials are traditional – such as chisels and red lead putty. But [Leo] is using power tools as well, including a custom-built chainsaw mount for shaping the keel. His videos are entertaining and illustrate many techniques of boat building. Wherever possible, [Leo] adds captions to explain the meanings of boat building terms, as well as explains the different terms used in England and the USA. In the latest video, you can watch along as [Leo] creates a Dutchman to fill in a knot in the keel. Can check that out in the video after the break.
Electric vehicles are fertile ground for innovation because the availability of suitable motors, controllers, and power sources makes experimentation accessible even to hobbyists. Even so, [John Dingley] has been working on such vehicles since about 2009, and his latest self-balancing electric unicycle really raises the bar by multiple notches. It sports a monstrous 3000 Watt brushless hub motor intended for an electric motorcycle, and [John] was able to add numerous touches such as voice feedback and 1950’s styling using surplus aircraft and motorcycle parts. To steer, the frame changes shape slightly with help of the handlebars to allow the driver’s center of gravity to shift towards one or the other outer rims of the wheel. In a test drive at a deserted beach, [John] tells us that the bike never went above 20% power; the device’s limitations are entirely by personal courage. Watch the video of the test, embedded below.
They say necessity is the mother of invention. But if the thing you need has already been invented but is extremely expensive, another mother of invention might be budget overruns. That was the case when [klinstifen]’s local government decided to put in countdown clocks at bus stops, at a whopping $25,000 per clock. Thinking that was a little extreme, he decided to build his own with a much smaller price tag.
The project uses a Raspberry Pi Zero W as its core, and a 16×32 RGB LED matrix for a display. Some of the work is done already, since the bus system has an API that is readily available for use. The Pi receives the information about bus schedules through this API and, based on its location, is able to determine the next bus arrival time and display it on the LED matrix. With the custom 3D printed enclosure and all of the other material, the cost of each clock is only $100, more than two orders of magnitude less expensive.
Hopefully the local government takes a hint from [klinstifen] and decides to use a more sane solution. In the meantime, you might be able to build your own mass transit clock that you can use inside your own house, rather than at the train station, if you’re someone who has a hard time getting to the bus stop on time.
[Revanth Kailashnath] writes in to tell us about an interesting project he and his team have been working on for their “Real Time Embedded Programming” class at the University of Glasgow. Intended to combat the harsh and dangerous winters in Glasgow, their system uses a Raspberry Pi and a suite of sensors to automatically deploy a brine solution to streets and sidewalks. While the project is still only a proof of concept and hasn’t been deployed, the work the team has done so far runs the gamut from developing their own PCBs to creating a web-based user interface.
The core idea is simple. If the conditions are right for ice to form, spray salt water. Using salt water is a cheap and safe way of clearing and preventing ice as it simply drops the temperature at which water freezes. The end result is that the ice won’t form until it gets down to 10F (-12C) or so. Not a perfect solution, but it can definitely help. Of course, you don’t want to spray people with salt water as they pass by, so there’s a bit more to it than that.
Using the venerable DHT22 sensor the team can get the current temperature and humidity, which allows them to determine when it’s time to start spraying. But to prevent any wet and angry pedestrians, a HC-SR501 PIR motion sensor is used. If the system sees motion it will stop for a while to let the activity quiet down.
Monitoring the sensors and controlling the pump is done by a daemon written in C++, which also logs data to an SQL database, which in turn feeds their PHP web interface. In the video after the break, [Revanth] demonstrates how the system is constantly making decisions based on the input of the various sensors. Environmental data and motion is analysed every few seconds to provide a real-time solution.
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.
A self-driving Uber Volvo XC90, San Francisco.
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!
Few would question the health benefits of ditching the car in favor of a bicycle ride to work — it’s good for the body, and it can be a refreshing relief from rat race commuting. But it’s not without its perils, especially when one works late and returns after dark. Most car versus bicycle accidents occur in the early evening, and most are attributed to drivers just not seeing cyclists in the waning light of day.
To decrease his odds of becoming a statistics and increase his time on two wheels, [Dave Schneider] decided to build a better bike light. Concerned mainly with getting clipped from the rear, and having discounted the commercially available rear-mounted blinkenlights and wheel-mounted persistence of vision displays as insufficiently visible, [Dave] looked for ways to give drivers as many cues as possible. Noticing that his POV light cast a nice ground effect, he came up with a pavement projecting display using four flashlights. The red LED lights are arranged to flash onto the roadway in sequence, using the bike’s motion to sweep out a sort of POV “bumper” to guide motorists around the bike. The flashlight batteries were replaced with wooden plugs wired to the Li-ion battery pack and DC-DC converter in the saddle bag, with an Arduino tasked with the flashing duty.
The picture above shows a long exposure of the lights in action, and it looks very effective. We can’t help but think of ways to improve this: perhaps one flashlight with a servo-controlled mirror? Or variable flashing frequency based on speed? Maybe moving the pavement projection up front for a head-down display would be a nice addition too.
