Ultrasonic Sensor Programming

[DavidGitz]

I'm reading through the LabVIEW Programming Guide for FRC, and I have a question about the Ultrasonic VI.

In the Open.vi description, it specifies to connect the Ping Channel and the Echo Channel correspondingly to the Ultrasonic sensor. My question is, if we use a sensor (such as the parallax ultrasonic) that has the ping and echo on one line, do we just connect that line to the ping and echo lines on the cRIO? Or do we put something between the wires, like bridging 2 zener's or something. Thanks!

BTW, the Manual looks great so far! Good Work!

[Joe Hershberger]

We haven't tested with that particular sensor yet. We intend to in the near future and will be able to answer this question more directly then. The current library support in C++ and LabVIEW will not work for this sensor. Perhaps if you use a transistor to drive the echo line controlled by the ping line, it would be close.

For now, I can tell you that if you want to use it as parallax intended, that requires changing the line direction on the digital module for each ping. Doing this has some side effects, that I can explain if you you are interested. We will try supporting it, but other sensors (that don't require switching line direction) will work much better on the current system.

[jmittelman]

Joe,

what about Maxbotix sensors?

http://www.maxbotix.com/MaxbotixHome.html

There are several options for reading values, including analog, digital and PWM, although analog is the easiest to use.

Will these be supported, and if not, how would we go about writing a driver vi for them?

[DavidGitz]

For now, I can tell you that if you want to use it as parallax intended, that requires changing the line direction on the digital module for each ping. Doing this has some side effects, that I can explain if you you are interested.

Sure Joe, please do

[jross]

what about Maxbotix sensors?

http://www.maxbotix.com/MaxbotixHome.html

There are several options for reading values, including analog, digital and PWM, although analog is the easiest to use.

Will these be supported, and if not, how would we go about writing a driver vi for them?

It should be trivial to read the analog signal it with the analog channel library. It shouldn't be too hard to use the counter library for the PWM in f-ree run mode. I think it might even work directly with the ultrasonic library.

[DavidGitz]

The problem with the Parallax ultrasonic sensor is that the output line and the input line are going to the same pin on the sensor. This requires that the signal line have the following properties:

When it's being read: Values of 1 or 0
When it's being transmitted to: Set to high impedance

The first step to implement are (as far as i know) is standard:

Hook up the Sensor line to a Digital Output and to a Digital Input to the control unit.

There are a few different ways for what goes next, I'll detail what I'm familiar with.

Implement in software directly:
When transmitting to the sensor, ignore the value being read from the input line. When receiving from the sensor, (somehow) don't control the line at all with the digital output line. For a PIC, this is done by (I believe) changing the same pin to a digital output to a digital input repeatedly, although I don't know how you would do this on the cRIO.

I've heard of this being done before using a crossed zener diode arrangement but don't exactly remember.

And Joe was right before, there is a way to implement this with a transistor arrangement but I'm not sure of the exact method.

Finally, I think it would be possible to just use a tri-state buffer as well.

Anybody come up with a good solution yet?

[Tim1681]

Why not just wire the SIGNAL pin on the Parallax PING sensor to two pins on the 9403? Set one pin as an OUTPUT for your TRIGGER and the other as your INPUT for your input pulse. Then you can program the second pin on the 9403 to either ignore the TRIGGER pulse, or use it as the basis for its measurement.

[Marshal Horn]

I asked about this at the "Labview Basics" class at the FIRSTWa preseason kickoff. They said you can actually flip an input to an output (and back), assuming it IS a bidirectional module. (I'm pretty sure ours are, considering the digital breakout board contains both inputs and outputs). I checked the datasheet, and there's a couple nanoseconds of delay. The problem would come in in the FIRST side of things. I don't believe the GPIO will allow an input to be flipped to output and back, and I'b doubting FIRST will allow us to do it.

In other words, your best bet is probably to use diodes and a small FET to cut off the output when it is false. I can draft out an electronic diagram if you would like.
IF you don't know what FETs are, I have a lovely short essay on it at http://sotabot.com/Contributors/marshal.html, near the bottom of the page.

[DavidGitz]

Just curious, but why do you think FIRST wouldn't allow this?

[Marshal Horn]

My mistake, I somehow thought the digital outputs weren't straight-through. You can do it just fine, but you have to use a digital input as an output; you can't use a relay out put as an input.

The only reason I didn't think FIRST would allow it is because they are very wary about teams not using their provided electrical/electronic systems.