Quote:
Originally Posted by Ether
Joe, are you saying that you rewrote your 2012 LabVIEW code in Java using the command-based approach and successfully ran it on the robot?
|
Yes.
Quote:
Originally Posted by Ether
Could the "huge, overly complicated, state machine in LabVIEW" have been partitioned and cleaned up to give results similar to the Java command-based system, or does LabVIEW not readily lend itself to that?
|
It certainly could be cleaned up to much better then it is now, but it wouldn't be as clean as the Command based code. There's a lot of stuff going on in the background that makes the Command based code easier to use. I'm sure something similar could be implemented in LabVIEW, but it would take someone fairly skilled in LabVIEW to make it easy enough for a novice LabVIEW programmer to use.
Quote:
Originally Posted by otherguy
The scheduler only interfaces with the commands. Commands then interface with the methods of a subsystem.
The state of a subsystem is kept track of by the subsystem.
The state of a command sequence is kept track of by the commands and scheduler.
A subsystem only knows how to interact with itself. It can turn a motor on/off, it can read the status of a sensor. Alone, it doesn't do you much
|
I do agree that in most cases the subsystem can update it's state in response to command.
There are sometimes that the state of a subsystem needs to be periodically updated, and isn't (necessarily) the result of a command. For example, consider a chassis subsystem that is keeping track of of the X-Y Location of the robot on the field using encoders and a gyro. The location may change when the robot isn't supposed to be moving, because the robot may be bumped. In order to get accurate results, you need to operate on small enough timesteps of data. If you don't have a command that is calling the updateLocation method, you will lose data.