There’s a car race going on right now, but it’s not on any sort of race track. There’s a number of companies vying to get their prototype on the road first. [Anurag] has already completed the task, however, except his car and road are functional models.
While his car isn’t quite as involved as the Google self driving car, and it doesn’t have to deal with pedestrians and other active obstacles, it does use a computer and various sensors to make decisions about how to drive. A Raspberry Pi 2 takes the wheel in this build, taking input from a Pi camera and an ultrasonic distance sensor. The Pi communicates to another computer over WiFi, where a neural network operates to make decisions about how to drive the car. It also makes decisions based on a database of pictures of the track, so it has a point of reference to go by.
The video of the car in action is worth a look. It’s not perfect, but it’s quite an accomplishment for this type of project. The possibility that self-driving car models could drive around model sets like model railroad hobbyists create is intriguing. Of course, this isn’t [Anurag]’s first lap around the block. He’s already been featured for building a car that can drive based on hand gestures. We’re looking forward to when he can collide with model busses.
There are a number of ways to control an automobile without using the pedals, and sometimes even without using the steering wheel. Most commonly these alternative control mechanisms are installed in vehicles whose owners are disabled in some way, but [Anurag] has taken this idea of alternative control one step further. He has built a car that can be driven by hand gestures alone.
On a remote controlled car, a Raspberry Pi 2 was installed that handles processing and communication. A wireless network is created on the Pi, and a laptop connects to the Pi over the network. The web camera on the laptop regularly captures frames at 15 fps to check for the driver’s hand gestures. The image is converted to gray scale, thresholded, contours are obtained, and the centroid and farthest points are obtained.
After some calculations are done, a movement decision is taken. The decision is passed to the Pi, which in turn, passed that to the internal chip of the car. All of the code is available on the project’s github page. [Anurag] hopes that this can be scaled up to full sized cars in the future. We’ve seen gesture-based remote controls before that rely on Sonar sensors, so it’s interesting to see one that relies strictly on image processing.
[TVMiller] has a bone to pick with you if you let your car idle while you chat or text on your phone. He doesn’t like it, and he wants to break you of this wasteful habit – thus the idle-deterrence system he built that he seems to want on every car dashboard.
In the video below, the target of his efforts is clear – those who start the car then spend time updating Twitter or Instagram. His alarm is just an Arduino Nano that starts a timer when the car is started. Color-coded LEDs mark the time, and when the light goes red, an annoying beep starts to remind you to get on with the business of driving. The device also includes an accelerometer that resets the timer when the vehicle is in motion; the two-minute timeout should keep even the longest stop light from triggering the alarm.
[TVMiller] plans an amped-up version of the device built around an MKR1000 that will dump idle to moving ratios and other stats to the cloud. That’s a little too Big Brother for our tastes, but we can see his point about how wasteful just a few minutes of idling can be when spread over a huge population of vehicles. This hack might make a nice personal reminder to correct wasteful behavior. It could even be rolled into something that reads the acceleration and throttle position directly from the OBD port, like this Internet of Cars hack we featured a while back.
[Daniel Norée] started the OpenR/C project back in 2012 when he bought a Thing-O-Matic. In search of a project to test out his new printer, he set his sights on a remote controlled car, which as he put it,”… seemed like the perfect candidate, as it presents a lot of challenges with somewhat intricate moving parts along with the need for a certain level of precision and durability.”
After releasing his second design, the OpenR/C Truggy, he realized a community was forming around this idea, and needed a place to communicate. So, he created a Google+ group. Today, the Truggy has been downloaded over 100,000 times and the Google group has over 5,000 members. It’s a very active community of RC and 3d printing enthusiasts who are testing the limits of what a 3d printer can do.
[wattnotions] has been playing with matches, well the box they come in anyway. One day he was letting synapses fire unsupervised, and wondered if he could build a robot inside of a matchbox. His first prototype was a coin lithium battery and scrounged motors from those 3 US Dollar servos you can buy by the dozen. It scooted around just fine, but it drained the battery instantly and was a little boring.
Next, he etched a board. It had a little PIC micro, a connector for a mini LiPo, and an H bridge. It fired up just fine, and even though it drained the battery way too fast, at least it wasn’t brainless anymore. In our experience, robots tend to discard all the useful data they collect anyway, so being blind wasn’t too much of a problem.
Inspired and encouraged, with synapses gloriously undeterred, [wattnotions] set out to make a version 2. This time he ordered a board from OSHPark, made a 3D model in SketchUp, and proceeded to lock himself out from his own chip. Without a high voltage programmerhe was out of luck. The development was unfortunately put on hold.
It was fun to read along with [wattnotions] as he went on a small robot adventure. We hope he’ll complete a version 3 and have a swarm of the little fellows scooting around.
This could be the start of a new thing. [HarpDude] showed off his String Car Racers over on the Adafruit forum. It’s like a small model cable car on caffeine. String up enough of them and go head to head racing with others.
A motor with a small pulley runs over a length of string stretched between 2 posts. Below the pulley, acting as a counterweight balance, is the rest of the racer. A Trinket board, motor driver, 9V battery and a pair of long lever micro switches to detect end of travel. The switches also help reverse the motor. A piece of galvanized wire acts as a guide preventing the String Car from jumping off the string. And discovering the benefits of a micro-controller design, as against discrete TTL/CMOS, old timer [HarpDude] added two operational modes via software. “Pong”, where the String Car keeps going back and forth over the string until it stops of (battery) exhaustion. The other mode is “Boomerang” – a single return trip back and forth.
We are guessing the next upgrade would be to add some kind of radio on the car (ESP8266 perhaps) and build an app to control the String Car. That’s when gaming could become fun as it opens up possibilities. One way to improve performance would be to add two “idler” pulleys in line with the main drive pulley, and then snake the string through the three of them. Now you know what to do with all of those old motors you’ve scavenged from tape drives, CD drives and printers. Let the Games begin!
The 2004 / 2005 models of the Prius had peculiar problems with their MFD. Buttons and touch functions became sluggish and unresponsive, it wouldn’t display ECU data such as current and average fuel consumption, and couldn’t control stereo and air-conditioning. Lots of Prius users were reporting similar problems on the Priuschat forum.
The issues would usually arise long after warranty expired, and replacement units cost a couple of thousand dollars new. Toyota knew what the problem was (PDF link), but their fix involved swapping the defective units out.
[hobbit] managed to get a defective MFD unit from a friend, and because his own Prius still had a working MFD, he was able to carry out comparative tests on both units. The broken unit was generally laggy, and the buttons didn’t beep when pressed. Apparently, the AVCLan, a small data network between various components in the car, wasn’t reaching the MFD reliably. The MFD would send the “beep” command to the audio amplifier and wait for a confirmation that would never arrive. The system hung here until the MFD timed out.
In the end, the cause of the problem was the 60-pin micro connector that interfaces the two main boards of the MFD. Once the two are mated, tightening the mounting screws twisted the two boards ever so slightly, leading to flaky contacts.
The fix? [hobbit] tweaked all of the 60 pins outwards enough that they still made contact even when the connector housing got twisted. Comparing the defective MFD to the one in [hobbit]’s own car also demonstrated how the factory fixed the problem.
Thanks to [Nick] for sending in this tip, which he stumbled upon “while searching for ideas for a very small solder tip to repair something on my laptop.”