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]

Originally Posted by jee7s

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.