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
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?
Beacon.zip and navigate.zip are on Innovation First’s website now.
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
hmmm… that will be problematic if I don’t go and get a 2nd 7.2v battery.
Just get a 7.2V generic AC adaptor and add the necessary connector to make it connect to the EduRC.
I haven’t read up yet on this, but where can we find what materials we will need to actually emit the waveforms?
Can you please describe the beacon waveform?
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
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.
I’ve done an Illustration showing the beacon waveforms and the infrared sensors response. It’s here: http://kevin.org/frc.
-Kevin
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
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
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…
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
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
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
What if both sensors are in view?
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
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???