Automatic braking on RC car
IlidanxD
Posts: 7
Hello! I'm working in my final school project, the idea is to make an RC car stop automatically when there's an obstacle in front of it, even if someone is still speeding up. For this, I'm using a ping sensor to detect the objects and the propeller chip to decide when stop the vehicle.
My problem is, since I connected the car's circuit to the propeller, the car have ceased moving, I'm sure it's a software problem but I don't know how to fix it, can you tell me if there's something wrong in my code? or another way to code this?
here is my code, and the code I use to control the ping sensor
Ping.spin S.P.A.T beta.spin
Thanks in advance, and sorry for my bad English.
My problem is, since I connected the car's circuit to the propeller, the car have ceased moving, I'm sure it's a software problem but I don't know how to fix it, can you tell me if there's something wrong in my code? or another way to code this?
here is my code, and the code I use to control the ping sensor
Ping.spin S.P.A.T beta.spin
Thanks in advance, and sorry for my bad English.
Comments
dont tell the car to go forward for 3 seconds then send a command to stop the car, tell the car to go forward 0.2 seconds, and forward for 0.2 seconds. Stop sending the command to go forward for 0.2 seconds when you want it to stop... and hazza! it stops.
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." -Einstein
How are the motors controlled? What's connected to "MTAD_Pin"? Is it some sort of H-bridge?
Here is a full-featured DIY H-bridge that claims to have braking. It works even better if you electric motor is geared.
http://www.solarbotics.net/library/circuits/driver_robinson.html
1) break one motor connection to the existing H-bridge circuit, and
2) connect that same motor connection to the other motor connection
That is, when the relay is activated by your sensor, the two motor leads are disconnected from the controller and shorted together to achieve dynamic braking. That will stop the car in a hurry until the object is removed. Kind of a pain, though, since the car is stuck, you can't back up either. You could get tricky and add a diode so that the relay drops out when reverse is applied so you can back away after stopping.
There are numerous ways to put the brakes on, but your bigger problem is sensing the obstacle reliably. Sonar/ultrasonic won't work reliably above a certain airspeed (motion and wind will affect), and your car will have a minimum braking distance, so I suspect you will spend some time limiting its top speed so as to not overdrive the car into an obstacle. Likely on the slow side, given the limits of sensor function, detection reliabilty, and vehicle stopping ability.
well the problem I mentioned is solved, I realized that the backwards ping was not correctly connected :blank:, and the car was moving just when the ping detect something, I mean if there was nothing in 3 m. the wasn't moving, I fixed that in the program, changing the case statement "16..300: outa[MTAD_Pin] := 1" for "other : outa[MTAD_Pin] := 1" but now my problem is the speed, as closer is the object as faster goes the car, and when the object is close enough, the motor stops but the inertia makes the car crash any way. If I want to make the speed stable do I have to use pwm?
If it isn't obvious, you're going way too fast for your sensors. Slow down. WAY down.
Are you braking to stop, or just removing power and coasting into the crash?
Yes, disconnect them from the power first. That's why I suggested a SPDT relay earlier.
http://www.youtube.com/watch?v=hGQEzz8CNIQ
and
http://www.youtube.com/watch?v=zFkJ29xuRFY (no braking)
http://www.youtube.com/watch?v=1EKlAOUXZ8U (with braking)
erco, have you observed problems with ultrasound sensors in windy environments?
When I played around with a Ping, one of the things I tried was to blow hot air from a heat gun at various angles in front of the sensor. I never observed any problems during these short tests. I haven't tried having the sensor move instead of using blowing air, but from my experience I don't see the vehicle speed (of RC cars) being a issue with the Ping.
Parallax's Laser Range Finder has a pretty slow refresh rate and doesn't work well outside in bright sunlight.
I agree about going slow enough to have time to stop but I'm not sure if switching to a LRF would help much.
I'm gonna go out on a limb here and throw out a number like 1 foot per second might be a reasonable speed to expect a single PING to function properly to detect large objects and walls and give a car/robot time to stop. Even 2 ft/sec may be possible with lots of chassis and sensor tweaking, but the 10 ft/sec speeds that even inexpensive cars can hit are "right out".
OK, the race is on. Who will be first to post results or find a Youtube video which proves erco doesn't know stuff from Shinola?
Well I made some changes in my code that solve most of my problems and I want to share it with you.
Thank you very much for your help :cool:.
S.P.A.T beta 2.spin
No one bit, so I'll have to take myself down with this nifty page on robotic vehicles that navigate around a room using ultrasonics. Looks to be somewhere in the ballpark of my predicted 2-3 ft/sec speed. Check the two videos, pretty cool stuff!
http://letsmakerobots.com/node/696#robot_em_video
None of my bots travel 10 ft/sec. I started making a Lego vehicle to add an ultrasound to but I've just got too much other stuff going on to spend much time on it.
An ultrasound echo from a forward facing sensor will return to the sensor a little sooner (<2%) than from a stationary vehicle. The frequency would also shift a little bit, but I don't think 10 ft/s is enough to cause the sensor trouble. A side facing sensor might have trouble since the robot might not be in the right place to detect the echo.
Since I'm working on quadcopter stuff right now, I might use one to test ultrasound sensors a higher speeds. I don't think a quadcopter will have trouble flying 10 ft/s.
I think we need some sort of wager to make this more interesting.
Sorry IllidanxD for hijacking the thread (but it's mostly erco's fault).
Welcome to Tangent City! AFAIK, all the propwash/downdraft/swirling eddies under a quadcopter is REALLY looking for a bloody nose using ultrasonic sensors calibrated for still air!
Propwash? Hogwash!
I blasted my Ping with both room temperature air and hot air from my heatgun while using the Ping to take measurements. The Ping didn't give a hoot about having air blow at it or across it. I will admit there was only a few inches of moving air the ultrasound waves had to pass through but the air was moving pretty fast. I don't think 10 ft/s movement nor propwash is going to present a significant problem for ultrasound sensors.
My little $100 HobbyKing quadcopter could lift a couple of ultrasound sensors, so I'll be testing this out relatively soon. I'll also add some ultrasound sensors to my new Elev-8 once I get it built. I'll post my results in a new thread before this one ends up in Cuba.
The Force is strong with this one! Duane, I love good strong convictions and a firm challenge. My past learnings include PhiPi making a believer out of me in encoders for differential drive to go straight, then I got fiesty and dug in when someone said a BS2 couldn't track a quad encoder at high speed. You have empirical tests, I only have accumulated the comments of the forumistas. Perhaps there's more to your passionate claims than meets the eye!
I find strong convictions also give crow a much stronger taste whenever I have to eat it.
I recently learned the board that comes with the Elev-8 can use ultrasound to aid in it's altitude control.
I'm adding connectors for ultrasound to my Propeller powered quadcopter daughter board to use with my $100 quadcopter right now. The original purpose of the Prop board was to control some LEDs. Now it will also monitor some ultrasound sensors. I'll probably use the LEDs (RGB) to display altitude and distance information.
Are we in Cuba yet?
A funny thing happened on our way to Chaco Canyon: Cuba, New Mexico! I just happened to have a T-shirt from my Cuban buddy's restaurant.