Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Official Beacon Tracking Code Posted (http://www.chiefdelphi.com/forums/showthread.php?t=23742)

Kevin Watson 25-01-2004 22:13

Re: Official Beacon Tracking Code Posted
 
Quote:

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 26-01-2004 00:15

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

cbolin 26-01-2004 10:40

Re: Official Beacon Tracking Code Posted
 
Hi,
We began experimenting with the IR sensors. We're waiting on our mechanics to get the robot assembled so we can wire it and begin to tweak the code.

The beacon works well...looks cool through a digital camera set to night vision. We are using an IR sensor to drive an LED. Tapping off signal between 33 ohm resistor and LED cathode and sending to oscilloscope.

We are curious about the IR sensitivity. About 12 feet from beacon we realize how sensitive the IR sensors are in terms of orientation (azimuth and elevation). We placed a tube around the sensor to improve detection. Turning lighting off in room seems to improve signal detection...however, this may simply be allowing us to see the waveform a little better.

Has anyone experimented with improving detection range? Other than optics of some sort, there is no way to amplify the signal inside the IR sensor since an ON/OFF signal is produced.

Regards,
ChuckB

Squall 26-01-2004 13:53

Re: Official Beacon Tracking Code Posted
 
I'm currently studying the program, but i just can't get how the robot follows the signal, does the motors get activated based on the pwm that the program send to the servos that have the sensors ?

The way i get it, i think it would be like this

If the sensor pwm is 100 the motors would be activated to make a left turn with the robot, is that corrent ?!

Thanks for your help :)

rosebud 27-01-2004 02:30

Re: Official Beacon Tracking Code Posted
 
i found out what was wrong. before i was unable to download some of the code posted and a project i was building. if any of you have trouble downloading projects between 12,000 and 18,000 bytes, and you get an error.mcp file, or the frc doesnt leave the program state, it probably is because you are running a version of ifi loader before 1.06. apparently, the previous versions cant handle medium sized files. anyways, thanks for people's help!

becca

tml240 28-01-2004 12:19

Re: Official Beacon Tracking Code Posted
 
so we use beacon on EduRobot and Tracker Code on the FRC robot to see if it works???

roknjohn 28-01-2004 12:37

Re: Official Beacon Tracking Code Posted
 
Kevin,

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

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 28-01-2004 13:21

Re: Official Beacon Tracking Code Posted
 
Quote:

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 28-01-2004 21:56

Re: Official Beacon Tracking Code Posted
 
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 28-01-2004 22:57

Re: Official Beacon Tracking Code Posted
 
Quote:

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 18-02-2004 19:31

Re: Official Beacon Tracking Code Posted
 
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 18-02-2004 21:04

Re: Official Beacon Tracking Code Posted
 
Code:

                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.


All times are GMT -5. The time now is 22:12.

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