Conversation
Currently we use Shuffleboard for our dashboard on the driver station. The Driving network table contains all the data that we can push (which does not include from the SendableChooser and the Limelight camera feed) that the drive team needs to run a match. This table should be reserved for this purpose alone, as currently we simply push any data we may need during testing with SmartDashboard. As I understand, Shuffleboard allows us to use data from other tables on the same page as the ones specifically for it, and we can set up a nice view that will remain persistent between reboots of the robot and not be cluttered with data the drive team does not need.
|
I approve, contingent on it working in testing |
|
I'm going to reiterate what we discussed last night so we have it written down in case the subject comes up again. We would rather use SmartDashboard only if possible, because it does not have memory leak problems like Shuffleboard does, and if something goes wrong with Shuffleboard at a competition we need to use SmartDashboard which cannot access other tables besides its own. Another thing to note is that we do not have the ability to send SendableChooser equivalents to other tables (yet?) and we need to learn how they operate and how we can replicate them if we want to switch to another Dashboard and table in NetworkTables. As I understand we are also going to encapsulate any programming specific pushes to SmartDashboard under a macro so that we can recompile and not be sending data the drive team does not need. |
From rationale commit:
Currently we use Shuffleboard for our dashboard on the driver station. The Driving network table contains all the data that we can push (which does not include from the SendableChooser and the Limelight camera feed) that the drive team needs to run a match. This table should be reserved for this purpose alone, as currently we simply push any data we may need during testing with SmartDashboard. As I understand, Shuffleboard allows us to use data from other tables on the same page as the ones specifically for it, and we can set up a nice view that will remain persistent between reboots of the robot and not be cluttered with data the drive team does not need.