From a991afe93bf73e4bdcb4532faaea608aea81e6e9 Mon Sep 17 00:00:00 2001 From: codetoad Date: Mon, 24 Feb 2025 23:24:00 -0500 Subject: [PATCH 1/4] added information about the Inputs in subsystem logging --- docs/subsystem-logging.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/subsystem-logging.md b/docs/subsystem-logging.md index da84eee..600a3c2 100644 --- a/docs/subsystem-logging.md +++ b/docs/subsystem-logging.md @@ -182,8 +182,16 @@ Starting off simple, all the `InputProvider` classes do is provide a common inte ### Inputs +<<<<<<< HEAD Inputs contain the actual fields that are being logged. +Similar to Command Logging, we want to maintain a tree like structure for our Inputs. To do this, each Inputs extends `FolderLoggableInputs` which in turn extends `LoggableInputs`. + +`FolderLoggableInputs` takes in a folder that is describes the hardware it is logging. You can name this what ever you want but I would recommend just putting the class name of the subsystem. + +!!!note + This folder can have subfolders separated by a / + There are two different ways of creating `LoggableInputs`. The *Legacy* method involves extending `FolderLoggableInputs` and declaring the properties by hand and how they are written and read from the log. @@ -228,6 +236,18 @@ class PidMotorInputs { Every `FolderInputs` (and subclasses) are in charge of logging the values that were selected using the builder. +So far it has been pretty simple, but how do we get to the different customizable inputs like `NeoPidMotorInputs` you may ask. + +There is another class that all the customizable Input classes extend, and that is `FolderInputs` (poorly named). + +All `FolderInputs` does is declare an abstract method called `process(InputProvider inputProvider)`. + +Ohhhh, I hear you say so that is where the `InputProvider` comes into play! + +The process method will then be called by IO Interfaces, with the corresponding `InputProvider`. + +As mentioned in [How to log a Subsystem](#how-to-log-a-subsystem), the two `FolderInputs` implementations are `MotorInputs` and `PidMotorInputs`. + ### InputBuilders Each InputBuilder is contains methods that set a flag indicating if the user wants to log a specific value. For example `MotorInputBuilder#encoderPosition` sets a boolean to `true` indicating that the `encoderPosition` should be logged. From 660a95f5efa97037fc6ee0091fe1ee04833bc1da Mon Sep 17 00:00:00 2001 From: codetoad Date: Mon, 24 Feb 2025 23:31:04 -0500 Subject: [PATCH 2/4] added information about calling command.setParent() --- docs/command-logging.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/command-logging.md b/docs/command-logging.md index 2afcd1e..3e050c2 100644 --- a/docs/command-logging.md +++ b/docs/command-logging.md @@ -104,3 +104,28 @@ The `CommandLogger` works by subscribing to some of the events of WPILib's `Comm 3. `onCommandInterupt(Consumer action)` On each of these events, we store the recorded state in a queue which then gets logged every tick. + +## Advanced Use cases + +Sometimes it is convenient to create and schedule and command within another command. + +Take the following example, where we create a command that goes to a position. + +```java +public void initalize(){ + LoggableCommand command = new GoToPoseCommand(drivetrain); + command.schedule(); +} +``` + +This will work but when we are looking for the command in AdvantageScope, it may make more sense to see the `GoToPoseCommand` listed under the command who called it. + +This can be done by calling `command.setParent(this)`. + +```java +public void initalize(){ + LoggableCommand command = new GoToPoseCommand(drivetrain); + command.setParent(this); + command.schedule(); +} +``` From 65136cd1394a4e1c8595f77ccdd233ae76d1afa3 Mon Sep 17 00:00:00 2001 From: codetoad Date: Mon, 24 Feb 2025 23:34:20 -0500 Subject: [PATCH 3/4] added information about calling command.setBasicName() --- docs/command-logging.md | 8 ++++++++ docs/subsystem-logging.md | 1 - 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/command-logging.md b/docs/command-logging.md index 3e050c2..59e3174 100644 --- a/docs/command-logging.md +++ b/docs/command-logging.md @@ -21,6 +21,14 @@ !!! important Commands can not be reused. They can be scheduled multiple times, but they can not have multiple parents. +## Customization + +By default, commands will be logged using their class name. Specifically, `class.getSimpleName()`. + +If you want to have a command with a different name you can call `command.setBasicName()`. + +Reasons for this may be if you have a command that is context dependant and want to easily differentiate between its use cases. + ## How Command Logging works !!! note diff --git a/docs/subsystem-logging.md b/docs/subsystem-logging.md index 600a3c2..7ea6949 100644 --- a/docs/subsystem-logging.md +++ b/docs/subsystem-logging.md @@ -182,7 +182,6 @@ Starting off simple, all the `InputProvider` classes do is provide a common inte ### Inputs -<<<<<<< HEAD Inputs contain the actual fields that are being logged. Similar to Command Logging, we want to maintain a tree like structure for our Inputs. To do this, each Inputs extends `FolderLoggableInputs` which in turn extends `LoggableInputs`. From cb3f5d9abfeea189fc3e8b9c476ad86078c2a120 Mon Sep 17 00:00:00 2001 From: codetoad Date: Sat, 5 Apr 2025 21:29:41 -0400 Subject: [PATCH 4/4] formatting fixes --- docs/subsystem-logging.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/subsystem-logging.md b/docs/subsystem-logging.md index 7ea6949..c09c259 100644 --- a/docs/subsystem-logging.md +++ b/docs/subsystem-logging.md @@ -189,13 +189,14 @@ Similar to Command Logging, we want to maintain a tree like structure for our In `FolderLoggableInputs` takes in a folder that is describes the hardware it is logging. You can name this what ever you want but I would recommend just putting the class name of the subsystem. !!!note - This folder can have subfolders separated by a / + Logged folder can have subfolders separated by a / There are two different ways of creating `LoggableInputs`. The *Legacy* method involves extending `FolderLoggableInputs` and declaring the properties by hand and how they are written and read from the log. The second method is using one of the prebuilt input classes with customizable parameters that can be selected using the corresponding Builder. + If using [method 2](#method-2) you can use one of the prebuilt `FolderInputs` classes. ``` mermaid