[Dave] wanted to make an Arduino robot out of a remote-control 1950 Mercury. He removed the RC portion from the car and kept the drive and steering motors. The idea was to use three ultrasonic rangefinders in the grille real estate and move the car forward based on the longest distance detected.
He initially used a Seeed motor controller and some Grove cables soldered to his sensors to power the steering. It went forward, but only forward, and [Dave] decided the motor controller and the car’s steering motor weren’t playing well together.
[Dave] had the idea to use relays instead to both power the motor and determine polarity. Now, the Merc was turning and avoid obstacles about half the time, but it was also getting dinged up from hitting walls. He figured out that his sensor arrangement was making the car turn immediately and decided to give the program information from the wheels with a reed switch and a rare earth magnet. The only problem is that the caliber of magnet required to trip the reed switch is too heavy and strong. [Dave] and has concluded that he simply can’t exercise the kind of control over the car that he needs. and will build his own robot chassis.
Update: Check out a video of [Dave]’s car after the break.
Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.
Just get yourself a smaller reed switch… Or a Hall sensor, goddammit =)
Or an optical sensor.
Just use a smaller reed switch. or a hall sensor =) There certainly is a way how this can be finished using the original enclosure, so I guess Dave can try again.
Yeah, I have used a hall sensor for similar purpose.
http://essentialscrap.com/toycar/drive-orings.jpg Hall sensor on the glued pcb on the left, magnet in the axis inside black heat shrink tubing. Though.. that sensor pcb eventually fell off due to bad gluing :)
Isn’t it possible that the ultrasonic waves from one sensor will be picked up by the others based on the closeness of the sensors, thereby mixing signals?
I wonder if the builder is cycling the sensors so instead of constant feedback he’s getting pulsed feedback and storing the values. You’re certainly right, unless he’s using different frequencies the sender/sensor relationship could be at play.
I think cycling the signals would have help solved all of his problems. All he would of have to do is set it to keep the forward sensor active till it reaches a specific threshold. Once it does (indicating it’s about to hit something), it would activate of the other two sensors while silencing the forward one to check for a direction to turn. This way, only one of them is active and there is no collision of data (or the car for that matter).
Actually, it would have solved the most pressing of his problems.
Try an L293D or SN754410 chip (quad half-H bridge, i.e. dual H-bridge)? Surely more responsive than relays! An AdaFruit Trinket or Trinket Pro, or SparkFun Arduino Pro Mini might fit in there nicely with the L293D. You probably need to choke back the speed of those motors via code because it’s likely they’re geared for speed.
A lot of toy R/C cars are geared for high speed, for “excitement” and racing, but are actually underpowered for their design speed and therefore steer and accelerate poorly. I had a similar experience trying to convert a large R/C donor toy car some time back and, like the OP, eventually gave up on it and built a custom differentially steered chassis.
This is what I came to realize, which is why I’m building my own chassis. It was fun struggling with this, though.
This is great. I was probably about 14 or 16 when I built my first nonworking Robot.
Excellent work trying to get it working, trying some different things, and giving up and moving on when you’ve decided it’s not going to work.
Thanks for posting it.
Don’t stop doing projects just because you’ve failed in the past.
As someone once said “Anything worth doing is worth doing badly at first.”
(Also, “If at first you don’t succeed, be thankful you’re not skydiving.”)
1) The motor controller didn’t work with the steering motor, but WHY not? I wouldn’t be satisfied until I knew the reason behind it, or at least had a hypothesis.
2) While the “oversteering” issue isn’t clearly described, it sounds like it’s turning sideways into walls. Maybe because given the angle of the sensors, when the car is driving parallel to the wall, the ultrasonic pulse may strike the wall at such an angle that it isn’t reflected back to the sensor. Or perhaps the sensor’s minimum detection range is being exceeded. It’s at this point that sensor function should have been verified by adding some human-readable feedback method, like LEDs. If it’s wrongly assumed that the sensors are working when they’re actually not, then the problem hasn’t been correctly identified. And trying to patch over a misunderstood problem by adding complexity, like wheel odometry, likely won’t work.
3) The odometry would have worked on this car by using a hall effect sensor, rather than a reed switch, as others have stated. Instead of looking into the issue and discovering this solution, he’s decided to abandon the RC car and build his own body. Which will let him attach the massive magnets to the wheels he thinks he needs. It’s probably a better choice for other, legitimate reasons, but the complexity of this project may be growing faster than his problem-solving skills.
Seems like an overarching issue is that [Dave] is a bit impatient. Too ready to change to a different approach when a problem presents itself, rather than solving/understanding the problem, and therefore missing opportunities to learn.
Man, what a downer. Opened the Hackday. tab, scrolled down and seen the Merc. I was far out a custom car build was featured. Then I noticed fail after that I noted is was RC model, still a custom I suppose, but not what I was hoping for.