|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
|||||
|
|||||
|
Re: Your testing beacons vs. competition beacons
I've had trouble with the beacons at the Trenton Regional, but my trouble was that the beacons were too strong, not too weak. That and the people running the event were barely aware of "IR beacons" and did not know how to tell me which was beacon Type 0 and Type 1. See my story.
Our trackers seemed to see IR from lots of directions -- reflections -- and the "lock" paradigm of "I'm locked when both sensors see some IR" leads to trackers that lock in almost any direction. I am trying a new approach outlined in my post here. My current problem is what I call RC "brain farts" -- the printf data occasionally gets corrupted and sometimes one or other tracker may suddenly zip all the way to one end. It's as if something was trampling on memory. I remember reading something Kevin Watson posted about not saving enough context info before each interrupt service. I'll look that up and see if I can apply it, and see if it helps. |
|
#17
|
|||||
|
|||||
|
Re: Your testing beacons vs. competition beacons
Funny, I seem to be getting something similar with the gyro. It sometimes increments the counter by 1s and 2s, even with a deadband of 7!
|
|
#18
|
||||
|
||||
|
Re: Your testing beacons vs. competition beacons
Yeah, you can see some pretty wierd behavior if the context isn't saved properly. It would be nice if the compiler was more intelligent in this regard. Until then, you need to tweak this yourself with a somewhat cryptic #pragma statement that's documented in section 2.9.2 of the compiler user's guide.
-Kevin |
|
#19
|
||||
|
||||
|
Re: Your testing beacons vs. competition beacons
Shawn see me Monday night. When I was at Detroit I had time to work with the Innovation FIRST guy. We did a lot of testing on the field with their sensor. We found that even when pointing right at 1 beacon that the other beacon was still being picked up. There were areas that both beacons were not picked up but they were random. We even got signals when facing the diamond plate. We also did a test covering the outside emitters with my fingers. After doing this the signals were much more distinct. This may be why they are taping some at other regionals.
For anyone going to a regional and using IR sensors, I would reccomend that you ask for 2 or three practice rounds, spread throughout the day, that only robots with IR are allowed onto the field and that computers can be brought onto field to recieve readings. I don't think that there should be a problem if approached right. Remember when asking to mention that this is something that FIRST wants to see, There are no beacons allowed on site and that the only way that you can troubleshoot is with your laptops. Good Luck to all!!!! |
|
#20
|
|||||
|
|||||
|
Re: Your testing beacons vs. competition beacons
Quote:
All: it's the "#pragma interruptlow" in user_routines_fast.c. This is the one to use: Code:
#pragma interruptlow InterruptHandlerLow save=PROD,section("MATH_DATA"),section(".tmpdata")
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Intrest in Another Competition? | Allison K | Off-Season Events | 4 | 26-02-2004 19:04 |
| Competition IR Beacon - how does its physical setup compare to our beacons? | DanL | Electrical | 2 | 25-01-2004 18:05 |
| Looking from a different point at "Fixing" | punarhero | General Forum | 27 | 18-03-2003 18:41 |
| How well did the regional competition help preparing? | archiver | 2001 | 3 | 24-06-2002 02:33 |