Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Kit & Additional Hardware (http://www.chiefdelphi.com/forums/forumdisplay.php?f=55)
-   -   Parallel Processor (http://www.chiefdelphi.com/forums/showthread.php?t=30896)

Adam Y. 25-10-2004 19:10

Re: Parallel Processor
 
Quote:

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 25-10-2004 19:26

Re: Parallel Processor
 
Quote:

Originally Posted by Adam Y.
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

Adam Y. 25-10-2004 19:39

Re: Parallel Processor
 
Quote:

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 26-10-2004 21:09

Re: Parallel Processor
 
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 26-10-2004 22:27

Re: Parallel 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.

Gdeaver 26-10-2004 23:53

Re: Parallel Processor
 
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 27-10-2004 06:50

Re: Parallel Processor
 
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 27-10-2004 18:11

Re: Parallel Processor
 
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 27-10-2004 18:31

Re: Parallel Processor
 
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 27-10-2004 18:38

Re: Parallel Processor
 
Quote:

Originally Posted by rohandalvi
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 27-10-2004 20:21

Re: Parallel Processor
 
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.


All times are GMT -5. The time now is 01:00.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi