Port twist commands to AckermannDrive (#8)

* Update mermaid diagrams

* Update node info

* Update gz_io_ros.md

Signed-off-by: Andrew Ealovega <andrew@ealovega.dev>

---------

Signed-off-by: Andrew Ealovega <andrew@ealovega.dev>

software/ros/gz_io_ros.md

@@ -2,22 +2,27 @@
 
 ## Summary
 
-This node is responsible for translating gazebo odom messages into TrainingData messages when training in sim.
+This node is responsible for aggregating ackermann commands and gazebo odom values together into values used in
+data logging. 
+
+It is also the endpoint in the system for ackermannDrive commands, splitting the command into a cmd_vel and steering angle
+component to be sent to gazebo. See the urdf doc for more info on this command setup.
 
 Its goal is to serve as a fake for [phnx_io_ros](phnx_io_ros.md).
 
 ### Subscribes
 
 - `/odom` - Gazebo odom source
-- `/robot/cmd_vel` - Steering and throttle command twist source
+- `/robot/ack_vel` - Steering and throttle command ackermannDrive source
 
 Sync the above two topics.
 
 ### Publishes
 
 - `/odom_ack` - AckermannDrive messages representing the current state of the kart. See module readme for more info.
+- `/robot/cmd_vel` - Twist messages to control the drive part of sim actuation. This only contains linear velocity.
+- `/robot/steering_angle` - Doubles that control the steering part of sim actuation. These are virtual ackermann values we want the wheels to be at, in the normal ROS convention.
 
-### Conversion Algorithm
+### Notes
 
-Converting the odom to training data will amount to converting the twist to ackermann steering and storing that in the steering field,
-then copying the twist's velocity_x into the acceleration field, and finally copying the odom's velocity_x into the velocity field.
+On receiving a command, the node should both create the odom and forward the command to gazebo.

software/ros/inference.md

@@ -2,7 +2,7 @@
 
 ## Summary
 
-The inference node actually runs the trained NN, sending it's output as twist commands.
+The inference node actually runs the trained NN, sending it's output as ackermannDrive commands
 
 ### Subscribes
 
@@ -12,8 +12,7 @@ The inference node actually runs the trained NN, sending it's output as twist co
 
 ### Publishes
 
-- `/nav_vel` - Twist message corresponding to NN output
-- `/ack_vel` - AckermannDrive message corresponding to NN output
+- `/nav_ack_vel` - AckermannDrive message corresponding to NN output
 
 ### Configs
 
@@ -32,10 +31,5 @@ The inference node actually runs the trained NN, sending it's output as twist co
 
 It would be nice if this node could be made flexible across CUDA and CPU, to allow for more people to run it.
 
-The model currently outputs things as percents, so we will need to multiply them by our max values to get values for
-a twist output. It's best to do this by first creating an ackermann message by multiplying the max pedal speeds by their
-percent,
-(giving brake priority over throttle), getting the wheel angle by multiplying its percent by max angle, then applying
-the
-steering ratio to the wheel angle to get the final virtual ackermann angle. This message can then be ackermann ->
-Twisted.
+The model currently outputs things as percents, so we will need to multiply them by our max values to get values for the 
+command. We can create an ackermannDrive message by just running the steering wheel angle through the steering ratio.

software/ros/logi_g29.md

@@ -14,8 +14,6 @@ outputs ackermannDrive and Twist messages directly, bypassing the need for somet
 
 - `/ack_vel` - AckermannDrive outputs from the wheel
 
-- `/cmd_vel` - Twist outputs from the wheel
-
 ### Params
 
 - `max_throttle_speed` - Velocity at which we consider the throttle fully pressed. This should match the config set in
@@ -34,8 +32,6 @@ outputs ackermannDrive and Twist messages directly, bypassing the need for somet
 The raw joy interface gives wheels and pedals in percents, so it's best to first create an ackermann message using the
 max throttle brake and wheel params. During this creation, we need to convert the wheel angle to virtual ackermann wheel
 angle by using phoenix's steering ratio, and convert pedal percents by just multiplying percent pressed by max values.
-We may as well pub this, and then also ackermann->twist it to output our actual
-final twist.
 
 If the wheel angle is greater than the max angle, we should pin it to max. Could use force feedback to help with this if
 we get it figured out.

software/ros/phnx_io_ros.md

@@ -23,7 +23,7 @@ The following config values refer to fields of /ack_vel messages:
 
 ### Subscribes
 
-- `/ack_vel` - Output from `twist_to_ackermann`. Braking commands are encoded as negative velocity.
+- `/ack_vel` - AckermanDrive command to actuate on the kart.
 
 ### Services Used
 

software/ros/phoenix_gazebo.md

@@ -26,20 +26,22 @@ stateDiagram-v2
     Gazebo --> gz_bridge:::common
     gz_bridge:::common --> Gazebo
     gz_bridge:::common --> data_logger:::data: /camera/mid/rgb
-    gz_bridge:::common --> gz_io_ros:::common: /odom
+
     
     %% command controllers
-    drive_mode_switch:::common --> gz_bridge:::common: /robot/cmd_vel
-    drive_mode_switch:::common --> gz_io_ros:::common: /robot/cmd_vel
-    joy_to_teleop_twist:::common --> drive_mode_switch:::common: /cmd_vel
+    drive_mode_switch:::common --> gz_io_ros:::common: /robot/ack_vel
+    gz_io_ros:::common --> gz_bridge:::common: /robot/cmd_vel
+    gz_io_ros:::common --> gz_bridge:::common: /robot/steering_angle
+    logi_g29:::common --> drive_mode_switch:::common: /ack_vel
 
     %% logging
     gz_io_ros:::common --> data_logger:::data: /odom_ack
     data_logger:::data --> disk: CSVs and images
 
     %% NN
     gz_io_ros:::common --> inference:::prod: /odom_ack
-    inference:::prod --> drive_mode_switch:::common: /nav_vel
+    inference:::prod --> drive_mode_switch:::common: /nav_ack_vel
     gz_bridge:::common --> inference:::prod: /camera/mid/rgb
 
+    gz_bridge:::common --> gz_io_ros:::common: /odom
 ```

software/ros/phoenix_robot.md

@@ -4,17 +4,17 @@ This package contains launch files for running phoenix IRL.
 
 there are three main launch files:
 
-- inference.py.launch: Runs the production version of phoenix, using the NN inference to drive the kart
-- data_collect.py.launch: Runs phoenix in data collection mode, labeling images for offline training
-- common.py.launch: Launch file that launches nodes common between the above two files
+- inference.launch.py: Runs the production version of phoenix, using the NN inference to drive the kart
+- data_collect.launch.py: Runs phoenix in data collection mode, labeling images for offline training
+- common.launch.py: Launch file that launches nodes common between the above two files
 
 ## Ros Config
 
-Red = common.py.launch
+Red = common.launch.py
 
-Black = inference.py.launch
+Black = inference.launch.py
 
-Blue = common.py.launch
+Blue = common.launch.py
 
 ```mermaid
 stateDiagram-v2
@@ -28,9 +28,8 @@ stateDiagram-v2
     phnx_io_ros:::common --> Can: Actuation commands
     
     %% command controllers
-    twist_to_ackermann:::common --> phnx_io_ros:::common: /ack_vel
-    drive_mode_switch:::common --> twist_to_ackermann:::common: /robot/cmd_vel
-    joy_to_teleop_twist:::common --> drive_mode_switch:::common: /ack_vel
+    drive_mode_switch:::common --> phnx_io_ros:::common: /robot/ack_vel
+    logi_g29:::common --> drive_mode_switch:::common: /ack_vel
     
     %% state control
     phnx_io_ros:::common --> robot_state_controller:::common: /robot/set_state
@@ -41,7 +40,7 @@ stateDiagram-v2
     data_logger:::data --> disk: CSVs and images
 
     %% NN
-    inference:::prod --> drive_mode_switch:::common: /nav_vel
+    inference:::prod --> drive_mode_switch:::common: /nav_ack_vel
     oak_d:::common --> inference:::prod: /camera/mid/rgb
     phnx_io_ros:::common --> inference:::prod: /odom_ack
 ```

software/ros/phoenix_training.md

@@ -28,21 +28,28 @@ stateDiagram-v2
     hypervisor --> runtime: spawns
 
     state runtime {
-        gz_bridge --> gz_io_ros: /odom
+
+        gazebo --> gz_bridge
+        gz_bridge --> gazebo
+        
         gz_bridge --> run_mgr: /camera/score/rgb
         gz_bridge --> inference: /camera/mid/rgb
         gz_bridge --> data_logger: /camera/mid/rgb
 
         gz_io_ros --> inference: /odom_ack
         gz_io_ros --> data_logger: /odom_ack
+
+        gz_io_ros --> gz_bridge: /robot/cmd_vel
+        gz_io_ros --> gz_bridge: /robot/steering_angle
         
         data_logger --> disk: CSVs and images
         data_logger --> run_mgr: /run_folder
 
-        inference --> gz_bridge: /robot/cmd_vel
-        inference --> gz_io_ros: /robot/cmd_vel
+        inference --> gz_io_ros: /robot/ack_vel
 
         run_mgr --> disk: Score file
+
+        gz_bridge --> gz_io_ros: /odom
     }
 ```