Any other robots w/Easy C at Boilermaker?

[Chris_Elston]

Curious if any other robots tried Easy C and was at Boilermaker? Was you using the camera?

If you did, can you tell me what matched you played? I want to watch your video in automode for a startup delay.

[Chris_Elston]

Ok....

Any robots AT ALL using EasyC? Do you have a video clip of your robot starting auto mode at ANY regional?

[TubaMorg]

Our robot is %100 EasyC, but our regional (Lonestar) isn't until next week, so we will see. Testing auto with the dongle seems to be ok though. I don't think we have what you want, though, since our camera is sitting on the shelf where we can't hurt ourselves Seriously, we designed a low shooter so didn't need the camera.

[Gdeaver]

We're using easy-c. Early on the programmers played with the camera. I seam to remember that 3 seconds was the best we could get a lock on and some times much worse. Also there where problems reacquiring a lock when it was lost. The camera was sucking up to much time and resources with little hope of success. We abandoned the camera. Our shooter can make the goal from the near start position. We optically align it, turn the motor on and feed balls. It's very accurate but, our feeder is slow. From the 2nd position we drive a minimum 4.5 ft and feed balls. We use a vex encoder (cheap) for distance with the GTS function. For shooting in the offensive period we are using an analog organic processor with a binocular vision subsystem (Human) to aim. I commend any team that got a camera system working reliably.

[Chris_Elston]

We didn't have any problems with the camera working at all. You can see where we get HIT and knocked off course here, but then we re-aim and finish taking the shots. Camera worked great for us.
http://www.soap.circuitrunners.com/2...n_010_bad2.wmv

I was curious if any other Easy C robot have a startup delay in auto mode. Watch this video, (we are 1501), lower left. you'll see that all robots start moving first but us. I wondered if that was the difference of using Easy C or something.
http://www.soap.circuitrunners.com/2...ker/in_005.wmv

[TubaMorg]

I recall when we were playing with our camera that there is a delay for the camera and gyro initialization. So the question is are you starting the camera or gyro anywhere else but the Initialize loop? I'm thinking maybe you are calling a start at the beginning of the Autonomous loop? Because once the camera is initialized, it begins tracking whether the field is enabled or not, so there is no reason for any delay unless it gets reinitialized. Does it do the same thing with Autonomous test dongle?

EDIT: BTW, Your team's robot looks great Chris!

[Chris_Elston]

I'll have to check into this. I think if I remember right, the "start" was only once in the INI function. Then the "capture" was twice I think. Once in Auto and Operator functions. Again, I'll have to look at it sometime.

[Kingofl337]

You should be starting your camera and initializing the gyro in the Initialization() function. I would also recommend starting timers and pretty much any other sensor in there as well. That way its ready once the program starts. Our team had no problems with startup delay.

Nice Robot and good job in automous by the way!

I would also recommend to any team in general if you don't want
to use the camera to drive use it for a manual aiming system that lights up the LEDs on the OI. I would recommend that you also fix the camera because it
complicates things when its panning and tilting.

I think going to post a program today with a function any team can import
to use a fixed camera mount to use it and the OI aim manualy with the camera.