SONAR Sensor Software Driver

[demarais*1153*]

I've been trying to figure this code using Vex Ultrasound, for FRC. Have you updated this code at all since last post (MikeDubreuil)? Is this code still incompatible with Kevin's PWM driver? Also I'm having trouble figuring what digital input and output ports... I've looked through the sonar.h and the sonar.c , with no avail. Thank You -- mDemarais **Team 1153**

[Qbranch]

Originally Posted by MikeDubreuil

For anyone interested in using a SONAR sensor I have completed a software driver for it.

Wow... that would have saved me some work... I had to write a driver for these sensors last year...

Cool stuff! How'd you make all the interrupt code independent of the user_routines_fast.c file which contains the interrupt vectors? Are you just calling functions? Is that making hiccups in your pulse timing?

-q

[emersont49]

I have a coupleof the old Polaroid Sonar modules. Will this work with them?

[ctorloey]

Hi all,

I need some programming help for the sonar, any help would be nice. We need it to return a number for the distance.

please help me or my team mate demarais*1153*

thanks

[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.

[Qbranch]

People have been PM'ing me about my single-pin ultrasonic driver for the Parallax PING))) ultrasonic sensor module.

I've cut out most of the signal processing, noise filtering, and object tracking code that I wrote, but there is enough here to get you your pulse-timing (raw distances). If you have questions post, please don't PM since many end up asking the same questions.

I realize it isn't the prettiest code, but then again I was never intending on posting it when it was written...

Enjoy... I attached the related files below. *cringes waiting for flood of 'this is bad programming convention' posts*

-q

[Protronie]

Originally Posted by Qbranch

Enjoy... I attached the related files below. *cringes waiting for flood of 'this is bad programming convention' posts*

-q

Your right... it ain't pretty but it works and thats what matters...
thanks for posting!

[Roger]

Hey, it has plenty of good comments -- is that what you mean by "bad programming convention"? Thanks Qbranch!

We did get Mike's sonar code working last night (oh, the simple errors we made) -- the places we can now go!

______________________________
It's kind of fun to do the impossible. -Walt Disney

[gnormhurst]

Back in 2006 I installed Mike's sonar driver and it worked great. I followed his instructions for modifying InterruptHandlerLow () and everything was good.

I want to do it again, but when I look at the current code, InterruptHandlerLow () looks very different!

Can someone have a quick look at this and tell me if I have created any obvious conflicts? My modifications are in color.

Thanks!

Norm

void InterruptHandlerLow ()     
{
	if (PIR1bits.RC1IF && PIE1bits.RC1IE) // rx1 interrupt?
	{
		#ifdef ENABLE_SERIAL_PORT_ONE_RX
		Rx_1_Int_Handler(); // call the rx1 interrupt handler (in serial_ports.c)
		#endif
	}                              
	else if (PIR3bits.RC2IF && PIE3bits.RC2IE) // rx2 interrupt?
	{
		#ifdef ENABLE_SERIAL_PORT_TWO_RX
		Rx_2_Int_Handler(); // call the rx2 interrupt handler (in serial_ports.c)
		#endif
	} 
	else if (PIR1bits.TX1IF && PIE1bits.TX1IE) // tx1 interrupt?
	{
		#ifdef ENABLE_SERIAL_PORT_ONE_TX
		Tx_1_Int_Handler(); // call the tx1 interrupt handler (in serial_ports.c)
		#endif
	}                              
	else if (PIR3bits.TX2IF && PIE3bits.TX2IE) // tx2 interrupt?
	{
		#ifdef ENABLE_SERIAL_PORT_TWO_TX
		Tx_2_Int_Handler(); // call the tx2 interrupt handler (in serial_ports.c)
		#endif
	}

        // the following added to support sonar:
        //
        else if (INTCON3bits.INT2IF && INTCON3bits.INT2IE)/* The INT2 pin is RB2/DIG I/O 1. */
        { 
          Hardware_Interrupt_Sonar(); 
          INTCON3bits.INT2IF = 0;
        }

        else if ( PIR2bits.TMR3IF && PIE2bits.TMR3IE )
        {
            Timer_Interrupt_Sonar();  
        }


}