Chief Delphi - SONAR Sensor Software Driver

Page 3 of 4

Show 100 post(s) from this thread on one page

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - SONAR Sensor Software Driver (http://www.chiefdelphi.com/forums/showthread.php?t=42717)

demarais*1153*

09-10-2007 20:20

Re: SONAR Sensor Software Driver

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

10-10-2007 12:00

Re: SONAR Sensor Software Driver

Quote:

Originally Posted by MikeDubreuil (Post 440799)

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... :rolleyes:

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

18-10-2007 15:03

Re: SONAR Sensor Software Driver

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

ctorloey

23-10-2007 22:01

Re: SONAR Sensor Software Driver

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

25-10-2007 09:55

Re: SONAR Sensor Software Driver

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

25-10-2007 11:10

Re: SONAR Sensor Software Driver

Quote:

Originally Posted by Roger (Post 647925)

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 :o ). 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

05-11-2007 11:47

Re: SONAR Sensor Software Driver

Quote:

Originally Posted by Roger (Post 647925)

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

06-11-2007 22:26

Re: SONAR Sensor Software Driver

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

07-11-2007 07:39

Re: SONAR Sensor Software Driver

Quote:

Originally Posted by B_Dubbs (Post 650053)

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

07-11-2007 07:40

Re: SONAR Sensor Software Driver

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

07-11-2007 10:13

Re: SONAR Sensor Software Driver

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) :D We're only using vex sonars as we have a couple from years past.

Qbranch

08-11-2007 11:32

Re: SONAR Sensor Software Driver

3 Attachment(s)

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... :o

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

-q

Protronie

08-11-2007 14:39

Re: SONAR Sensor Software Driver

Quote:

Originally Posted by Qbranch (Post 650374)

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

-q

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

Roger

09-11-2007 07:52

Re: SONAR Sensor Software Driver

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

15-01-2008 10:33

Re: SONAR Sensor Software Driver

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

Code:

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();  

        }





}

All times are GMT -5. The time now is 22:14.

Page 3 of 4

Show 100 post(s) from this thread on one page