Moving on to the list of more advanced sensors, here we go on the Ultrasonic Range Finder.
- Sensor output
- Those wires. Ugh.
- It’s digital?
- A special note about digital Ports 4 & 10
- Considerations for use
- Combining sensor data
The ultrasonic sensor works like a bat’s or dolphin’s echolocation, or a submarine’s sonar [in our lab, we call it “the bat sensor” 🙂 ]. It sends out a sound wave and catches the rebound. Using the amount of time it takes for the sound wave to bounce back, the sensor calculates the distance from itself to the object in front of it.
The ultrasonic sensor has the ability to measure objects between 3cm and 3m away (1.5 inches to ~10 feet). One of the two “eyes” on the front of the sensor sends the signal out, and the other one receives the signal back (see the sensor’s info sheet PDF for the details). The pulse that gets sent out is 250 microseconds long, and it gets sent out on a regular schedule, every 50 milliseconds. By the 50ms mark, the previously-sent sound waves have dissipated enough that they do not risk interfering with the next pulse or measurement. If you’re interested in additional technical details on this component, this is a very helpful blog post, as well as this VEX Forum thread, and this one too.
Ultrasonic Sensor Output
Once you tell your setup that you’re using millimeters/centimeters/inches, the output from the sensor is very straightforward: the value the sensor gives you is the number of mm/cm/in to the object in front. (Note to easyC users: I know that this sensor can report in inches or centimeters, but I am unsure as to where that setting is; be on the lookout for it in your GetSensor or StartSensor blocks. Here is a really great YouTube tutorial on programming the ultrasonic in easyC!)
What about –1? I keep getting –1 when I’m pointing the sensor around the room; what does that mean? A value of –1 means that the object is out of range/too far away. So oftentimes in your programming you’ll want to add the condition “…and sensorValue > 0” to make sure that you’re not including junk data in your calculations or comparisons.
Test Test Test
Before we attached our sensor to our robot last week, we hooked it up to a test cortex. Using the debugger window (online window for easyC users; or sending the value to an LCD screen), we walked around the room with the test setup, pointing the sensor at different objects and comparing the sensor’s value to what we got using a tape measure.
This step will help you calibrate your sensor, understand how straight it has to be pointing at an object to work right, figure out what type of objects work well (or don’t), and double-check that you have a working, non-defective sensor—before you go to the trouble of attaching it to your robot.
Those Wires. Ugh.
Looking at the sensor you’ll see that the 2 wires have labels: “Input” and “Output” (photo, right). Contrary to what a reasonable person might think, the “Input” wire is the one that sends out the pulse signal, and “Output” receives the signal back. Basically, these Input and Output labels are from the sensor’s perspective. The sensor gets instructions in from the cortex to send a pulse via the Input wire; it returns the rebounded signal via the Output wire.
RobotC: Both of these wires get plugged into adjacent cortex Digital ports, with the Input wire in the lower-numbered port and Output wire in the higher-numbered port. In the RobotC “Motors and Sensors” window, you set the sensor to return inches or centimeters; once you tell it where the Input wire is plugged, it will prompt you for where the Output wire is plugged.
easyC: You must plug both wires into digital ports, but it’s not necessary that they be neighboring ports. In the easyC configuration window, you must flip the Input wire’s port direction, so that the teeny arrow is pointing out from the teeny white circle. Here’s a really helpful Ultrasonic Sensor presentation from San Jose State University that I downloaded I-don’t-know-when. The diagrams are for the old, PIC controller, but the necessary steps and setup are basically unchanged. There are specific steps in easyC needed to start the whole ball rolling, and this PDF walks you through them.
Huh? How can this be digital? Doesn’t it return a specific distance to an object? I thought digital just was for 0’s and 1’s.
Yes, it does give you specific distance values, but “digital” really refers to how the cortex talks to the sensor, not the information you ultimately use in your program. In this and other digital sensors, the cortex gives or receives HIGH and LOW values — a.k.a. 1 and 0. When the sensor sends out a pulse, it returns a 1 (HIGH); when the signal comes back, it returns a 0 (LOW). The cortex knows the length of the pulse and the time until return, and—combined with the speed of sound—puts it all together for you in the form of a distance measurement.
A Special Note About Ports 4 & 10
As described in my post on shaft encoders, the cortex has a structural limitation with regard to these 2 ports. Namely, these 2 ports use the same bit of memory, so the information it reads from Port 4 will get overwritten by the information from Port 10 a moment later. Lovely. SO, it’s safest to use only one of these 2 ports at a time. If you must use them both, you can plug, say, a shaft encoder into Port 4 and then Port 10 can be used for a bump sensor/limit switch, pneumatics, or for the Input wire of the ultrasonic sensor. These acceptable options for Port 10 involve different types of data communication with the cortex, and do not present a conflict/overwrite.
Considerations for Use
Since the sensor works by sending out sound and listening for it rebounding, those outgoing sound waves must hit an object that will actually bounce them back TOWARD the sensor, and not off in another direction.
- A great candidate is the field perimeter: nice & flat, with a uniform surface.
- A starstruck cube/pillow, on the other hand, is not a good candidate, since the fabric is not really gonna bounce much sound back to the robot. Same for Starstruck stars—too small and spindly with projections at different distances from the robot.
- A round, smooth surface (like an In The Zone stationary goal tower) is doable, but you need to do some testing to determine how accurately the sensor needs to be pointed at the target to return useful information for your needs. It may or may not be the best sensor for your use.
- A multi-faceted object like an In The Zone cone turns out to work very well. There are enough surfaces and angles on it that some of the sound is pretty much guaranteed to bounce back to the robot.
In autonomous, make sure that the object you’re targeting will likely be in the right place when your robot is pinging it AND nothing is likely to get between you and the target during the 15 seconds.
- In the Toss Up game, large beach balls often got moved around during the auton period. If your robot was trying to measure from the field perimeter, and now Oops! there’s a beach ball in the way, your 15 seconds will have an inglorious ending.
- Alternately, if you’re pinging off of a target cone in In The Zone auton, it’s wise to think about where other robots may be, and how likely it is that they will move your object somewhere else—taking it, or running into it and moving it out of your sensor’s viewable area.
Multiple Sensors on One Robot
You can use more than one ultrasonic sensor on your robot at the same time, for example one facing forward and the other facing to the side (or front/back, left/right, etc.).
As described at the top of this encyclopedic post, if you can remember that far back, I mentioned that the cortex sends out an extremely short ping (250 microseconds) about every 50ms, and spends the rest of the interval listening for the echo. The interval is long enough so that the sound is sufficiently dissipated before the sensor fires again.
The cortex works on the same schedule when you have multiple sensors on your robot, except that instead of pinging sensor A every 50ms, it moves next to sensor B, and 50ms later moves on to sensor C, etc., until you’re back around to sensor A. So every sensor gets the 50ms ping-wait-listen-dissipate cycle, one at a time. So you can rest assured that if you have 2 ultrasonic sensors on the robot, even if they’re pointing in the same direction, they are each on their own non-overlapping schedules. (It is conceivable that an ultrasonic on someone else’s robot could interfere with your measurements, but that’s a low-probability item completely out of your control, so I wouldn’t lose sleep over it.)
A side effect of this setup is that the more sensors you have, the less often each one gets a turn. Since these time intervals are very short to start with (50ms), you probably wouldn’t notice any difference if you had 1 sensor or 2 sensors on the robot. I can’t say what would happen if you had, say, 5 of these on your robot (taking up every port on the cortex!).
A common use for this sensor is programming autonomous movements. You could write code that says, “drive forward until the sensor reads 4 inches (or less).” If you’re pointed at an In The Zone cone, you could tell the robot to stop when it’s xx inches away from the cone—the perfect distance for your robot to grab it.
You can also use the sensor in driver-control mode, and have it, say, reduce the speed of the robot automatically as it approaches the field perimeter.
The Laws of Physics Apply to You
Whether you’re in driver control or autonomous, be aware that the laws of physics still apply. When you tell the robot to stop when it reaches the xx-inch mark, the motors will turn off on cue, but the robot will continue forward for some extra amount of time from its own inertia. You’ll need to do some real-world testing to see what role inertia plays for your robot. The inertia problem can be solved by “putting on the brakes” when the robot reaches its target, or using a PID algorithm to slow down as it approaches, reducing the likelihood of overshooting.
Pre-Autonomous / Initialize
The reason my team started using this sensor on our In The Zone robot is for lining up the robot before the match even starts. In the pre-autonomous section of the code (RobotC; the initialize tab for easyC users), we added a few lines of code to say, “While the robot is disabled, put the ultrasonic sensor value to the LCD screen.” (The “if the robot is disabled” part is critical; otherwise it will never break out of the while loop when autonomous starts.)
Combining Sensor Data
If you’ve gotten as far as using an ultrasonic sensor on your robot, you’ve probably got some other sensors on there as well. Here’s the perfect opportunity to use information from multiple sensors to accomplish one task.
For example: In this year’s game (In The Zone), many robots will drive forward and place their preload cone on the stationary goal/tower nearest their starting bar. Using an ultrasonic sensor combined with shaft encoders will help you drive right to your target.
- Use the encoders (combined with some programming referred to as a PID algorithm) to make your robot drive truly straight ahead.
- Place the ultrasonic sensor on the front or back of your robot and use it to decide when the robot should stop its movement, measuring distance to the tower or distance from the field perimeter, respectively.
With this setup, you’ve got one set of sensors keeping the robot moving straight, and the other telling it when to stop. Using sensors in this way can offer more sensitivity and reliability in the robot’s movement compared to the more basic command of driving for ##milliseconds, with all motors running at the same power level.
♦ ♦ ♦
So, 30 bucks for this sensor is non-trivial, particularly if you’re an organization with multiple robots. Plus, it doesn’t hurt to have a spare at a tournament if this is a vital component of your robot’s functionality—so make that 60 bucks. I hope that this post has helped you understand more about how this sensor works and how it’s used (or not), and helps in your purchasing decision-making process. Our team thinks this is a pretty nifty item.
Additional Posts on VEX Sensors
- Introduction to VEX sensors
- Bumper & limit switches
- Optical / quadrature shaft encoders
- Line tracker
- Light sensor
- Gyro (a.k.a. Yaw sensor)
- LCD screen – for use with any sensor
- Jumper clips & LED indicators
- Added 5/20/18: Filtering sensor data – to handle noise in sensor output