reidlo5135/ros-vehicle-control

Purpose and Runtime

This is a ROS 2 Humble C++ workspace for vehicle control. It turns ROS control inputs into vehicle commands, exchanges those commands and vehicle telemetry through SocketCAN, then validates/corrects runtime vehicle state. Target deployment is Ubuntu 22.04 with a SocketCAN-capable vehicle or simulator; map_handle_msgs and robot_status_msgs are external message dependencies.

Process Entry Points and Deployment

Each major capability is an independently built ROS 2 package with a node executable, launch file, and YAML parameters:

• CAN bridge: can_manager/src/main.cpp, can_manager/launch/can_manager.launch.py, can_manager/config/can_manager.yaml

• Motion control: motion_controller/src/main.cpp, motion_controller/launch/motion_controller.launch.py, motion_controller/config/motion_controller.yaml

• Validation: motion_validation/src/main.cpp, motion_validation/launch/motion_validation.launch.py, motion_validation/config/motion_validation.yaml

Presentation-layer node classes own ROS-facing subscriptions, publishers, parameters, and callback orchestration.

Motion Controller: Input to Vehicle Intent

motion_controller is the upstream command-processing stage. Its presentation node receives ROS control inputs and delegates to application services:

• Command/control logic: motion_controller/src/application/control.cpp

• Input/unit/message conversion: motion_controller/src/application/converter.cpp

• Motion behavior/orchestration: motion_controller/src/application/motion.cpp

Vehicle state and tunable vehicle parameters are isolated in the domain layer at motion_controller/include/domain/vehicle.hpp and motion_controller/include/domain/parameter.hpp. The boundary is ROS topics at the node layer versus vehicle-oriented control commands produced by application/domain code.

CAN Manager: ROS–Bus Boundary

can_manager is the hardware/protocol boundary between ROS messages and CAN frames. It explicitly supports both directions:

• CAN-to-ROS translation: can_manager/src/application/c2r.cpp

• ROS-to-CAN translation: can_manager/src/application/r2c.cpp

• ROS node integration: can_manager/src/presentation/node.cpp

Its domain vehicle model and parameters (can_manager/include/domain/vehicle.hpp, can_manager/include/domain/parameter.hpp) centralize vehicle-specific interpretation rather than exposing raw CAN semantics throughout the workspace. CAN channel and topic configuration belongs in can_manager/config/can_manager.yaml.

Shared CAN Transport and Utilities

can_utils is a reusable native library beneath the CAN manager rather than a ROS node. It contains the SocketCAN-facing adapter and common frame operations:

• Transport adaptation: can_utils/include/can_utils/adaptor.hpp, can_utils/src/adaptor.cpp

• Sending: can_utils/include/can_utils/send.hpp, can_utils/src/send.cpp

• Frame dumping/diagnostics: can_utils/include/can_utils/dump.hpp, can_utils/src/dump.cpp

This package forms the important infrastructure boundary between application-level frame conversion and the underlying CAN interface.

Motion Validation: State Assurance Feedback Stage

motion_validation consumes runtime vehicle state and applies validation, filtering, and correction before publishing trusted state back into ROS:

• Validation rules: motion_validation/src/application/vertification.cpp

• State correction: motion_validation/src/application/correction.cpp

• Kalman-based filtering: motion_validation/src/application/kalman.cpp

ROS integration is concentrated in motion_validation/src/presentation/node.cpp; its parameters are represented by motion_validation/include/domain/parameter.hpp. This stage is downstream of CAN-derived runtime data and can provide corrected state for controllers or other vehicle-platform consumers.

End-to-End Control Flow

Primary command path: ROS control topics → motion_controller conversion/control/motion logic → vehicle command topics → can_manager ROS-to-CAN conversion → can_utils/SocketCAN → vehicle bus.

Primary feedback path: vehicle CAN frames → can_utils → can_manager CAN-to-ROS conversion → runtime vehicle-state topics → motion_validation verification/Kalman/correction → validated ROS state topics. Vehicle-specific mappings and parameters are package-local, allowing the ROS interfaces, motion policy, and physical CAN transport to evolve at separate boundaries.