View Single Post
  #15   Spotlight this post!  
Unread 25-10-2004, 18:45
Rickertsen2 Rickertsen2 is offline
Umm Errr...
None #1139 (Chamblee Gear Grinders)
Team Role: Alumni
 
Join Date: Dec 2002
Rookie Year: 2002
Location: ATL
Posts: 1,421
Rickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant futureRickertsen2 has a brilliant future
Send a message via AIM to Rickertsen2 Send a message via Yahoo to Rickertsen2
Re: Parallel Processor

Quote:
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.
__________________
1139 Alumni

Last edited by Rickertsen2 : 25-10-2004 at 18:56.