View Single Post
  #2   Spotlight this post!  
Unread 15-03-2004, 14:27
Astronouth7303's Avatar
Astronouth7303 Astronouth7303 is offline
Why did I come back?
AKA: Jamie Bliss
FRC #4967 (That ONE Team)
Team Role: Mentor
 
Join Date: Jan 2004
Rookie Year: 2004
Location: Grand Rapids, MI
Posts: 2,071
Astronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud ofAstronouth7303 has much to be proud of
Re: Programming Competition: Autonomous Simulator

Here is my idea to implement this:

You submit 4 files (or a zip containing them):
  • A hex with your compiled program
  • A binary containing a DirectX program that describes the shape of your bot
  • An INI describing the positions and conections of motors, sensors, etc.
  • A zip containing source code. (Optional?)

To develop:
  • A program to stream (or just create animation)
  • A virtual macine (figurtively) to run the hex (Or any of the generated files?
  • A simulator to actualy take Output values from VM, apply that to model, add physics, and give the VM Inputs.
  • an optional OI web app? Many auto programs take values from the OI in the disabled time to set modes and such. Also may include an output window/dashboard.

My basic idea to implement the INI file is like this:
  • Only kit parts (or parts inputed by the orginizers) may be used for beginnings and ends for mechanical trains. (Our arm may be difficult, we'll see)
  • there are a series of 'Connectors' or 'Hubs' between mechanical trains (MT) ends/beginigs.
  • the final ratio of a connection (between 2 connected items (Connector, wheel, motor, sensor, etc.)) is given.
  • Also given for each connection is the direction, the driver and the driven.
  • Every connection has to be the driver for at least one connection and the driven for at least one connection.
  • Ideally, the drivers can be back driven be the driven.
    To get specific with items:
  • Each motor has: Type, Polarity, Input (Byte), and Output (RPS)
  • Each potentiometer has: Turns, Input (RPS, a smart pot), Output (10-bit), and pin #
  • Each encoder has: EdgeCount, Input (RPS), Output (boolean), and pin #
  • Each Connector is a collection of objects with: Rate (RPS) and IO (Enum, Input or Output)
  • Each item is smart, and each send/recieve rates to handle for them selves (a pot will increment, a encoder will count).
  • Other sensors (Gyros, line followers) will be handled apropriately.
  • For simplification, Gyros will return rate of known turn, and banners for lines will be perfect.
  • IR servo/sensor combos will have: Position, Valur (Boolean)

This obviously needs to be revised and expanded (not to mention coded!) If we can choose a language, we can start coding.

I know this is going to be complex (No one said it would be easy!), but I think we can rise to the challenge. I await for responses before continuing.