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