Official Beacon Tracking Code Posted

[Kevin Watson]

Originally Posted by SilverStar

Can you add this to the repository?

http://nrg.chaosnet.org/repository - You'll need to register

Thanks, but I'd rather not have the beacon/tracking/navigation code posted elsewhere because it makes it even harder for me (and others) to support folks using the code.

-Kevin

[deltacoder1020]

also, it's best to have the official code only posted certain places, as updates (if necessary) would be painful with multiple locations.

[tml240]

so we use beacon on EduRobot and Tracker Code on the FRC robot to see if it works???

[roknjohn]

Kevin,

On your website, you mention that there are two versions of receiver.c.

As there are two different versions of receiver.c, make sure that your sensors are attached according to the instructions at the top of receiver.c.

WHERE are the two versions, WHAT are the differences, and - uh- WHY?

I was using a solderless breadboard to build and test the beacon and sensors before committing to a design. Using the EDU, I was going to marry the beacon driver and the receiver code into one program to get a better understanding of how this stuff works. (i.e. one program to both flash the beacons and detect it with a sensor) Unfortunately, my first attempt at that resulted in a flashing red program state LED on the EDU. I will work on it again tonight. Are there any considerations/conflicts when including receiver.c in the beacon code?

[Kevin Watson]

Originally Posted by roknjohn

Kevin,

On your website, you mention that there are two versions of receiver.c.
WHERE are the two versions, WHAT are the differences, and - uh- WHY?

The version in tracker.zip is newer that the version used to build the kick-off demonstration code. The differences can be gleaned through examination of the FAQ and the file headers.

-Kevin

[Matthew_H]

I have noticed that the diagram that FIRST has posted on the photo sensor is wrong if you go by the picture. If you follow were pin 1 goes it is correct but looking how the sensor ir positioned on diagram pin 1 and 3 are swapped. We caught this by looking at the datasheet from http://www.kevin.org/frc/TSOP34840.pdf

I hope this will help any other teams that might be having some small problems with the IR sensors.

Matthew

Ubergeeks

[Kevin Watson]

Originally Posted by Matthew_H

I have noticed that the diagram that FIRST has posted on the photo sensor is wrong if you go by the picture. If you follow were pin 1 goes it is correct but looking how the sensor ir positioned on diagram pin 1 and 3 are swapped. We caught this by looking at the datasheet from http://www.kevin.org/frc/TSOP34840.pdf

I hope this will help any other teams that might be having some small problems with the IR sensors.

Matthew

Ubergeeks

Holy cow! I just found the document and it is backwards. I wonder how many teams have used this document. Matthew, as this is your find, you should start a new thread with this information.

-Kevin

[arnob1]

I was wondering, once the Turn_To_Target state switches to the Drive_To_Target state, what is it supposed to do since Drive_To_Target is blank? Does that code have to be implemented by ourselves?

[deltacoder1020]

		case DRIVE_TO_TARGET:
		case PASSED_TARGET:

the way the "switch" and "case" statements work, the code for PASSED_TARGET is actually executed for both the DRIVE_TO_TARGET state and the PASSED_TARGET state. you see how most "case" statements have a "break" statement at the end? that is to keep the code from the "case"s below from executing - the break statement makes the execution jump to the end of the current block, in this case the "switch". There's no "break" after DRIVE_TO_TARGET, so it just keeps on executing downwards, and thus it's just a shortcut so that both states have the same code.