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…
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?
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.
What is your purpose for using a second processor?
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
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.
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.
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.
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
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.
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.
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.
I was referring to this part of his explanation when I suggested some ways to optimize code:
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.
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.
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
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.
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.
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.