Parallel Processor

[rohandalvi]

Does anybody know what is a good parallel processor to use, where I can get it from, and whether it come with code? My team (1414) is thinking of using parallel processing but we need some outside input, does anybody have any experience wiht parallel processors and what is best? Thanks...

[Gdeaver]

You probably mean coprocessor not parallel processor. There are many choices. You could use a basic stamp. It was the processor in the old robot controller. However, your team would have to figure out how to handle the communications between the robot controller and the co processor. Do you have a Mentor that could help?

[rohandalvi]

Originally Posted by Gdeaver

You probably mean coprocessor not parallel processor. There are many choices. You could use a basic stamp. It was the processor in the old robot controller. However, your team would have to figure out how to handle the communications between the robot controller and the co processor. Do you have a Mentor that could help?

we have a mentor that know some stuff about programming. However, would you just connect the robot controllers together or would you have to place the processor in a new housing?

[Dave Flowerday]

Originally Posted by rohandalvi

My team (1414) is thinking of using parallel processing but we need some outside input, does anybody have any experience wiht parallel processors and what is best?

Using a second processor on the robot and having it talk with the main Robot Controller isn't the hardest thing in the world but it's not trivial either. If you don't have someone on your team who is pretty familiar with embedded microcontrollers then it could be difficult. Also, debugging communications problems between the two processors without the right equipment can sometimes be a challenge. All of this leads me to my question: why do you think you need a second processor? It could be a great learning experience, but on the other hand if you don't have a specific need for it then you might just end up putting yourself through a unecessarily frustrating experience. Also, if you let us know why you need a second processor it will put us in a better position to recommend one to you.

As for our team, we have used a Motorola HC08 series microcontroller on our robot for the last 3 years. It's a pretty simple processor to design a circuit for and all the tools you need to program it are available for free.

[Joe Ross]

What is your purpose for using a second processor?

[rohandalvi]

I need to double-check with my team members and get back to you; but I am pretty sure that we are going to be using one processor for steering and driving, and another for the arm or whatever extension is needed

[Jeff_Rice]

All you need to do is just make another function to handle the arm. A coprocessor would create a lot of work (debugging communications, etc.); it seems like it would be overkill in this instance.

[Rickertsen2]

I don't see any reason you need a coprocessor for these tasks. The processor built into the controller is more than adequite for basic robot controlling. The only reason for a coprocessor is if you are doing very sophisicated navigation, feedback control loops etc. Last year we had a coprocessor to handle all of our navigation. We chose to use another PIC because we were already familiar with them and so that code snippets could be interchanged between the RC and our coprocssor. Specifically we used a PIC18F252. Again unless you are doing something very special and have some sort of experience with embedded design and programming i would strongly caution against a second procssor.

[rohandalvi]

Ok. we need a coprocessor for a faster response time. With the current FIRST processor, the response to a touch sensors feedback is 30ms. We need to bring that down to 10 or 15 at most. Also we will use the basic FIRST CPU for the drive system
and we feel we need more processing power for the autonomous mode line
tracking and also for handling the sensor feedback during arm control.

As the arm moves, the forces change with the angle and hence we need to
crunch quite rapidly the angle as per a potentiometer output and the power
output of to the motor. Equally, when the arm is stopped at any position
other than straight down or straight up, we need to apply a variable amount
of motor breaking to resist the force of gravity. We learnt that the FIRST
CPU was not up to the frequency of calculations we require to make the
programming work properly.

[Gdeaver]

You might look at http://kronosrobotics.com/xcart/customer/home.php. The Dios chip is of the pic 18f family. They sell carrier board kits to make it easier to hook every thing up. They also have some app notes on a rs485 interface that may help with the communications issue. The chip is programed in basic with support for inline assembler if you need it. There are coprocessor functions in the language but, you would have to duplicate them on the robot controller. Still not sure you really need a coproc. The items you mentioned don't sound that intensive. As for the arm being back driven, worm gears are very good at preventing this. Both the van door and window motors are worm designs. We choose the window motor last year with additional reduction and had no problem with back driving. Our arm could reach the tall goal and place the ball when our drivers where on. I always prefer to handle problems with mechanical design instead of trying to correct deficiencies with programming.
Gary Deaver

[Joe Ross]

Your problem isn't the speed of the processor, but the structure of your program. Have you read the Programming reference manual?

Default_Routine will only be called every 26ms. Process_Data_From_Local_IO will be called every program loop, which will be much more often (the PIC is actually quite fast). You can also use a timer to call your routine at a fixed rate, such as 100hz.

Even then, the PWMs won't be updated unless you use the fast PWMs.

Definetly read through ALL the documentation, and if you still have questions, ask. The PIC should be more then fast enough for what you want to do. Even if it wasn't, a coprocessor wouldn't help at all the way your program is written now.

[Max Lobovsky]

The topic of optimizing code to run faster is a huge one, but one big piece of advice I can give you is do not use floating point operations and try not to use division. Also, use 8bit operations whenever possible. With some clever math, you can very often do what you want without using floating point operations.

[Alan Anderson]

Originally Posted by Max Lobovsky

The topic of optimizing code to run faster is a huge one,...

In rohandalvi's case, the appropriate "optimization" is almost certainly just a matter of putting the code somewhere it will run more often than the ~38 Hz communication rate. The touch sensor is "local I/O", and thus ought to be processed in the Process_Data_From_Local_IO() function.

Our simple wheel speed sensor was polled in Process_Data_From_Local_IO(), and the code kept up just fine with a signal that changed every 8 ms under normal conditions. I didn't put in any instrumentation to measure the timing precisely, but I did verify that Process_Data_From_Local_IO() ran at least twice every four milliseconds.

[Max Lobovsky]

Originally Posted by Alan Anderson

In rohandalvi's case, the appropriate "optimization" is almost certainly just a matter of putting the code somewhere it will run more often than the ~38 Hz communication rate.

I was referring to this part of his explanation when I suggested some ways to optimize code:

Originally Posted by rohandalvi

Also we will use the basic FIRST CPU for the drive system
and we feel we need more processing power for the autonomous mode line
tracking and also for handling the sensor feedback during arm control.

As the arm moves, the forces change with the angle and hence we need to
crunch quite rapidly the angle as per a potentiometer output and the power
output of to the motor. Equally, when the arm is stopped at any position
other than straight down or straight up, we need to apply a variable amount
of motor breaking to resist the force of gravity. We learnt that the FIRST
CPU was not up to the frequency of calculations we require to make the
programming work properly.

[Rickertsen2]

Originally Posted by rohandalvi

Ok. we need a coprocessor for a faster response time. With the current FIRST processor, the response to a touch sensors feedback is 30ms. We need to bring that down to 10 or 15 at most. Also we will use the basic FIRST CPU for the drive system
and we feel we need more processing power for the autonomous mode line
tracking and also for handling the sensor feedback during arm control.

As the arm moves, the forces change with the angle and hence we need to
crunch quite rapidly the angle as per a potentiometer output and the power
output of to the motor. Equally, when the arm is stopped at any position
other than straight down or straight up, we need to apply a variable amount
of motor breaking to resist the force of gravity. We learnt that the FIRST
CPU was not up to the frequency of calculations we require to make the
programming work properly.

I feel that you can easily acheive all of this using only the RC. you are NOT limited to 38.2hz. This is a frequently confused issue. The 38.2hz(26.2msec) is the minimum frequency at which you must call Putdata() function and not be disabled by the master uP. Using Interrupts and user generated PWMs, you can get WAY under the 10-15ms you mention. As far as line tracking goes, the processor could perform enven the most sophisticated line following algorithms in its sleep. This leaves you plenty of processor time for your arm feedback algorithms. Most teams use coprocs for mathematically intensive operations such as guidance calculations based on wheel encoders and accelerometers. None of what you mentioned above is really that demanding except your arm feedback control depending on how sophisticated algorithm you are using.

The processor will not be the bottleneck in reading your touch sensors. You MAY have problems with the speed controllers and especially the relays. They relays take time to switch and the speed controllers take time to send a signal to. The relays update immediately, but they take time to switch. Typical relays take anywhere from .5msec for small reed relays to 50msec and up for large power relays. I don't know the specific activation and release time for the relays inside he spikes, but looking at similar relays i would guess from 15-25msec. The speed controllers have another problem. It takes between 1.0 and 2.0 msec just to send a command to the speed controllers. There may also be a latency between when the speed controller revieves a signal and when it outputs. Let me ask you this: What is soo critical about these touch sensors that they must be responded to soo quickly?

The some care and code trickery, you should be able to run everything you mentioned above on the RC alone with a good safety margin.