[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.”
A lot of technological milestones were reached in 2007. The first iPhone, for example, was released that January, and New Horizons passed Jupiter later on that year. But even with all of these amazing achievements, Volvo still wasn’t putting auxiliary inputs on the stereo systems in their cars. They did have antiquated ports in their head units though, and [Kalle] went about engineering this connector to accommodate an auxiliary input.
The connector in question is an 8-pin DIN in the back, which in the days of yore (almost eight years ago) would have been used for a CD changer. Since CDs are old news now, [Kalle] made use of this feature for the hack. The first hurdle was that the CD changer isn’t selectable from the menu unless the head unit confirms that there’s something there. [Kalle] used an Arduino Nano to fool the head unit by simulating the protocol that the CD changer would have used. From there, the left and right audio pins on the same connector were used to connect the auxiliary cable.
If you have a nearly-antique Volvo like [Kalle] that doesn’t have an aux input and you want to try something like this, the source code for the Arduino is available on the project page. Of course, if you don’t have a Volvo, there are many other ways to go about hacking an auxiliary input into various other devices, like an 80s boombox or the ribbon cable on a regular CD player. Things don’t always go smoothly, though, so there are a few nonstandard options as well.
When you have an idea, just go build it. That’s the approach that [GordsGarage] takes with most of his projects, and he’s back in the machine shop again. This time it’s with a rather unique oil candle that uses a spark plug as inspiration. We have to say, the results are on fire.
The spark plug candle was fashioned out of a single piece of 6061 aluminum. To create the scale model, first the stock metal hit the lathe to create the “insulator” section of the plug. From there, he milled in the hex bolt section, then it hit the lathe again to create the threaded section. The inside was bored out to create space for the wick and oil, and then the electrode was installed just above the flame.
This is a pretty impressive scale model and has a great finished look. The only thing that isn’t to scale is the gap for the electrode which is completely necessary to keep the candle from getting smothered. It’s an interesting, unique idea too, which is something that [GordsGarage] excels at. And, if you want to scale his model up a little bit, perhaps you can find some inspiration from this other candle.
A big problem with most modern cars is the sheer number of parts and systems that are not user serviceable. This is a big departure from cars of just decades ago that were designed to be easily worked on by the owner. To that end, [Anthony] aka [fuzzymonkey] has tackled what is normally the hardest thing to work on in modern cars: the Engine Control Unit. (Older posts on this project can be found at [Anthony]’s old project log.)
Every sensor in any modern car is monitored by a computer called the Engine Control Unit (ECU), and the computer is responsible for taking this data and making decisions on how the car should be running. In theory a custom ECU would be able to change any behavior of the car, but in practice this is extremely difficult due to the sheer number of operations required by the computer and the very specific tolerances of a modern engine.
The custom ECU that Anthony has created for his Mazda MX-5 (a Miata for those in North America) is based on the PIC18F46K80 microcontroller, and there are actually two units involved. The first handles time-sensitive operations like monitoring the engine cam position and engine timing, and the other generates a clock signal for the main unit and also monitors things like cooling temperature and controlling idle speed. The two units communicate over SPI.
[Anthony]’s custom ECU is exceptional in that he’s gotten his car running pretty well. There are some kinks, but hopefully he’ll have a product that’s better than the factory ECU by allowing him to change anything from throttle response and engine timing to the air-fuel ratio. There have been a few other attempts to tame the ECU beast in the past, but so far there isn’t much out there.