Valor 6800 1.0
Loading...
Searching...
No Matches
valor::BaseSubsystem Class Reference

Abstract class that all Valor subsystem's should implement. More...

#include <BaseSubsystem.h>

Inheritance diagram for valor::BaseSubsystem:
valor::Loggable valor::Swerve

Public Member Functions

 BaseSubsystem (std::string name)
 Construct a new Valor Subsystem object.
 
virtual void analyzeDashboard ()
 Synchronize dashboard data (both read and write)
 
virtual void assessInputs ()
 Read controller logic and set subsystem state.
 
virtual void assignOutputs ()
 Read subsystem state and send motor commands.
 
virtual void reset ()
 Reset all subsystem state.
 
void setGamepads (valor::Gamepad *_operatorGamepad, valor::Gamepad *_driverGamepad)
 
- Public Member Functions inherited from valor::Loggable
void LogChild (std::string_view name, Loggable *child)
 Register a child Loggable under a named subtree.
 
void LogChild (std::string_view name, wpi::Sendable *child)
 Register a child Sendable under a named subtree.
 
void setLoggingPeriod (units::millisecond_t period)
 Set the minimum period between LoggablePeriodic() invocations.
 
template<>
decltype(Loggable::subscribers) ::iterator addSubscriber (std::string_view field, const std::vector< bool > &defaultValue)
 
template<>
void WriteLogImpl (nt::Publisher *pub, const std::vector< bool > &data)
 
template<>
std::vector< boolReadLogImpl (nt::Subscriber *sub)
 

Protected Attributes

valor::GamepadoperatorGamepad
 
valor::GamepaddriverGamepad
 

Additional Inherited Members

- Static Public Member Functions inherited from valor::Loggable
static units::millisecond_t GetLoggingTime ()
 
- Protected Member Functions inherited from valor::Loggable
 Loggable (std::string_view name)
 Construct a Loggable that registers a top-level table name.
 
 Loggable ()
 Default construct an uninitialized Loggable.
 
virtual ~Loggable ()=default
 Virtual destructor.
 
virtual void OnLoggingStart ()
 Hook invoked when logging is started for this object.
 
virtual void LoggablePeriodic ()
 Periodic callback for logging updates.
 
template<typename T >
T WriteLog (std::string_view field, const T &data)
 Publish a value to NetworkTables under the given field.
 
template<typename T >
ReadLog (std::string_view field, const T &defaultValue={})
 Read a value from NetworkTables for the given field.
 

Detailed Description

Abstract class that all Valor subsystem's should implement.

To make developer's lives easier and to prevent any mistakes in a quick build season, BaseSubsystem is used to organize code and abstract a lot of the base code that is often repetitive in all subsystems.

Valor Subsystem implements the FRC WPILib Subsystem class and therefore has all baked in features from WPILib.

The idea is that subsystems on the robot implement BaseSubsystem and logic for that subsystem is broken out into 3 different functions:

  • assessInputs
  • analyzeDashboard
  • assignOutputs

Every 20 milliseconds when the robot is on, the functions will run in order if the robot state matches what is in the table below: Robot State | assessInputs | analyzeDashboards | assignOutputs ---------—|-----------—|----------------—|-----------— Disabled |

|

|

Auto |

|

|

Teleop |

|

|

Descriptions for each function and their intent is listed in the function description

Constructor & Destructor Documentation

◆ BaseSubsystem()

valor::BaseSubsystem::BaseSubsystem ( std::string name)
inlineexplicit

Construct a new Valor Subsystem object.

Sets up the infrastructure so that the various robot modes will automatically call the proper function. This NEEDS to be called from the constructor of every subsystem.

Parameters
nameA human readable name of the subsystem

Member Function Documentation

◆ analyzeDashboard()

virtual void valor::BaseSubsystem::analyzeDashboard ( )
inlinevirtual

Synchronize dashboard data (both read and write)

The analyzeDashboard function runs at all times (disabled, auto, and teleop). The intent of the function is to send sensor and state information from the robot to the Driver Station for debugging. Additionally, driver commands and data can be sent from the Driver Station to the robot and collected in this function.

ALL network table and sensor logic should be in this function as both network table and sensor information should be read at all times, not just during teleop since auto will never get that information.

This function is a virtual function and should be implemented by the subsystem.

Reimplemented in valor::Swerve.

◆ assessInputs()

virtual void valor::BaseSubsystem::assessInputs ( )
inlinevirtual

Read controller logic and set subsystem state.

assessInputs only runs during teleop and should be used to convert driver/operator inputs into subsystem state. Since this function only runs during teleop, driver/operator inputs in auto are ignored which is completely okay. Instead, our auto commands will mimic driver input and set the states.

Note that state should not be READ in this function, and instead should only be WRITEs. This is because using previous state will occur in assignOutputs when determining what values to send to motors.

Suggested flow:

  • Read inputs from driver/operator
  • Set state based on those inputs in if statements
    • The higher up in the if statement, the higher the priority of the state

This function is a virtual function and should be implemented by the subsystem.

◆ assignOutputs()

virtual void valor::BaseSubsystem::assignOutputs ( )
inlinevirtual

Read subsystem state and send motor commands.

This function runs during teleop and auto, but not disabled. This is because the function is intended to control motors and should not send motor outputs when the robot is disabled. assignOutputs should read the subsystem state set in assessInputs and analyzeDashboard and create motor commands.

Note that state should be READ and not be written to (the opposite of assessInputs). The big rule to obey with this function is that other subsystem's state should never be written to. For example, if sensors in subsystem A determine outputs for subsystem A AND subsystem B, then the sensor should live in both subsystems instead of subsystem A trying to write results in subsystem B. This will make logic easier to understand for all developers.

Suggested flow:

  • Read subsystem state
  • Set motor output based on those states in if statements
    • The higher up in the if statement, the higher the priority of the motor output

This function is a virtual function and should be implemented by the subsystem.

Reimplemented in valor::Swerve.

◆ reset()

virtual void valor::BaseSubsystem::reset ( )
inlinevirtual

Reset all subsystem state.

Use this function to set the subsystem state to default values, as well as set the motor outputs to 0 so the robot doesn't "lurch" when booting up due to phantom state (aka. state that was previously set but hasn't been reset yet).

This function is a virtual function and should be implemented by the subsystem.

Reimplemented in valor::Swerve.


The documentation for this class was generated from the following file: