|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools |
Rating:
|
Display Modes |
|
#29
|
||||
|
||||
|
Re: TI and future Jaguars
After some lunch I realized I should probably clarify why the motion control command interpreter I outlined above would have to have a module at all.
In theory with the open (non-FIRST) firmware for the Jaguar you could already implement that. In theory you could write a library, a software module, a component for LabView, or even a converter for the command line that takes that more stylistically familar lanaguage and shorthand for grand motion control functions and breaks it down to something more practical to implement in existing languages. In theory to conserve memory on the module you could also do what Java and Parallax pBASIC interpreters do and compile what you write down to simplier more compact form (byte-code) while checking it for errors. You could then upload that to the module. Here's the thing, you could essentially take an existing CAN module for example (assuming it already existed any place accept our heads) and change out the software within it for this motion control language. Just like you could do with the Jaguar (in fact a great deal of what I described above is already in the Jaguar...so it's a short reach...the Jaguar is just a little less developed in language right now). The problem that will crop up is that FIRST is going to want to approve something so they'll need to see something tangible in operation. If you create something for one or many existing modules on a PC and it doesn't change the possibly already approved software in that module then it shouldn't be a problem. However, if you alter the module's software you the open proverbial can of worms. If you tried to create a piece of alternate firmware for existing modules you'd create quite a few new things FIRST would have to evaluate and possibly that would mean dragging you as the motion control langauge developer into the module designer's approval process. That's a lot more variable concerns for something otherwise simple. So the fastest way I can figure you'd break that self-feeding complexity would be to make a module that is the exact hardware you desire so you don't have to worry about someone else using different processors or MCU and then you having to port your work to their changes and then getting everything approved again. It's a lot more direct if you simply absorb someone's module design or make one yourself and bundle it with your motion control language (in programming terms fork their project). If you absorbed an existing module they are free to develop as they like and even change hardware. You are free to develop as you like and even tinker with the hardware. Unless of course FIRST will award you approval process coopertition points. ![]() Last edited by techhelpbb : 21-04-2012 at 13:07. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|