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

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

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.

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?

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…

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…

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…

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.

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 !!

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!]

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.

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…

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.

My bad. I wasn’t looking at the pic when I posted. Oops…

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.

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:


/*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;
}

I’ve had trouble with the beacons at the Trenton Regional, but my trouble was that the beacons were too strong, not too weak. That and the people running the event were barely aware of “IR beacons” and did not know how to tell me which was beacon Type 0 and Type 1. See my story.

Our trackers seemed to see IR from lots of directions – reflections – and the “lock” paradigm of “I’m locked when both sensors see some IR” leads to trackers that lock in almost any direction.

I am trying a new approach outlined in my post here. My current problem is what I call RC “brain farts” – the printf data occasionally gets corrupted and sometimes one or other tracker may suddenly zip all the way to one end. It’s as if something was trampling on memory. I remember reading something Kevin Watson posted about not saving enough context info before each interrupt service. I’ll look that up and see if I can apply it, and see if it helps.

Funny, I seem to be getting something similar with the gyro. It sometimes increments the counter by 1s and 2s, even with a deadband of 7!

Yeah, you can see some pretty wierd behavior if the context isn’t saved properly. It would be nice if the compiler was more intelligent in this regard. Until then, you need to tweak this yourself with a somewhat cryptic #pragma statement that’s documented in section 2.9.2 of the compiler user’s guide.

-Kevin

Shawn see me Monday night. When I was at Detroit I had time to work with the Innovation FIRST guy. We did a lot of testing on the field with their sensor. We found that even when pointing right at 1 beacon that the other beacon was still being picked up. There were areas that both beacons were not picked up but they were random. We even got signals when facing the diamond plate. We also did a test covering the outside emitters with my fingers. After doing this the signals were much more distinct. This may be why they are taping some at other regionals.

For anyone going to a regional and using IR sensors, I would reccomend that you ask for 2 or three practice rounds, spread throughout the day, that only robots with IR are allowed onto the field and that computers can be brought onto field to recieve readings. I don’t think that there should be a problem if approached right. Remember when asking to mention that this is something that FIRST wants to see, There are no beacons allowed on site and that the only way that you can troubleshoot is with your laptops.

Good Luck to all!!!

Thanks, yeah, I was using the old #pragma. I updated it to the more conservative one you posted here and the brain farts went away.

All: it’s the “#pragma interruptlow” in user_routines_fast.c. This is the one to use:

#pragma interruptlow InterruptHandlerLow save=PROD,section("MATH_DATA"),section(".tmpdata")