Thread: Co-Processor?
View Single Post
  #3   Spotlight this post!  
Unread 07-11-2007, 03:36
Guy Davidson Guy Davidson is offline
Registered User
AKA: formerly sumadin
FRC #0008 (Paly Robotics)
Team Role: Alumni
 
Join Date: Mar 2005
Rookie Year: 2005
Location: Ra'anana, Israel
Posts: 660
Guy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to beholdGuy Davidson is a splendid one to behold
Send a message via ICQ to Guy Davidson Send a message via AIM to Guy Davidson Send a message via MSN to Guy Davidson
Re: Co-Processor?

Up until now I have just avoided floating point math by using integer approximations and making sure I am multiplying before I'm dividing (and that my data types are big enoguh for the type of numbers I expect to see).

Actually, we're messing around with some neat ways to do software (or even mostly hardware) hande much of the encoder data, and just give the RC velocities or some other easier (on the system) type of data via a serial or a digital input. If that works, and works well, we might try and apply the same solutions to an ultrasonic sensor or a gyro. Money investment should and probably won't be the limiting factor for this projcet (while obviously not spending money just because we can).

I am not sure we have exceeded the capacity of the RC. Is there any good way to test that? It should probably change based on weather or not we're using WPILib, which we plan to use.

Seeing as I do not know what would exceed the capacity of the RC, I'm not sure if there's a chance of that happening.

Remote programming is definitely not a necesity, or the reason why we'd implement a co-processor.

The experience, however, might be a bigger factor.