Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Your testing beacons vs. competition beacons (http://www.chiefdelphi.com/forums/showthread.php?t=26820)

gnormhurst 20-03-2004 22:54

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.

Astronouth7303 21-03-2004 15:26

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!

Kevin Watson 21-03-2004 16:00

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

Steve W 21-03-2004 16:25

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!!!!

gnormhurst 22-03-2004 09:41

Re: Your testing beacons vs. competition beacons
 
Quote:

Originally Posted by Kevin Watson
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

Thanks, yeah, I was using the old #pragma. I updated it to the more conservative one you posted here and the brain farts went away.

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


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

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