Official Beacon Tracking Code Posted
 

I've posted the official IR beacon and IR beacon tracking and navigation code that was used at the kick-off here: http://kevin.org/frc. The folks at IFI will also be posting the code on their website. If you have questions about the code, please leave 'em here and I'll try to keep up :ahh:.

-Kevin

Re: Official Beacon Tracking Code Posted
 

Thanks Kevin,

Do we run this in the EduBot RC as a separate system?

Is anyone able to convert this to Pbasic so I can run it on a Parallax BOE?

Re: Official Beacon Tracking Code Posted
 

Beacon.zip and navigate.zip are on Innovation First's website now.

Re: Official Beacon Tracking Code Posted
 

Yes, it was designed this way on purpose so that teams would be able to generate the beacon on their own fields. The field for this years game will use a EDU-RC to generate the beacon waveforms.

-Kevin

Re: Official Beacon Tracking Code Posted
 

hmmm.. that will be problematic if I don't go and get a 2nd 7.2v battery.

Re: Official Beacon Tracking Code Posted
 

Just get a 7.2V generic AC adaptor and add the necessary connector to make it connect to the EduRC.

Re: Official Beacon Tracking Code Posted
 

I haven't read up yet on this, but where can we find what materials we will need to actually emit the waveforms?

Re: Official Beacon Tracking Code Posted
 

Can you please describe the beacon waveform?

Re: Official Beacon Tracking Code Posted
 

I'm working on additional documentation for the beacon and beacon tracking software. I'll post it as I complete it. Meanwhile have a look at this thread for a description.

-Kevin

Re: Official Beacon Tracking Code Posted
 

Thanks. That scheme is relatively simple. Maybie if i find some time(not likley) i will post an alernative circuit, for those who do not wnat to use the edubot. This setup is easy to replicate using a handful of resistors, capacitors, and 555 timers.

Hmmm... I might have to look into the whole triangulation thing.

Re: Official Beacon Tracking Code Posted
 

I've done an Illustration showing the beacon waveforms and the infrared sensors response. It's here: http://kevin.org/frc.

-Kevin

Re: Official Beacon Tracking Code Posted
 

Kevin,
Thanks for the link explaining that the system uses BOTH beacons instead of ONE. I guess it finally clicked. I had trouble understanding how to manuever both directions ( left and right )using using a single "line of sight" source. My trig skills havn't been used in 20 years so I hope the students can help us out with triangulation.

I am still a little confused why 4 receiving LEDS are used and not 2, 1 for each beacon. ??

-Phil

Re: Official Beacon Tracking Code Posted
 

I'm trying to fully understand the code and working with the External ISRs first. It seems their sole purpose is to measure the amount of time of the active low pulse, categorize it as beacon 1 or 2, and then update Sensor_Stats[0].Beacon_Count[n] accordingly. Beacon 0 pulses every 1 MS and Beacon 2 pulses every 2 MS.


SO:
SENSOR #1
Sensor_Stats[0].Beacon_Count[0] increments a running count of pulses from beacon 1
Sensor_Stats[0].Beacon_Count[1] increments a running count of pulses from beacon 2

SENSOR #2
Sensor_Stats[1].Beacon_Count[0] increments a running count of pulses from beacon 1
Sensor_Stats[1].Beacon_Count[1] increments a running count of pulses from beacon 2

SENSOR #3
Sensor_Stats[2].Beacon_Count[0] increments a running count of pulses from beacon 1
Sensor_Stats[2].Beacon_Count[1] increments a running count of pulses from beacon 2

SENSOR #4
Sensor_Stats[3].Beacon_Count[0] increments a running count of pulses from beacon 1
Sensor_Stats[3].Beacon_Count[1] increments a running count of pulses from beacon 2


Ideally counts for beacon #1 should be incremented 26 times for beacon 1 and 13 times for beacon 2 when the Timer_1_Int_handler runs
Every 26.2MS, Timer_1_int_handler subtracts the "last" running count of pulses from the "new" running count of pulses to determine the number of pulses that occured over the last 26.2MS perion.

SO:
Sensor_Stats[0].Beacon_Quality[0] = Number of pulses that sensor #1 received from beacon 1 that occurred during the last 26.2 MS
Sensor_Stats[0].Beacon_Quality[1] = Number of pulses that sensor #1 received from beacon 2 that occurred during the last 26.2 MS

Sensor_Stats[1].Beacon_Quality[0] = Number of pulses that sensor #2 received from beacon 1 that occurred during the last 26.2 MS
Sensor_Stats[1]Beacon_Quality[1] = Number of pulses that sensor #2 received from beacon 2 that occurred during the last 26.2 MS

Sensor_Stats[2].Beacon_Quality[0] = Number of pulses that sensor #3 received from beacon 1 that occurred during the last 26.2 MS
Sensor_Stats[2].Beacon_Quality[1] = Number of pulses that sensor #3 received from beacon 2 that occurred during the last 26.2 MS

Sensor_Stats[3].Beacon_Quality[0] = Number of pulses that sensor #4 received from beacon 1 that occurred during the last 26.2 MS
Sensor_Stats[3].Beacon_Quality[1] = Number of pulses that sensor #4 received from beacon 2 that occurred during the last 26.2 MS


End result is:
The values held in the element Beacon.Quality[n] are the number of pulses from each sensor that occurr every 26.2MS where n = beacon #1 or #2. These values are updated every 26.2MS

AND

There are 4 sensors index by Sensor_Stats[n]
where n = of of 4 sensors

Ideally Beacon.Quality[n] should be contain 26 for beacon #1 and 13 for beacon #2.

Is this basically what's happenning in receiver.c ??
Sorry to be so "anal" but I like to fully understand how the code works in order to understand the entire system and move on to understanding tracker.c and then navigate.c where the rubber meets the road. All this while trying to work out out an approach to manage current and software optomization of a 4 motor drive system. I guess my weekend is shot.

-Phil

Re: Official Beacon Tracking Code Posted
 

Kevin,
Is there a "Theory of Operation" or White paper available to explain how this all works? I am assuming that type-0 operates on one side of the field and type-1 operates on the other side. Is this correct?

Also, is the waveform chart on your website accurate? I assume that the pulse repetition interval's (PRI) are fixed as depicted on the chart.

Thanks,
Steve...

Re: Official Beacon Tracking Code Posted
 

Actually, the beacon 0 pulse width is 1ms, the beacon 1 pulse width is 2ms. The beacon flashes every 10ms for a beacon rate of 100Hz.



As the beacon rate is 100Hz (=10ms), the counts for both beacon types will increment by 2 or 3 everytime the timer_1_int_handler executes.



Yes, this is correct except the beacons are #0 and #1



Yes, with index values of 0-3. How the individual sensors map to loacations on the tracker assembly is noted at the top of tracker.c



No, ...Beacon.Quality[n] should contain 2 or 3 when the beacon is in view. The algorithm in tracker.c assumes the beacon is in view of that particular sensors "quality" is greater than 0.



Yes, you have a very good grasp of how it works



No problem at all. This is a great discussion that other folks can hopefully learn from.



Have a look at Rich Petras' code in navigate.c for an example of motor stall detection using the new current sensors.



Sorry, dude, whether you know it or not, your next five weekends are shot :ahh: .

-Kevin

Re: Official Beacon Tracking Code Posted
 

Not yet. I need to find the time to complete it.


Yes, this is correct.


Yes, the waveforms are accurate. The beacon flash rate is fixed at 100Hz.

-Kevin

Re: Official Beacon Tracking Code Posted
 

No, actually the tracking software uses just one beacon for tracking. The type that it tracks is selected using a switch on digital I/O 7. We use four receiving sensors for speed and it simplified the tracking algorithm significantly (I'm still writing the theory of operation).

-Kevin

Re: Official Beacon Tracking Code Posted
 

What if both sensors are in view?

Re: Official Beacon Tracking Code Posted
 

Assuming the tracking assembly is correctly constructed, it means the tracker is pointed at the beacon. If you really meant to ask what if both beacons are in view?, the system is designed to easilly handle this because the type-0 and type-1 beacons are never flashing at the same time (assuming both beacons are being driven by one EDU-RC).

-Kevin

Re: Official Beacon Tracking Code Posted
 

Heh, pretty early in the morning for me, ye I meant beacons not sensors. So if both beacons are in view, then the trackers would keep switching back and forth from one beacon to the other depending on which one is flashing???

Re: Official Beacon Tracking Code Posted
 

No, the trackers will only track the beacon you want it to track (as selected by a switch on digital I/O 7).

-Kevin

Re: Official Beacon Tracking Code Posted
 

I see, thanks. Let see if I understand how the navigation code works:

The servos are constantly rotating attempting to follow the beacon. While this is happening the bot navigates to the beacon by moving in the direction that causes the angles with respect to the beacon and the trackers to become smaller? When the angle becomes small enough it assumes that it is in front of the beacon?

Re: Official Beacon Tracking Code Posted
 

hi kevin,
my team is having trouble downloading the navigation code onto our frc. our project builds fine, we can download other programs like beacon onto our edubot, so i dont think it is ifi loader or mplab, but when we download tracker or navigation the frc either crashes, doesnt get out of program state, or sends back a file called error.mcp that i think has address and hex op codes or something. do u know what is wrong? thanks
becca

electrical officer
115 monta vista high school

Re: Official Beacon Tracking Code Posted
 

Can you successfully load the default code for the FRC-RC? I've also noticed that sometimes when you download code to the EDU-RC and FRC-RC, the transfer was successful but the program light stays on until you power cycle or reset the controller at which time the controller functions as expected. Have you tried that?

-Kevin

Re: Official Beacon Tracking Code Posted
 

hey, did you ever get that circuit working?

AArgh...
 

Can anyone help out a confused person?
First, should we use 180-degree servos or 360-degree ones?
Second, minimum and maximum values for the servos are 0 and 254, respectively, right?
Third, is left servo position-127=right servo position, the beacon is centered, right?

Re: Official Beacon Tracking Code Posted
 

yes, we have successfully downloaded the frc default program. we have also tried to reset the controller, and when we do, the controller goes back into program state instead of running the program. has anyone else had this problem? i didnt change the navigation code before i downloaded it to the frc. thanks
becca

Re: Official Beacon Tracking Code Posted
 

Can you add this to the repository?

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

Re: Official Beacon Tracking Code Posted
 

we uploaded beacon code on the edurobot and the navigate code on the FRC robot to test if the IR things work. we got the ir beacons and the receivers on the right spot....are those the codes that suppose to work together?

or how do we test the beacon?

Re: Official Beacon Tracking Code Posted
 

If all you want to do is test the beacon and trackers, load beacon.hex into the EDU-RC and tracker.hex (included in tracker.zip) into the FRC-RC. The code in navigate.zip assumes that it's running on a real 'bot.

-Kevin

Re: Official Beacon Tracking Code Posted
 

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

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.

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

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 :)

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

Re: Official Beacon Tracking Code Posted
 

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

Re: Official Beacon Tracking Code Posted
 

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?

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?

Re: Official Beacon Tracking Code Posted
 

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

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

Re: Official Beacon Tracking Code Posted
 

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

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?

Re: Official Beacon Tracking Code Posted
 

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.