PDA

View Full Version : Parallel Processor


rohandalvi
10-23-2004, 03:47 PM
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
10-23-2004, 04:39 PM
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
10-23-2004, 07:06 PM
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
10-23-2004, 09:10 PM
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
10-23-2004, 09:13 PM
What is your purpose for using a second processor?

rohandalvi
10-24-2004, 08:17 AM
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
10-24-2004, 11:07 AM
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
10-24-2004, 12:31 PM
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
10-25-2004, 05:49 AM
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
10-25-2004, 07:20 AM
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
10-25-2004, 08:26 AM
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
10-25-2004, 12:38 PM
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
10-25-2004, 01:07 PM
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
10-25-2004, 02:11 PM
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:
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
10-25-2004, 05:45 PM
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.

Adam Y.
10-25-2004, 06:10 PM
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?
You bring up a very good point. You have to be very very careful with timing when programming the robot. If you program the robot to be too sensitive a problem known as hysteresis will appear. This is due to the latency caused by the motors (backlash-motor starts moving before the shaft moves), speed controllers, sensors, and probably even the microcontroller (I wouldn't know since I don't know how to program the pic). A good example of hysteresis is programming a heater to turn on exactly at a specific temperature. It would constantly want to turn on and off every little heat change. Usually, hysteresis is corrected by adding a dead band to the programming. This is essentially an area where it you decide that it's clse enough. Also, what type of relays are actually in the spikes. Are the phsyical relays or solid state relays.

Rickertsen2
10-25-2004, 06:26 PM
You bring up a very good point. You have to be very very careful with timing when programming the robot. If you program the robot to be too sensitive a problem known as hysteresis will appear. This is due to the latency caused by the motors (backlash-motor starts moving before the shaft moves), speed controllers, sensors, and probably even the microcontroller (I wouldn't know since I don't know how to program the pic). A good example of hysteresis is programming a heater to turn on exactly at a specific temperature. It would constantly want to turn on and off every little heat change. Usually, hysteresis is corrected by adding a dead band to the programming. This is essentially an area where it you decide that it's clse enough. Also, what type of relays are actually in the spikes. Are the phsyical relays or solid state relays.
They make a clicking sound. They are definately mechanical. IFI does however sell a solid state version (http://ifirobotics.com/ssr.htm), buts its not used in FIRST and has a nominal current capacity of only 7A vs. 20A for the mechanical version. As far a i can see, its only advantage is that it is rated for up to 60v while its mechanical counterpart is only rated for 15V

Adam Y.
10-25-2004, 06:39 PM
They make a clicking sound. They are definately mechanical. IFI does however sell a solid state version, buts its not used in FIRST and has a nominal current capacity of only 7A vs. 20A for the mechanical version. As far a i can see, its only advantage is that it is rated for up to 60v while its mechanical counterpart is only rated for 15V
Im amazed that there haven't been mechanical relay problems with the spikes then which is why I asked the question in the first place. Usually mechanical relays have a limited off-on lifetime which would mean that the older relays would become less and less reliable until they actually die. Also the possibility of shorting the relays so that they are always on which probably would never happen since there are fuses on the actually relay. IFI lists there relay type as H-Bridge which is confusing because it really doesn't explain what type of relays they use unless Im missing something. Anyway we can spin this off into another topic since this is on parallell processing.

rohandalvi
10-26-2004, 08:09 PM
ok, thanks to everyone for your help. Our team never knew that we could optmize all of this stuff through just the code. However, we want to use a co-processor as a backup in case we run into a problem with the current processor. We are trying to develop a compass based guidance system which relies on touch sensors to identify obstacles, readjust the robots position, and to compute a re-adjusted route so the robot does not go off track. We need the co-processor to be able to do this very quickly. However, we need to look into the fact of optimization through code. If all else, fails, then we will use the co-processor.

Gene F
10-26-2004, 09:27 PM
I just today got a card from Microchip announcing a sale on their demo boards. Only $49. It uses the same family Micro as the RC but one step more program space and RAM. Their site is
www.microchip.com
You'll need to find tools somewhere, the ones you get from Innovation First only works with the robot controller. You can get the same tools but enabled for the new processor from Microchip but I don't know the cost, check the site.

Gdeaver
10-26-2004, 10:53 PM
Compass based navigation. I'm curious as to what digital compass your looking at. Most of the ones I've seen are fairly slow as to the number of updates per second. (less than 100 HZ). Can't see where all the computing horsepower is needed. Care to give any more details?

rohandalvi
10-27-2004, 05:50 AM
well, our engineering sub-team is still working out which would be the best one for the robot (small size, durable, etc.). So i am not too sure on that, however I am sure that we will be using a digital compass. I'll check with engineering and get back to you on the brand.

rohandalvi
10-27-2004, 05:11 PM
Ok here's the link to the compass we will be using: http://www.pnicorp.com/family?nodeId=c1b

as you can see its pretty cheap and the second one has a built-in microprocessor so we might be able to use that.

Max Lobovsky
10-27-2004, 05:31 PM
Apparently, Gdeaver made a good point about low number of updates per second. These compasses apparently output 2.5 or 5 outputs per second. That gives you a lot of time to do calculations. I really can't imagine an application of this that you could not do on the 40 MIPS processor in the RC.

Joe Ross
10-27-2004, 05:38 PM
Ok here's the link to the compass we will be using: http://www.pnicorp.com/family?nodeId=c1b

Have you verified that compass is availible from one of the allowed suppliers?

rohandalvi
10-27-2004, 07:21 PM
well ,we are not going to be using it on the real robot, we just want to use it on the practice robot and check it out. Maybe, if it is good, then we will consider using it in other applications, which I am sorry, but I am not at liberty to discuss.