SONAR Sensor Software Driver

[Roger]

More specifically, to flesh out my teammates questions, we're using the vex sonar in our FRC robot, which has two pwm type plugs labeled INPUT and OUTPUT. We're not quite sure which locations these two wires should be plugged in at the controller, which the above sonar code is expecting.

emersont49: Are you talking about the ones that were on the old Polaroid cameras, or whatever developed from that? I don't think they are the same.

We have a couple of the Vex Ultrasonic Range Finder kits (http://www.vexlabs.com/vex-robotics-...nder-kit.shtml), which I believe are similar to the ones from Parallax.com (http://www.parallax.com/detail.asp?product_id=28015).

Qbranch: The sonar code's seem to be rather simple programming-wise, with help from the readme file. Call one routine to start the action, then call another routine to get the distance.

Our problem is where to plug the wires in. Or are we doing the code wrong? Or, like Tom Bottiglieri suggests (and I vaguely remember something of the sort, but hoping it wasn't true), it doesn't work with Kevin's PWM driver. There are too many unknowns, hardware and software, and it looks like we've got some grunt work ahead of us, and some hours with interrupts.

Too bad we can't plug the vex ultrasonic unit into the vex controller, then connect that to the FRC controller. Might be an easier path to take --- ?

I think there's been lots of activity since I last visited this thread, and suggestions. Thanks to all. And, not to beat a dead horse, but has anybody got *any* ultrasonic to work on FRC?

[Qbranch]

Originally Posted by Roger

Qbranch: The sonar code's seem to be rather simple programming-wise, with help from the readme file. Call one routine to start the action, then call another routine to get the distance.

...

I think there's been lots of activity since I last visited this thread, and suggestions. Thanks to all. And, not to beat a dead horse, but has anybody got *any* ultrasonic to work on FRC?

Roger, I had a different method of timing for the Sonar than this driver uses, hence why mine was a little more complicated. I was using a CCP module in input capture mode to do cycle (nanosecond) precise timing. But, yes, you essentially get the same result, except i was reading out in tenths (of an inch) on a stationary robot and fairly stable 50 thousandths increments on an overhead cart.

To answer your other question... we sure did get an ultrasonic sensor to work. Our team as an offseason project finished a fully ultrasonic autonomous mode that worked flawlessly (and finished juuuuuust under 15 seconds ). Now, it did take a TON of data processing (band-pass filtering, trend/slope aquisition, line reconstruction, and curve fitting to be specific) which is part of why about 1 whole second is used just calculating after a scan is taken (we mounted our ultrasonic sensor on an airplane servo). We did use a PING))) sensor from Parallax. If you want more info just post.

-q

[MikeDubreuil]

Originally Posted by Roger

we're using the vex sonar in our FRC robot, which has two pwm type plugs labeled INPUT and OUTPUT. We're not quite sure which locations these two wires should be plugged in at the controller, which the above sonar code is expecting.

When I wrote this software for my capstone project in college it was using the Vex sensor. I chose the Vex sensor because of it's protective case. Wiring the Vex sensor to an FRC controller requires some simple electrical work. In the software SONAR_OUTPUT, is actually the control input to the Vex sonar device. The output of the rangefinder is connected to an interrupt capable digital i/o pin on the FRC controller.

Vex Rangefinder Input Cable
Red = +5V
Black = GND
Yellow = Control = SONAR_OUTPUT (rc dig i/o 16) = Driving this high causes the SONAR to send echo

Vex Rangefinder Output Cable
Red = +5V
Black = GND
Orage = Signal = Hardware_Interrupt_Sonar() = Interupt 1 (software needs interrupt 1)

[B_Dubbs]

Hi team 1153 posting. I would just like to extend a gracious thank you to everyone who helped, as we got our sonar up and running tonight. Now onto new problems. Our Sonar is giving us data in spurts so our Displays look like
Distance = 5
Distance = 0
Distance = 5
Distance = 0
Distance = 5
Distance = 0
Distance = 5
Distance = 0
Distance = 5
Distance = 0
etc.
Does anyone know why t has these jumps to zero? We followed through the code that it seems to be coming from Timer3 being equal to 0 at certain points, but we would like to know if that is the case or what is causing it to go to zero and if possible how to fix this issue. Many thanks team 1153.

[MikeDubreuil]

Originally Posted by B_Dubbs

Distance = 0
Distance = 5
Distance = 0
etc.
Does anyone know why t has these jumps to zero?

You'll need to provide more information for me to understand the problem. Is 5 the correct distance? Where does Ping_Sonar() and Get_Sonar_Distance() get called in your code? I seem to remember while developing the code that many print statements in the code cause bizarre results, watch out for that too.

[Gdeaver]

I know that this discussion is focused on the VEX sonar but, the Matbotix sonar sensor is a much better sensor. It has been redisigned and is offered in several versions with different cones of detection. The nice thing about programming these sonars is that they offer a analog voltage output. A simple A to D call is all that is needed. They are 25$ plus shipping. Check out Sparkfun electronic for the differnt models and some links to FAQ and data sheet. The Sharp IR proximity sensor are similiar to the sonar but, better for some uses.
http://www.sparkfun.com/commerce/cat...hp?cPath=23_84

[Roger]

Unfortunately I didn't grab the code from last night so I don't remember exactly how "B_Dubbs" set it up (and he is hopefully at school right now and can't answer).

Generally it was counting down each loop and at one number it would do the Ping_Sonar() and a (lower) number it would do the Get_Sonar_Distance(). Originally it was 38 and 19, but I was trying to get him to go down to 3 and 1. My reasoning being that the Ping needs time to, er, ping before doing the Get.

We didn't have too many printfs, just printing out the distance and (at one time) printing out the raw number in Get_Sonar_Distance(). The output was pretty regular.

The numbers were approximately the distance, though I was just eye-balling it from afar. I tried to find out how far a distance it could reach but the numbers were only going up to 12 or 14. (I'm hoping for a bigger distance.) When it was working it would alternate a number-distance with a zero.

We are using 2006 (pre-Kevin's PWM routine) code, BTW.

Going back to my DOS days programming with INT 27h, I recall that you can daisy-chain programs to an interrupt address. Thinking ahead to making this code work with 2007 code, can this daisy-chaining work with IFI's code?

Mike, I want to also thank you for your time. I also want to thank you for an opportunity for me (at least) to dive into FRC interrupts -- it looks like fun!

Gdeaver: I'll put your suggestion into the Subcommittee in charge of Acquisitions (Sonars and Sodas sector) We're only using vex sonars as we have a couple from years past.