Poll: Is your team using an external processor?

[Eldarion]

I am curious how many teams are going to use some kind of external processor, other than the robot controller, on their robot this year.

You don't have to say what it is or what it does.

We are going to use one, I have already posted a teaser here:
http://www.chiefdelphi.com/forums/pi...le&picid=12651

[chris31]

We are not. This is my first year though, maybe next year.

[EricS-Team180]

We started a multi-year project to develop the capability. It is not our highest priority, so our progress is slow, right now.

Eric

[Chris Hibner]

This is the first year since autonomous was introduced that we are not using an external processor. It has nothing to do with the new micro, it's just that our autonomous strategies this year do not warrant an external processor.

[Windward]

How would you hook that up to the regular processor and what tasks are you assigning it to do instead of the main processor?

[Cuog]

we were going to use a TI-83 for our external calculations but we decided against it, next year we plan to use a "magic box" with all of our sensors and some sort of processor to crunch all the data and send the info back to the master microchip processor

[X-Istence]

Nah, no need for it. Most calculations can be done ahead of time, and instead can use a lookup table, simplifying things significantly.

While a lot of data can be good, too much data means too many what-if's need to be thought of and handled.

[Jared Russell]

Not needed for anything we need to do this year, so no.

[CronosPrime1]

Eldarion, I may be wrong, but it looks to me like your "extrenal processor" programming teaser might be the FRC controller with the cover off...

[Eldarion]

Originally Posted by CronosPrime1

Eldarion, I may be wrong, but it looks to me like your "extrenal processor" programming teaser might be the FRC controller with the cover off...

Sorry, but that isn't the RC.

This thread has some pics of the inside of the RC, and if you compare the two you can see my teaser is different.
http://www.chiefdelphi.com/forums/sh...ad.php?t=41079

[Darkswordsmith]

can someone tell me what this external processor is or why is it necessary for tasks?

[Chris Hibner]

Originally Posted by Darkswordsmith

can someone tell me what this external processor is or why is it necessary for tasks?

In past years, we had a 2-D navigation system using angular rate sensors and an encoder on a 5th wheel. The system would calculate X,Y coordinates of the robot so it always knew where th robot was on the field. In addition to that, it had all of the control algorithms necessary to drive in a straight line, turn in place, follow an arc of a give radius, or go directly to any X,Y position on the field. It could also send commands to the RC to move the arm, etc. It was all controlled by a scripting language that was complete with variables and logic (for instance, if you don't make it to X,Y within a certain time, you can take a different route). All of this would barely fit in a Motorola HC12, and it wouldn't come close to fitting in the RC.

The external processor read all of our sensors, did all of the math, ran the control algorithms, and performed two-way communication with the RC. The RC could update the external processor with information from the arm, and the external processor could send all of the drive-train commands back to the RC.

It was a really nice system and it made autonomous operation a breeze. It's just not necessary this year. In past years, you had to be in very precise positions in autonomous mode to pick up objects and score them. This year, you can shoot from anywhere on the field if you have the ability to auto-aim. Therefore, precise positioning of the robot is just not necessary in autonomous mode, so we're not using it this year.

[phrontist]

I can't imagine anyone needs an external processor to accomplish their autonomus tasks, but I could be wrong. I'm using three quaderature encoders, two potentiometers and the CMU cam, the data from which is used for some fairly complex navigation absractions and multiple feedback systems, and I haven't felt the limitations of the processor yet. What could you possibly be doing that requires a coprocessor? Calculating trajectories through some sort of crazy iterative method? I suppose that would justify it, but you are probably better off just linearizing a lot of empirical data to get a robot range to turret tilt (or shooter speed) function.

In the end you have to control everything through the main processor anyway, so it's not like you can run control loops faster...

[CronosPrime1]

I also don't believe in the need for one. I think that's overcomplicating things. FIRST programming is supposed to be relatively simple. To feel the limitations of the FRC, you have to do some really crazy stuff.

[seanwitte]

Originally Posted by CronosPrime1

I also don't believe in the need for one. I think that's overcomplicating things. FIRST programming is supposed to be relatively simple. To feel the limitations of the FRC, you have to do some really crazy stuff.

Most software development follows a bottom-up approach, where you start with small, managable chunks and gradually build up your functionality. It makes it easier to unit test and distribute the work load. If you have the expertise it makes sense to hand some of that work off to an external processor. Think taking Kevin Watson's camera code and running that on its own PIC. The output is the pan/tilt/centroid/bounding box/confidence. The group building out that functionality can work independently of the core programming team as long as they return the right data.

Based on the teaser that he posted, they're using a holonomic base and the camera. If the robot's reference frame is locked to the field's frame then the math and feedback loop start getting complex. Putting that on a separate processor would make sense, whether the RC could handle it or not.