![]() |
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... |
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 |
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. |
Re: Your testing beacons vs. competition beacons
Quote:
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:
Our autonomous mode would stop the robot if at any time a tracker showed NONE_IN_VIEW... which happend more often than not... Quote:
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:
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... |
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. |
Re: Your testing beacons vs. competition beacons
Quote:
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 !! |
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.
|
Re: Your testing beacons vs. competition beacons
Quote:
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!] |
Re: Your testing beacons vs. competition beacons
Quote:
|
Re: Your testing beacons vs. competition beacons
Quote:
It should still work, just under the conditions I described before... |
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?
|
Re: Your testing beacons vs. competition beacons
Quote:
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. |
Re: Your testing beacons vs. competition beacons
My bad. I wasn't looking at the pic when I posted. Oops...
|
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:
|
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*/ |
| All times are GMT -5. The time now is 03:10. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi