Ultrasonics+RobotC: looking for their inner secrets

I’m trying to gain a better understanding of how the ultrasound sensor works, especially with RobotC.

Elsewhere on the forum, I have seen statements that suggest that the ultrasound sensor only “pings” when RobotC encounters a statement such as
** if (SensorValue[ultrasonic] > 0)**.

But I’ve been wondering what really goes on between the code, the Cortex, and the ultrasound sensor. For example, does the ultrasound merely “ping” once, emitting merely a single pulse of sound, and from that single solitary pulse determine distance? Or does it emit, say, 10 pulses in a row and then take some sort of average before reporting back to RobotC with an answer to SensorValue[ultrasonic]?

Or does the ultrasound continuously “ping” on its own, and only when RobotC requests some data does SensorValue[ultrasonic] get set to the most updated value?

I have a number of reasons for asking. First, I’ve been wondering if the ultrasound might give better data if multiple readings are averaged out in RobotC. Second, I’m trying to determine the probability than numerous ultrasounds used on a single robot (or multiple robots on the field) might interfere with each other and give false readings.

I have seen postings on the forum that suggest ultrasound sensors might be enabled and read one at a time, so if multiple sensors are used on a single robot, then interference is not a problem. But what if there are other robots on the field whose sensors are pinging continuously? Are the timing intervals so tight that acoustic interference is not a problem?

The ultrasonic sensor is constantly “pinging”, see this post for some details.


Multiple sensors on a single robot will not interfere with each other, they are used sequentially so more sensors will have a slower update rate. Sensors on other robots could potentially interfere.

1 Like

Okay, please correct me if I’m interpreting this wrongly. Once an ultrasonic sensor is started by a RobotC program, that ultrasonic sensor is forever “continuously” pinging. But if more than one ultrasound is being used by a RobotC program, then those multiple ultrasonic sensors are commanded to take their turns “continuously” pinging so they don’t confuse each other with their echoes. So some sort of background function of RobotC or some other sort of background system inside the Cortex is making all the ultrasounds take their turns. However, once an ultrasound is started in a RobotC program, you can not command an ultrasound to stop pinging inside a RobotC program. Does that summarize it correctly?

Thanks. :slight_smile:


Yes, the ROBOTC executive and interrupts handle the ultrasonic sensors.

You can stop the ultrasonic by setting the sensor type to “sensorNone”, I don’t see why you would want to though, the overhead is minimal. Some demo code to show how to do that.

#pragma config(Sensor, dgtl1,  sonar1,         sensorSONAR_cm)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

task main()
        // Turn off sonar
        if( vexRT Btn8U ] == 1 )
            SensorType dgtl1 ] = sensorNone;
            while( vexRT Btn8U ] == 1 )
        // Turn on sonar
        if( vexRT Btn8D ] == 1 )
            SensorType dgtl1 ] = sensorSONAR_TwoPins_cm;
            while( vexRT Btn8D ] == 1 )

Wow! Much appreciated. I never feel comfortable teaching about something until I know a little bit more about what’s going on under the hood. Thanks so much!


And if you follow those links, you can see the beam pattern is pretty tight, so nearly perpendicular to the wall is best.

We had a robot in 2011 that had a front and side ultrasonic and it worked realtively well.

From that beam pattern graph, using the ultrasonic in conjuntion with a gyro is probably a good idea. The “trust” you have in the ultrasonic reading may be as good as the facing of a good clean path to a wall within those degrees. Buckeys rolling to weird palces got in the way this year in autonomous as is being in the middle of a turn where being off more than 30 degrees can get hairy.

Also the dreaded -1 readings when you are too close or the signals bounce funny. One of our teams tried to used this to ther advantage for detecting the tall goal as when they turned just right it consistently went to a -1 sicne there was no path back for the signals.

Have fun with it!

Thanks! We’ll try! :slight_smile: