Chief Delphi
Page 1 of 2 1 2 >
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)
-   -   Your testing beacons vs. competition beacons (http://www.chiefdelphi.com/forums/showthread.php?t=26820)

Mr. Lim 16-03-2004 10:44
Your testing beacons vs. competition beacons
 
All,

Our team had difficultly with the beacons at the Pittsburgh Regional this past weekend. The beacons we manufactured ourselves, driven by the default beacon code via an EduRobot controller, worked fine with our robot. The ones we constructed were 7-LED arranged in a gradual arc, with the proper spec current limiting resistors on each LED. No housing (we had no drawings for them).

When we put our robot on the field, we only were sporadically picking up FIRST's beacon signals. It would find it for a fraction of a second, then lose it. I'm not talking about our trackers oscillating back and forth in the general direction of the beacon, but it would find the beacon, stop while looking directly at it for a short time, then start sweeping back and forth over our entire servo travel distance. A few seconds later, it would find it again.

As if someone was turning the beacon on for a split second, then off for 2-3.

We had a team member with a PDA standing right along the side of the field during a few of our matches. Normally he can read and "capture" the signal being sent out by the beacons from the opposite side of the field. In fact, we did this to verify that the proper beacon signals were being broadcast on the proper sides of the field, by "capturing" the signal, and then reproducing it with the PDA in an isolated place for our robot.

The problem we found was that we had to be within 5 feet of FIRST's beacon to properly "capture" the signal with our PDA, whereas our beacons, we can be 40 feet away and still capture them.

And yes, we held the PDA at about 3'8" off the ground at all times.

We asked the Innovation FIRST representative that was present to check the beacons, and he told us that they were working properly.

Am I missing something about the specs of the beacons? Was there anyone else who noticed any differences between beacons they had built and the ones at the competitions?

I'm disappointed we couldn't get our IR working properly at our 1st regional this year, and now am seriously doubting to even try IR at our 2nd event. We reverted to a series of dead-reckoning programs after blowing away our practice sessions and most of our qualification rounds =(.

Any kind of help or advice would be greatly appreciated!

-Shawn...

Kevin Watson 16-03-2004 11:30
Re: Your testing beacons vs. competition beacons
 
You might consider using the beacon diagnostics code to make sure the beacons are working correctly. Do you know which FIRST representative you talked with?

-Kevin

KenWittlief 16-03-2004 11:54
Re: Your testing beacons vs. competition beacons
 
the IR beacons used have a 40Khz carrier frequency - there are many different frequencies used by IR links, so unless you have looked into it, the chances are your PDA is not on 40Khz - which would explain the reduced range compaired to the sensors FIRST gave us.

We used the IR beacons and had no problem, but only look for them 90° off the sides of our bot - so we dont need to see them until we are passing it about 3 to 8 feet away.

we were at pittsburgh and they seemed to work fine for us.

I made a beacon using a PIC chip and the circuit provided by FIRST - this allows us to use the EDU bot as an IR receiver - I wish I understood your problem better at pittsburgh - we could have verified the beacon operation with our EDU RC

but if FIRST says they were working I would think they had something similar to check them with - I would seriously consider checking your code - are you using the default stuff from innovationfirst? or did you make changes to it.

interrupts can be very tricky, and when something is not right with them intermittant operation is one of the symptoms

we are not using interrupts - only the INT1 and INT2 flags, polled from the main loop to see if the pin saw a transistion, then we clear them in SW - no interrupts are enabled in our code.

Mr. Lim 16-03-2004 16:49
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by KenWittlief
the IR beacons used have a 40Khz carrier frequency - there are many different frequencies used by IR links, so unless you have looked into it, the chances are your PDA is not on 40Khz - which would explain the reduced range compaired to the sensors FIRST gave us.
It was a PDA program meant to copy IR signals from a remote control, and be able to reproduce them, so that you could use your PDA as a remote control replacement. I know that IR remote controls also have a whole range of carrier signal frequencies, and that 40kHz is quite nominal.

This also doesn't explain why we CAN capture the signals from our beacons from 40 ft away, but need to be within 5 ft to capture signals from FIRST's beacons... all using the same PDA.

They should both be putting out the same signal right? Are FIRST's intensities much lower? can they not be picked up from more than 10 feet away? Is there another team using the IR beacons from their starting positions? Am I just too $@#$@#$@#$@# far?

Quote:
Originally Posted by KenWittlief
We used the IR beacons and had no problem, but only look for them 90° off the sides of our bot - so we dont need to see them until we are passing it about 3 to 8 feet away.

we were at pittsburgh and they seemed to work fine for us.

I made a beacon using a PIC chip and the circuit provided by FIRST - this allows us to use the EDU bot as an IR receiver - I wish I understood your problem better at pittsburgh - we could have verified the beacon operation with our EDU RC
Our robot needed to be able to pick up both beacons from the starting position until the robot progressed near the middle of the field. It would then turn towards the closer beacon, and both our trackers would then focus on that single beacon.

Our autonomous mode would stop the robot if at any time a tracker showed NONE_IN_VIEW... which happend more often than not...

Quote:
Originally Posted by KenWittlief
but if FIRST says they were working I would think they had something similar to check them with - I would seriously consider checking your code - are you using the default stuff from innovationfirst? or did you make changes to it.
Our code uses receiver.c and tracker.c. We modified them to have our trackers sweep in both directions (rotate CW until limit, switch to CCW) and in smaller increments (1 count), and reduced the period of TMR1 since the default period allowed up to 3 occurances of the beacon signal to be captured in a single interrupt period.

The guts of our autonomous code is simple: If the trackers aren't NONE_IN_VIEW, we take the servo position of each tracker, fire it through a lookup table for the left motor and the right motor. We precalculated the look up tables beforehand on a PC. If any of the trackers is NONE_IN_VIEW, then the robot stops.

When your robot jerks violently for a few seconds, then stops, then jerks again... something is amiss...

When everytime your robot stops moving, and you see your trackers are sweeping furiously trying to find a beacon 15 feet away... it makes you think harder...

Quote:
Originally Posted by KenWittlief
interrupts can be very tricky, and when something is not right with them intermittant operation is one of the symptoms

we are not using interrupts - only the INT1 and INT2 flags, polled from the main loop to see if the pin saw a transistion, then we clear them in SW - no interrupts are enabled in our code.
It still bothers me that everything works fine with our beacons, but didn't on the field in Pittsburgh.

At any rate, I think I'm going to make one last stab at the Canadian Regional during our 1st practice session, then call it quits on IR if it's a no go...

Wish us luck =)...

-Shawn...

KenWittlief 16-03-2004 17:03
Re: Your testing beacons vs. competition beacons
 
how do you have the sensors mounted on your bot? are you restricting the angles from which the light can hit the sensor?

we have ours on inside a 1 x 2 x 4" black plastic box from radioshack, with the sensor all the way on the back side, and the front has a slit cut, about 1/8" wide and vertical on the bot

so we have a very narrow angle of view left and right and about a 45° angle up and down

have you done something similar or do your sensors have a wide angle of view?

one suggestion is if you lose the signal keep going straight ahead until you re-acquire it - we had our auton mode shutting down if something went wrong, then realized - what are we protecting by doing that? - nobody is going to get hurt if we are off course or somethings not exactly right, so we might as well at least take a shot at dead recogning - maybe we will still get the ball that way - cant hurt to try, but if you stop you definately lose out.

Dale(294engr] 16-03-2004 17:42
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by SlimBoJones
All,

Our team had difficultly with the beacons at the Pittsburgh Regional this past weekend. The beacons we manufactured ourselves, driven by the default beacon code via an EduRobot controller, worked fine with our robot. The ones we constructed were 7-LED arranged in a gradual arc, with the proper spec current limiting resistors on each LED. No housing (we had no drawings for them).

When we put our robot on the field, we only were sporadically picking up FIRST's beacon signals. It would find it for a fraction of a second, then lose it. I'm not talking about our trackers oscillating back and forth in the general direction of the beacon, but it would find the beacon, stop while looking directly at it for a short time, then start sweeping back and forth over our entire servo travel distance. A few seconds later, it would find it again.

As if someone was turning the beacon on for a split second, then off for 2-3.

We had a team member with a PDA standing right along the side of the field during a few of our matches. Normally he can read and "capture" the signal being sent out by the beacons from the opposite side of the field. In fact, we did this to verify that the proper beacon signals were being broadcast on the proper sides of the field, by "capturing" the signal, and then reproducing it with the PDA in an isolated place for our robot.

The problem we found was that we had to be within 5 feet of FIRST's beacon to properly "capture" the signal with our PDA, whereas our beacons, we can be 40 feet away and still capture them.

And yes, we held the PDA at about 3'8" off the ground at all times.

We asked the Innovation FIRST representative that was present to check the beacons, and he told us that they were working properly.

Am I missing something about the specs of the beacons? Was there anyone else who noticed any differences between beacons they had built and the ones at the competitions?

I'm disappointed we couldn't get our IR working properly at our 1st regional this year, and now am seriously doubting to even try IR at our 2nd event. We reverted to a series of dead-reckoning programs after blowing away our practice sessions and most of our qualification rounds =(.

Any kind of help or advice would be greatly appreciated!

-Shawn...
Is it possible the ~30' cables driving the competitiion emitters from an EDU looses pulse integrity for the 12.5uS ON pulse period ?
i.e. resulting in << 12.5uS ON period for the IR LED's and consequent decreased range ?? (Receiver looses lock on pulse train)
Did you scope the Rx output ?
A straight IR photodetector to a scope would be revealing.
At the Phoenix Regional half of the emitters on one side were taped off !!

Random Dude 16-03-2004 18:05
Re: Your testing beacons vs. competition beacons
 
One possibilty that comes to mind is that the cable got connected backwards. That would simply reverse the ground and signal pins, so the beacon could still transmit, however, since the sink ablitly of the signal pin isn't very high, it would consideralbly reduce the range of the IR signal.

Astronouth7303 16-03-2004 19:52
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by Random Dude
One possibilty that comes to mind is that the cable got connected backwards. That would simply reverse the ground and signal pins, so the beacon could still transmit, however, since the sink ablitly of the signal pin isn't very high, it would consideralbly reduce the range of the IR signal.
Since LEDs are a variety of diode (not that I should have to say this), then the LED won't allow backwards current through. NO IR.

Or am I misunderstanding the IRL3103 (FET) thingy?

When I though of this, I checked both the pin arangement and the revised schematic. I think I'm reading everything right. (Check pins w/IFI's huge gif)

[Excuse me if I'm wrong. Trying to figure it out right is giving me a headache!]

dez250 16-03-2004 20:06
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by Astronouth7303
Since LEDs are a variety of diode (not that I should have to say this), then the LED won't allow backwards current through. NO IR.

Or am I misunderstanding the IRL3103 (FET) thingy?

When I though of this, I checked both the pin arangement and the revised schematic. I think I'm reading everything right. (Check pins w/IFI's huge gif)

[Excuse me if I'm wrong. Trying to figure it out right is giving me a headache!]
No you are absolutly correct, you can not run an led in "reverse". On normal commercial led's the positive pin is the longer of the 2 pins. What i am wondering is if you might have went out and got replacment ir recievers from radio shack or somewheres and got a blanket style ir device that will pick up a range of frequencies or if you might just have damaged ir detectors. The temp can damage them in shipping or storage.

Random Dude 16-03-2004 20:23
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by Astronouth7303
Since LEDs are a variety of diode (not that I should have to say this), then the LED won't allow backwards current through. NO IR.

Or am I misunderstanding the IRL3103 (FET) thingy?

When I though of this, I checked both the pin arangement and the revised schematic. I think I'm reading everything right. (Check pins w/IFI's huge gif)

[Excuse me if I'm wrong. Trying to figure it out right is giving me a headache!]
Actually, I wasn't refering to the LED, I was refering to the PWM cable that would have been connected by the field personnel. If the cable was reversed, the LED's would still be biased correctly, but the Gate and Source on the FET would be swapped.

It should still work, just under the conditions I described before...

Astronouth7303 17-03-2004 07:24
Re: Your testing beacons vs. competition beacons
 
I still don't understand the FET, but if you switched a PWM cable, you would swap ground (Black) and signal (Red). That would mean that there is no + on the + side of the LEDs, correct?

Random Dude 17-03-2004 11:27
Re: Your testing beacons vs. competition beacons
 
Quote:
Originally Posted by Astronouth7303
I still don't understand the FET, but if you switched a PWM cable, you would swap ground (Black) and signal (Red). That would mean that there is no + on the + side of the LEDs, correct?

Nope, The red wire (+7.2v) is in the center, so that is always going to be connected to the + side of the LED.

The Black (Gnd) and White (Signal) are on the outside.

Astronouth7303 17-03-2004 14:58
Re: Your testing beacons vs. competition beacons
 
My bad. I wasn't looking at the pic when I posted. Oops...

Mr. Lim 17-03-2004 20:17
Re: Your testing beacons vs. competition beacons
 
We "shotgunned" our sensors. The sensors are housed in a length of heatshrink tubing, with half of it cut away. It is pretty much exactly the same as what you would see on Kevin Watson's website. The sensors are mounted on PCB which are then fastened to a servo with industrial plastic velcro.

The entire servo/sensor assembly is enclosed in the clear plastic top of a CD spindle.

I'm going to take your advice about dead reckoning if no signal is found. I guess there isn't much to lose by having the robot just go, but I think we will try and dead reckon ourselves closer to the beacon first, then use IR to fine tune an approach to the 10pt balls. I'm going to forget about using IR right from the beginning of autonomous mode.

Quote:
Originally Posted by KenWittlief
how do you have the sensors mounted on your bot? are you restricting the angles from which the light can hit the sensor?

we have ours on inside a 1 x 2 x 4" black plastic box from radioshack, with the sensor all the way on the back side, and the front has a slit cut, about 1/8" wide and vertical on the bot

so we have a very narrow angle of view left and right and about a 45° angle up and down

have you done something similar or do your sensors have a wide angle of view?

one suggestion is if you lose the signal keep going straight ahead until you re-acquire it - we had our auton mode shutting down if something went wrong, then realized - what are we protecting by doing that? - nobody is going to get hurt if we are off course or somethings not exactly right, so we might as well at least take a shot at dead recogning - maybe we will still get the ball that way - cant hurt to try, but if you stop you definately lose out.

KenWittlief 17-03-2004 22:41
Re: Your testing beacons vs. competition beacons
 
SLimBo - thanks for posting this thread and your concerns - I am definately bringing my spare sensors and my edu bot RC- which has the same code for looking for the IR signals, and it turns on an LED on a digital output

so I can use it to scan the field at the buckeye regional (our next event) and see if the beacons are working and solid

im posting my scanner code - its about as simple as you can get - it looks at the INTR flags for rc_dig_in01 and 2, which are INT2 and 3 - those flags get set when the input pin see a change in state, which would normally trigger an interrupt

but we dont use the interrupts - we dont enable them - all we want to know is if those pins are toggleing - and we wait till we see them toggle on three SW loops in a row - then we say - YEP! that sensor is flooded by the beacon:

if anyone wants to use the IR sensors and interrupts have scared you off, try this code - its simple:

Code:
/*driver mode scan for IR beacons - used for testing beacons*/
if (INTCON3bits.INT2IF)        /*578 interrupt flag polling */
{
        INTCON3bits.INT2IF=0;        /*clear the intr flag*/
        if (DirFilterL==2) DiSeeL=1;        /*IR seen when intr2 3 times in a row*/
        else DirFilterL = DirFilterL+1;
}
else
{
        DiSeeL=0;        /*turn it off when no intr*/
        DirFilterL=0;
}
if (INTCON3bits.INT3IF)
{
        INTCON3bits.INT3IF=0;    /*clear the R intr flag*/
        if (DirFilterR==2) DiSeeR=1;        /*IR seen when you see the intr3 3 times*/
        else DirFilterR=DirFilterR+1;
}
else
{
        DiSeeR=0;        /*turn it off when no intr*/
        DirFilterR=0;
}


All times are GMT -5. The time now is 02:53.
Page 1 of 2 1 2 >
Show 100 post(s) from this thread on one page

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi