Some of us get into robotics dreaming of big heavy metal, some of us go in the opposite direction to build tiny robots scurrying around our tabletops. Our Hackaday.io community has no shortage of robots both big and small, each an expression of its maker’s ideals. For 2018 Hackaday Prize, [Bill Weiler] entered his vision in the form of Project Johnson Tiny Robot.
[Bill] is well aware of the challenges presented by working at a scale this small. (If he wasn’t before, he certainly is now…) Forging ahead with his ideas on how to build a tiny robot, and it’ll be interesting to see how they pan out. Though no matter the results, he has already earned our praise for setting aside the time to document his progress in detail and share his experience with the community. We can all follow along with his discoveries, disappointments, and triumphs. Learning about durometer scale in the context of rubber-band tires. Exploring features and limitations of Bluetooth hardware and writing code for said hardware. Debugging problems in the circuit board. And of course the best part – seeing prototypes assembled and running around!
As of this writing, [Bill] had just completed assembly of his V2 prototype which highlighted some issues for further development. Given his trend of documenting and sharing, soon we’ll be able to read about diagnosing the problems and how they’ll be addressed. It’s great to have a thoroughly documented project and we warmly welcome his robot to the ranks of cool tiny robots of Hackaday.io.
I print something nearly every day, and over the last few years, I’ve created hundreds of practical items. Parts to repair my car, specialized tools, scientific instruments, the list goes on and on. It’s very difficult for me to imagine going back to a time where I didn’t have the ability to rapidly create and replicate physical objects at home. I can say with complete honesty that it has been an absolutely life-changing technology for me, personally.
But to everyone else in my life, my friends and family, 3D printers are magical boxes which can produce gadgets, weapons, and characters from their favorite games and movies. Nobody wants to see the parts I made to get my girlfriend’s 1980’s Honda back on the road before she had to go to work in the morning, they want to see the Minecraft block I made for my daughter. I can’t get anyone interested in a device I made to detect the algal density of a sample of water, but they all want me to run off a set of the stones from The Fifth Element for them.
As I recently finished just such a project, a 3D printed limpet mine from Battlefield 1, I thought I would share some thoughts on the best practices for turning fiction into non-fiction.
In Japan, tea ceremony (cha-dou) is revered as a way to a gain deeper insights into life and philosophy. Traditional Japanese tea ceremony practitioners put in long hours to master the intricacies and details of pouring tea. The road to becoming a tea master is crucial as it develops the practitioner’s mental state as well as physical technique.
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.
Seeing as grinding pepper requires at least as much torque as turning an average key in an average lock, the electric pepper mill makes perfect sense to use as a lock actuator. This build actually uses the electric pepper mill to directly turn the key in the lock, courtesy of an adapter to couple the square output shaft to the key. The adapter was crafted out of a moldable plastic called MultiMorph. The pepper mill is being used for its high-torque motor & gearbox, which makes it absolutely perfect for this application.
The rest of the project leans heavily on the hacker’s go-to, an Arduino and some off-the-shelf gesture recognition modules. Now, it’s possible to lock and unlock the door at the press of a button or the wave of a hand! Video after the break.
This project is so pretty in its own right, it doesn’t need a case!
Clocks are a recurring feature among the projects we feature here on Hackaday, with several common themes emerging among them. We see traditional clocks with hands, digital clocks with all forms of display including the ubiquitous Nixie tube, and plenty of LED ring clocks. [Matt Evans]’s build is one of the final category, a particularly nice LED ring clock using wire-ended multi-colour LEDs. Other clocks produce an effect that looks good from across the room, but this one is also a work of beauty when examined in close-up.
Behind it all are four interlocking semicircular PCBs, an STM32F051C6T6 ARM Cortex M0 microcontroller which controls the clock, and a brace of driver chips. The different “hands” of the clock are expressed as different LED colours, and there is a variety of different colour and clock “hand” effects. An acrylic ring completes the effect, by covering the LEDs themselves. He’s put together a video of the clock in action, which you can see below the break.
