View Single Post
  #47   Spotlight this post!  
Unread 21-04-2012, 11:14
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,624
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: TI and future Jaguars

Quote:
Originally Posted by AustinSchuh View Post
One of the motor controllers that I have used in the past had a language on it that you interfaced to it with. This allowed you to do the basic things like set voltage and stuff, or to do the crazy stuff like custom control loops. The language was basic-like, and pretty simple. This makes it so teams could do whatever they want at the lowest level (1khz custom control loop ftw!), but the kill signal would always be respected.
It occured to me that you might have meant that it had a very simple proprietary motion control language.

My previous statement in reply remains the same. Except you might be able to entirely skip the custom circuit if you keep it simple.

What would need to be done is pick what processor or MCU that langauge would be written for, then create a 'custom control module' or go directly to the interface module design phase with the necessary hardware and a suitable interface(s).

I would think that you'd need to run the language as an interpreter, reading the commands sent to it from the interface, parsing them, then performing the desired actions. Like a shell script (in point of fact if you used a 68k compatible or ARM CPU you could run Linux or ucLinux). This can be done in something as simple as a PIC 16F628 or the Atmel AVR AT90S2313.

Obviously this involves writing basically a new language unless you have specific information about the former language's structure.

At the most simplistic you could create commands like:

SET (BRAKING, RPM, VOLTAGE, CURRENT, PID, POSITION, DIRECTION, LIMITS, VARIABLE, OUTPUT)
READ (ENCODER, SWITCH, VARIABLE) - Note that the difference is one has units and one is raw
OVERRIDE (LIMIT, ENCODER)
RESET
GROUP (SWITCH, ENCODER, MOTOR, CODE BLOCK)
WRITE (CODE BLOCK, STATE, ALL)
UNGROUP (SWITCH, ENCODER, MOTOR)
RUN (CODE BLOCK, BACKGROUND, FOREGROUND)
DEFINE (CODE BLOCK) - Use a start and end delimiter to stream reset of command set
END (CODE BLOCK) - Ends a running code block
TRIGGER (#, CODE BLOCK) - Could trigger on a memory mapped input, encoder reading or event like reset

(20 minutes of dreaming up a new language of commands...200 hours of actually writing it...LOL)
Then you could instruct the system with those commands:
...Set it up so that an actuator performs an action on a trigger on it's own.
...Set it up so that an actuator just goes were you tell it at a fixed speed or with braking, or with a PID control).
...Even create a background process to watch an encoder while while you do other things.

Someone will quickly note that that language lacks decision making and loops. Not a problem because the interpreter is really more a command interpreter like a shell. Inside the processing it defines the common recipes for the loops you would otherwise define in a programming language.

That's quite a project but I wouldn't want to force everyone to use it. In an industrial setting it would be handy, but in an educational setting it would sort of reduce the amount of thought involved. Still obviously it's within the practical capability to achieve it. In some ways that would drag a lot of the functionality of the cRIO into this system.

Last edited by techhelpbb : 21-04-2012 at 12:28.
Reply With Quote