A web config tool to be hosted on the roborio with several team code infrastructure diagnostics
json will be used for most things
The robot code binary is located at /home/lvuser/
.
FRCUserProgram
- Robot Code binary run at startup by the roboriodman/
- Working directory for the application
The working directory is /home/lvuser/dman/
. Within it is the manifest file and several subdirectories
manifest.json
- This is a file containing file paths to various files.autonomous/
- This directory contains all autonomous scriptsports/
- This directory contains all port configscontrols/
- This directory contains all controller bind profilessettings/
- This directory contains all user-defined config fileslogs/
- This directory contains all previous logs and a ledger of all logsbinaries/
- This directory contains all versions of the robot code binary and a ledger/table of info on each one
The manifest file contains the following attributes
templates
- Contains file paths to template filesconfigs
- Contains template file paths for configs (ports/controls/settings)ports
- Path to ports template filecontrols
available
- Path to available controls filerequirements
- Path to required controls file
settings
- Path to settings template filelog-config
- Path to log config template fileruntime
- Contains file paths to files loaded by robot code at startconfigs
- Path to configsports
- Path to the json file containing component port labelscontrols
- Path to the json file containing the controller binds profilesettings
- Path to the json file containing end-user-defined settings for the robot configurationlog-config
- Path to the json file containing log configuration
autonomous
- Path to the lua script for autonomous modebinary
- Path to the binary being runserver
- Settings related to the appweb-root
- Path to web rootport
- Port to listen on
Configuration files encompass controls, ports, settings, and anything miscellaneous that fit into this category. They are stored as json files.
These are files generated by the robot code which specify the data which need to be included in the configuration file. These are read by the manager app in order to generate the web interface allowing the user to edit the config files. For example, in ports/template.json is a layout of the names of hardware components on the robot as well as the range of port numbers or IDs which they can be mapped to.
The following explains the structure of the ports/template.json file generated by the robot code. The file is an array of "port spaces". A port space is essentially a type of input that has its own set of ports, e.g. CAN Bus IDs are enumerated independently from solenoid outputs or digitial input-output pins.
- Port Space Object
name
: The name of the port space"[CAN|DIO|solenoids|pwm|analog-in]"
min
: Minimum port or id used in this spacemax
: Maximum port or id used in this spacekeys
: An array of either strings which correspond to hardware components that have an independent port or objects which correspond to a named subset of the port-space, simply organizational.
The following explains the structure of the settings/template.json file generated by the robot code. The file contains an object with a single member
subsystems
: Array of conceptual subsystems containing settings which pertain to themname
: Name of the subsystem or settingvalues
: Array of settings or subsystemstype
: Specifies the type of data the setting is. If this is null or undefined then this object is a subsystem."[integer|float|boolean|string|null]"
The following explains the structure of the controls/requirements.json file generated by the robot code. The file contains data which tells the configurer the commands and systems on the robot which require a teleoperated input to be bound to them. At the root is an array of subsystem objects.
- Subsystem object
name
: Name of the subsystemcontinuous-inputs
: Array of continuous action objects. These are robot components which require updated input every frame, such as the drive base and most other analog controls.name
: Name of the action requiring controltype
: Type of parameter needed"[analog|digital]"
commands
: Array of command objects. These are processes which can be bound to a trigger.name
: Name of the command
The following explains the structure of the controls/available.json file generated by the robot code. The file contains data which tells the configurer which inputs are available to be bound to commands and such on the robot. At the root is an array of input space objects
- Input space object
name
: Name of the input space object (e.g. "joysticks")ids
: The presence of this object means that this input space has several of the same type of input which are ID'd by the scheme described in the object. One example of this would be the multiple joysticks.min
: Minimum IDmax
: Maximum IDnames
: Array of strings corresponding to possible named idstypes
: An array of input space objects. The presence of this array means that there are multiple types of inputs on the same ID space. e.g. joysticks and gamepads.digitals
: An array of strings corresponding to various "digital" inputs (swithces or buttons)analogs
: An array of strings corresponding to various "analog" inputs (joysticks axes or analog sensors)
The web config is responsible for outputting a json file which is read back into the robot code to tell it how things are bound or configured. The robot code also generates a default.json along with the templates so that it can read in default behavior as well as provide the web config with a default value.
The following explains the structure of the ports/default.json file generated by the robot code. This file serves as a model for other output control configs as well. At the root is an object with two members
binds
: Object which contains subsystem objects, named bycontrols/requirements.json
- Each subsystem object a series of commands or action objects, known to the robot by the key
- Each command or action object contains info on the nature of the bind
source
: Either an object or id of an object which corresponds to an input sourceinput
: Address of the input. Each input space is separated by a slash. The available inputs are defined incontrols/available.json
. For input sources which have types as well as IDs, the type is referenced first, and then the ID. For example:joysticks/joystick/0/y-axis
sources
: An array of sub-source objects. Its manipulation depends on the other variablessource
: A sub-source object. Its manipulation depends on the other variablestype
: Defines the type of sourcenull
: If the type is null it is just a direct input sourcetoggle
: This requires there to be a booleansource
object or input in the source. This specifies that the value of the source flips every time the source switches from true to falseand
: This requires there to be an underlyingsources
array in the source. This specifies that the value of the source is true if all of the elements in thesources
array are also trueor
: Same asand
but is true if any of the underlying sources are truenone-of
: Same asand
but is true if none of the underlying sources are truecompare
: This requires there to be acomparison
member as well as either asource
orinput
.
comparator
: Value of the same type as the input which is compared to the inputcomparison
: If the source is of typecompare
this specifies how the input is compared. It supports:">", "<", ">=", "<=", "==", and "!="
poll
: This specifies the event which leads to the command being runonTrue
: Runs the command when the source becomes trueonFalse
: Runs the command when the source becomes falseonSwitch
: Runs the command when the source changes
- Each command or action object contains info on the nature of the bind
Most of the subdirectories are simply just a collection of various versions of the file associated.
Most also have a template.json
which is generated by the robot code client which contains a template of the values and defaults requested by the robot code at initialization. This is used by the web app to assist in initializing values in a new or outdated config.
The logs/
directory contains several more directories indexed by run time. Each will contain a copy of the manifest.json
used for that runtime at startup. Each log directory will also contain a console.log
containing the formatted log output.
timestamp: <message_type-verbosity> [system][component_name][component_type]: message
timestamp
- Time in milliseconds since program startmessage_type
- Eitherstatus
,info
,warn
,error
, orfatal
verbosity
- Integer. The higher the number the more verbose. Used for filtering by importancesystem
- System generating the message. e.g. "Drive", "Lifter", etc.component_name
- Name of component within system. e.g. "Right Front Motor", "Piston", etc.component_type
- Type of component e.g. "Talon", "Solenoid", etc.
The binaries/
directory contains all versions of the robot code binary, as well as ledger.json
which contains info about each. Attributes will be things such as git-commit, date built, user-notes.