Quote:
Originally Posted by GeeTwo
In order to legally make the change you're describing, you would have to have a model in which your external (android) device would send high level/abstract commands to the roboRIO so that the roboRIO could do the low level control.
|
Yup, the flow was gonna be something like
1. Roborio sends data to Android
2. Android does calculations
3. Android sends a table of values for all motor outputs, solenoid states, etc. back to roborio
4. Roborio sets outputs of controllers
Which is why I was concerned about latency
Quote:
Originally Posted by Greg McKaskle
If you see a limit as to how things are being scheduled, it is likely being caused by the framework you are using. I believe that the command-based framework defaults to a 20ms schedule rate.
Also, if you look at the chart tab on the DS, it shows the roboRIO CPU. Unless your CPU is pegged, you don't necessarily need a faster processor, but different code running on it.
Greg McKaskle
|
The reason I was interested in a faster processor was because I wanted to do detailed logging with every iteration of the code, as well as do vision processing onboard, which I was concerned would be too taxing on the roboRIO (though I recognize I could use a setup similar to the poofs)