Co-Processor?

[Guy Davidson]

I recently ran into the AdamBots' informative wiki about their co-processor from last year using a gumstix. It sounds like a very intriguing idea. However, we were having our doubts as to how necessary or helpful it is. Obviously remote programming is nice. However, we have a few questions to anyone who's tried to use co-processors before, thought about it, or best, used them:

Do you see a significant change in performance (does the robot respond faster)?
Does the extra processing power help a lot (for example by making it feasible to do floating-point math and trig)?
Did you find you can use more sensors without a loss in performance? Or more in general, did you find you having a co-processor makes more complex code feasible?

For those of you who haven't seen it, here is the link to relevant part of the AdamBots' site:
http://www.adambots.com/index.php?title=Co-Processor

[jee7s]

Co-processors aren't out of the question, and I have found they are useful for additional interfacing. For example, in the past I have used several networked controllers to divide a system into smaller independent parts. In this case, the sample rates on each controller can be increased since each controller completes the main loop faster.

Also, if you are doing a lot of floating point operations, keep in mind the PIC18 controllers in the IFI controller do not have hardware implementations of the floating point math, so you are chewing up extra instruction cycles with every floating point operation. There are companies that make floating point co-processors, like micro-mega (http://www.micromegacorp.com/).

As for a FIRST application, I have floated the idea of a co-processor for additional sensor feedback. Why have the IFI controller do all sorts of processing to determine if a (generic) sensor is within a limit when a co-processor can do it? Better yet, why not have a co-processor decode all encoder inputs? This will limit the number of interrupts that occur on the IFI controller, and expand the number of encoders you can use. This can be done with PIC18 processors that Microchip sells for about $5 a piece, provided you are willing to buy the necessary programmer. Also, your students would already be familiar with the MPLAB IDE.

So, even if you don't want to move all the way to the GUMSTIX level, you can 'roll your own' with Microchip, if you are willing to invest some money ($200) in a programmer.

[Rickertsen2]

Building a co-processor is a great learning exercise. That said, with efficient coding most anything can be accomplished with the RC in current form. Ask yourself why you need a co-processor. Have you exceeded the capacity of the RC already? Is there some specific sensor setup or algorithm you want to implement that requires one? Do you need remote programming? Is building a co-processor for the learning experience reason enough? Ask yourself these questions. Theoretically you could implement remote reprogramming without the use of a co-processor.

[Guy Davidson]

Up until now I have just avoided floating point math by using integer approximations and making sure I am multiplying before I'm dividing (and that my data types are big enoguh for the type of numbers I expect to see).

Actually, we're messing around with some neat ways to do software (or even mostly hardware) hande much of the encoder data, and just give the RC velocities or some other easier (on the system) type of data via a serial or a digital input. If that works, and works well, we might try and apply the same solutions to an ultrasonic sensor or a gyro. Money investment should and probably won't be the limiting factor for this projcet (while obviously not spending money just because we can).

I am not sure we have exceeded the capacity of the RC. Is there any good way to test that? It should probably change based on weather or not we're using WPILib, which we plan to use.

Seeing as I do not know what would exceed the capacity of the RC, I'm not sure if there's a chance of that happening.

Remote programming is definitely not a necesity, or the reason why we'd implement a co-processor.

The experience, however, might be a bigger factor.

[bear24rw]

So, even if you don't want to move all the way to the GUMSTIX level, you can 'roll your own' with Microchip, if you are willing to invest some money ($200) in a programmer.

Or just use an AVR and its practically free..

[Robostang 548]

I worked with the adambots coprocessor solution over the summer. I'm working on a new kind of autonomous code that needs the added processing speed, memory, and floating point capability. I strongly recommend you take a laptop running Linux and hook it up to your RC just to try the code out before you buy anything. The adambots code is difficult to understand when you download it. The RC code is more like a bunch of files. The workspace file doesn’t include protocol.c and .h so you need to modify the workspace and files to get it to compile. Also, their python code that you put on the coprocessor takes a while to work. You have to install pyserial to get it to work. You also have to remove their code that lets you use a fake-ifi script because for some reason it just wants to use the fake-ifi. You can execute their example code on your desktop. I hooked up my computer to our RC and hooked up the camera servo assembly. I moved the joysticks and the camera moved. That may not seem like much but all the work was being done through my pc. I then bought a gumstix. I got the code to run on the gumstix but I accidentally fried mine. We eventually decided on a micro-itx motherboard (6.7 square inches). It includes an onboard power supply. We got a flash memory stick that plugs right into the IDE port on the motherboard. We loaded the flash up with the base install of Debian. On power-up Debian retrieves our code from a thumb-drive we have plugged in. It works great so far. Now we in the process of putting together a lightweight case for it so we can mount it on our bot. We are also working out the details of the legality of our coprocessor. The adambots explained what rules it needs to comply with but I’m working on a document that shows everything the coprocessor does (taking on the processing, using the serial port) is perfectly within the bounds of the rules in case anyone has any concerns about whether it breaks any rules.

-Don

[Guy Davidson]

We might try to mess around with AVRs, because we have an STK500 and some chips lying around.

That sounds pretty complex. We might try that at some point, however we don't even have a laptop running linux right now.

Has anyone done more "low-level" co-processor solutions before? How did you interface with the RC? How hard was it to get up and running? What functions did you use it for?

[Tom Bottiglieri]

I would use a co processor (running linux, vxworks, qnx, whatever..) this year as long as the box supported wireless networking and could run interpreters for some scripting languages (python/ruby/perl/whatever).

I think it would make programming, tuning, and debugging a whole lot easier, as you could make changes to the software in real time. Default access to a file system is also handy.

[3dude_2231]

I must say, I don't really see a reason to install a Co-processor,
other than the great (HUGE) educational experience the team could experience.

or, for systems with very little information exchange, such as the StanGPS,
which answers a simple query and returns a simple solution.
"A?" -"0x10 !"


BUT
1) this can be done, and will be educationally-effective only to mature, technically knowledgeable team members.
2 )I wouldn't use such a systems if the entire operation depends on it,
and 3)there are many rules and restrictions around such things.
I assume new teams would want to "keep it simple, stupid" =],
as they fear that even a simple malfunction would spoil their chance to win the regional.


at the bottom line:
I hope I could convince the team to make a commitment to such a responsibility =]

just my 3.50$ ("tree-fidy!")
</brain_wash>

[Guy Davidson]

I think we are going to try doing an entire co-processor solution. Both for the huge educational value it has, and for the technical benefits that having a co-processor will give us. We have a few people aboard who want to make it work, and hopefully enough time to do enough.

One questions to teams who have done it before: A system, be it something like StangPS, or a full-scale co-processor, will have to boot up. Does it start booting up when the robot is turned on, and waits for data from the RC and sensors, or does it only start booting up when autonomous starts?

Thanks

[Tom Bottiglieri]

Everything will boot up as soon as you give it power, unless you design it otherwise. The RC outputs 5v whether or not it is enabled.

[Guy Davidson]

Very awesome. Thank you very much. I'm assuming that also holds for things that are not connected directly to the RC - if our system is connected to the distribution block via a 5v regulator, or something similar, it should also receive power the moment the robot is turned on, right?

[bear24rw]

yep

[Lord_Jeremy]

You know this all seems rather pointless. It is very likely that any effort expended this year will be incompatible with the new RC being designed for the '08 year...

[danshaffer]

With sumadin aka Guy on vacation for Turkey Day, I guess I'll handle this one.
1. Hopefully we can actually avoid a lot of the architecture changes by writing all of our code for an outside platform, then just dealing with their interfacing during the transition.
2. We're Seniors! We want to work hard on some project, whether or not it will be useful next year. We need something exciting to do! Our programming captain-to-be is a very competent person, and should be able to handle next year no problem.
Remember: just because things will change next year doesn't mean that innovation has to take a year off.