A 3 pin Ultrasonic rangefinder

[Mr.R_2]

Hello,
I have begun working on my summer projects early. Most of them involve creating practice bot ideas for training new members. For the past few years, our team has collected hobby kits to help teach programming, but it has not always worked out too well.

Long story short, we have the PiCar-s and the VMX-Pi. I got the car working (even wrote a small class for the steering yoke; it works well). However, the ultrasonic sensor is a mystery to me. It seems like a digital TOF sensor (even though they repeatedly call it analog in the documentation). Yet there is only one cable. The sensor is a max220-49 ds-2. In the Arduino and Raspberry Pi code, they use the same pin as both an input and an output. Is this possible in the FRC world? Does a counter send a pulse, or a PWM receive one? Sorry if this thread is misplaced. I am ultimately programming in Java.

I saw someone posted a similar question a few years ago with no response. I am wondering if anyone has any thoughts.

If this is not possible, that is okay. I just wanted to know before a spent much more time on it (I thought it would be simple).

Here is the Arduino Snippet (I know, it is C++, not Java).

//set SIG as OUTPUT,start to output trigger signal to the module to start the ranging
  pinMode(SIG, OUTPUT);
  //Genarate a pulse 20uS pulse
  digitalWrite(SIG, HIGH);
  delayMicroseconds(20);
  digitalWrite(SIG, LOW);
  //set SIG as INPUT,start to read value from the module
  pinMode(SIG, INPUT);
  rxTime = pulseIn(SIG, HIGH);//waits for the pin SIG to go HIGH, starts timing, then waits for the pin to go LOW and stops timing
  //  Serial.print("rxTime:");
  //  Serial.println(rxTime);
  distance = (float)rxTime * 34 / 2000.0; //convert the time to distance

[nuttle]

Have you found https://docs.wpilib.org/en/latest/docs/hardware/sensors/ultrasonics-hardware.html and/or https://docs.wpilib.org/en/latest/docs/software/sensors/ultrasonics-software.html#ultrasonics-software?

Based on the code, this is a “Ping-response ultrasonic”, but the link you included isn’t to an ultrasonic part…

A picture and more detailed description would be helpful – three wires, just to confirm?

[I originally missed one of the links you provided, looking…]

[nuttle]

This is going to connect to a digital I/O port on the RIO (see https://docs.wpilib.org/en/latest/docs/hardware/sensors/digital-inputs-hardware.html):

Sensor Pin – RIO Pin
GND – ⏚
5V – V
SIG – S
NSE – do not connect this pin

For the code, see https://first.wpi.edu/FRC/roborio/release/docs/java/edu/wpi/first/wpilibj/Ultrasonic.html.

Based on this answer, you may need to use up two digital I/O ports.

[Mr.R_2]

Thank you. It was the Y connector I did not think of. It seems exactly like the parallax on the other thread. I was stuck with the one cable and not being able to choose between the input and output. The Y connector solves that problem.

[nuttle]

If that part gives you trouble, you should be able to get one with a different interface pretty quickly, even these days. Depending on the application, there are some really nice time-of-flight laser range finders available for reasonable prices anymore – see https://www.digikey.com/en/articles/simplifying-time-of-flight-distance-measurements. This might be a better technology for FRC. Here’s a part that’s packaged up for easy use: http://www.revrobotics.com/rev-31-1505/.

This part also looks like a great fit.

[Mr.R_2]

Thanks. Those are good options. We actually have a Rev one in the shop. I was thinking we would switch to LIDAR later. The whole point of this project is we have some of these devices, but every build season they become afterthoughts and then we run out of time. The goal is to develop kits so some of the programmers can work on implementing these while the mechanical has the base. So, I am working on developing curriculum so they can learn more independently.

I thought the challenge of implenting the kit as is would be a good one. Yet, I am quickly finding though the troubleshooting teaches me a lot about programming, there is a reason most of the FRC vendors’ products work so well.

[nuttle]

Makes sense.

The programmers can look at the code in Wpilib (https://github.com/wpilibsuite/allwpilib) and figure out if things will work with a single digital I/O. I think the code in question is here, but I didn’t spend more than a few seconds looking. If so, it’s not set up for this, nor structured to make this a super easy change. So, the Y cable is probably the way to go. If you have a scope, using it to watch between signal and ground may be interesting, in the event things don’t just work (or even just to see).

If you have a extra RIO, it’s useful to set up a bench system for electrical and programming to be able to do more in parallel with mechanical. It can also be useful for controlling prototypes. But off-season it the time to build capability for sure.

[nuttle]

The problem with the Y cable is that you are essentially putting two outputs and one input at the three ends of the Y – the digital output and input are two of these, and the sensor acts as both input and output. You can have one output and multiple inputs, but things get more complicated when it’s the other way around.

Changing the code to use a single digital I/O solves this, but the sensor and the digital I/O will both act as inputs and outputs, so it’s still possible they will both be outputs at the same time. So, you kind of have to understand the electrical characteristics as well as the timing either way you go.

The datasheet for the sensor isn’t great, it lacks detail. It just says:

Trigger Input Signal: 10uS TTL pulse
Echo Output Signal: Input TTL lever signal and the range in proportion

The sample code makes it clear input and output are both digital, 5V. I suspect the sensor keeps it’s side of signal as an input, waiting for an input pulse to trigger it. Then, it briefly drives the signal as an output some time after, depending on how long the sound takes to return. One way this can be made to work is to have a resistor pull the signal either high or low, and then either device can drive the pin to the other value. This way, the two outputs do not fight each other (one high, the other low). However, connecting a RIO digital output isn’t going to work this way, at least not without a little extra circuitry (or different code) – the specifics of which depend on the exact specifications.

In other words, the normal scheme to pull this off is to set things up so neither output ever actively drives a high voltage, but to use a resistor to establish a high voltage when neither output is actively driving a low voltage. Then, if either output does drive a low voltage, the resistor will be overcome and the voltage will go low. If both outputs drive a low voltage, they are not trying to do the opposite thing, and it’s OK – the voltage will go low. By directly connecting a digital output, it will actively drive either a high or low voltage at all times, and you have the situation where two outputs are trying to drive opposite voltages at the same time. This probably won’t work.

The lesson here is that one has to interface electrically and in software, and the datasheet normally has the information on how to do this. So, one has to be able to read these. You can pick from many parts that sound similar in the descriptions, but that interface differently. The sensor performance characteristics are another area where things can be very different: think range, accuracy, etc.

There are three options here:

1. Modify the software for “Ultrasonic” (or write new, lower-level code) to use a single digital I/O as both input and output – there is a built-in resistor and things will probably work (without the Y cable on the wiring side of things);

2. Construct a more elaborate circuit to connect the signal part of things, instead of just the Y cable – I can try to find an example based on some guesses and will do another reply;

3. Find a different sensor which is compatible with the existing software – a four pin one that will connect slightly differently (pick one that’s listed in the Wpilib comments, it’s likely to be a good fit for FRC in terms of range/accuracy/price).

[Mr.R_2]

Thank you. Last night I got a readout from the sensor using a breadboard as a Y cable. The scale is a bit confusing ~ (4.5 x10^8) for the ultrasonic.getDistanceInches(). I think if I cannot get it working I will just use a different sensor as you suggested.
I got the VMX-Pi for precisely the reason of setting up a test base. It works so well and is half the price of a Rio. It runs the WPILib HAL. The io is mapped a little differently, but it is still incredibly nice. It is powered by a Raspberry Pi so the bootloader is safer than a rio as far as experimentation goes.

Our programmers are not ready to independently interpret the API, but they are getting there. I think this project is going to help get them most of the way there.
Thanks again for your help.

[nuttle]

The page on RIO digital I/O ports says:

All DIO ports have built in “pull-up” resistors between the power pins and the signal pins - these ensure that when the signal pin is “floating” (i.e. is not connected to any circuit), they consistently remain in a “high” state.

The objective for option 2) above is to have what’s known as an “open collector” output, as opposed to a normal one. So, if you want to have a little project on the electrical side, you can build a simple circuit to do this. This is what the reference to adding a transistor was alluding to in that other discussion thread.

Sounds as though you are making good use of the off season – good luck!