CmdVel to CAN Bridge ROS2 Package

Overview

This package provides a modular bridge between ROS2 cmd_vel messages and CAN commands for VESC motor controllers. It follows a clean architecture pattern with separated concerns for maintainability and debugging.

Package Architecture

Based on the original plan, this package implements a modular design:

cmdvel_to_can_bridge_ros2/
├── CMakeLists.txt              # Build configuration
├── package.xml                 # Package dependencies and metadata
├── include/cmdvel_to_can_bridge_ros2/
│   ├── can_interface.hpp       # CAN communication interface
│   ├── velocity_converter.hpp  # Velocity calculations and kinematics
│   ├── can_message_builder.hpp # VESC CAN message formatting
│   ├── cmdvel_to_can_node.hpp  # Main ROS2 node class
│   └── safety_system.hpp       # Safety mechanisms and validation
├── src/
│   ├── can_interface.cpp       # SocketCAN implementation
│   ├── velocity_converter.cpp  # Differential drive math
│   ├── can_message_builder.cpp # VESC protocol implementation
│   ├── cmdvel_to_can_node.cpp  # Main node implementation
│   ├── safety_system.cpp       # Safety checks and emergency stop
│   └── main.cpp                # Entry point
├── config/
│   ├── params.yaml             # Default parameters
│   └── robot_config.yaml       # Robot-specific configuration
├── launch/
│   ├── cmdvel_to_can.launch.py # Main launch file
│   └── debug.launch.py         # Debug mode launch
├── docs/
│   ├── README.md               # This file
│   ├── plan_history.md         # Development history and decisions
│   ├── API.md                  # API documentation
│   └── TROUBLESHOOTING.md      # Common issues and solutions
└── tests/
    ├── test_velocity_converter.cpp
    ├── test_can_message_builder.cpp
    └── test_safety_system.cpp

Dependencies

• ROS2 Humble or later
• rclcpp: ROS2 C++ client library
• geometry_msgs: For cmd_vel message types
• can_msgs: CAN message definitions
• socketcan_interface: SocketCAN communication
• std_msgs: Standard message types
• diagnostic_msgs: For system diagnostics

Development Workflow

1. Environment Setup

# Source ROS2 and workspace
source /opt/ros/humble/setup.bash
cd /home/robot/robot_ws
source install/setup.bash

2. Build Process

# Build only this package
colcon build --packages-select cmdvel_to_can_bridge_ros2

# Build with debug symbols
colcon build --packages-select cmdvel_to_can_bridge_ros2 --cmake-args -DCMAKE_BUILD_TYPE=Debug

# Clean build
rm -rf build/cmdvel_to_can_bridge_ros2 install/cmdvel_to_can_bridge_ros2
colcon build --packages-select cmdvel_to_can_bridge_ros2

3. Testing Workflow

# Run unit tests
colcon test --packages-select cmdvel_to_can_bridge_ros2
colcon test-result --verbose

# Integration testing (with hardware)
ros2 launch cmdvel_to_can_bridge_ros2 debug.launch.py

4. Code Standards

• C++17 standard minimum
• Google C++ Style Guide formatting
• Doxygen documentation for all public APIs
• Unit tests for all core functionality
• Thread-safe implementations with proper mutex usage

Modular Development Approach

Benefits of Current Architecture

1. Separation of Concerns: Each module has a single responsibility
2. Testability: Individual components can be unit tested
3. Maintainability: Issues can be isolated to specific modules
4. Scalability: New features can be added without affecting existing code
5. Integration Ready: Can be integrated with ROS2 Control in the future

Module Responsibilities

CAN Interface Module

• Raw SocketCAN communication
• CAN frame transmission and reception
• Error handling and connection management
• Thread-safe message queuing

Velocity Converter Module

• Differential drive kinematics
• cmd_vel to wheel velocity conversion
• Velocity limiting and validation
• Mathematical calculations

CAN Message Builder Module

• VESC protocol implementation
• Message formatting and encoding
• Command type handling (velocity, current, duty cycle)
• Protocol-specific validation

Safety System Module

• Emergency stop mechanisms
• Velocity bounds checking
• Watchdog timers
• Fault detection and reporting

Main Node Module

• ROS2 lifecycle management
• Topic subscription and publishing
• Parameter handling
• Component orchestration

Configuration Management

Parameter Structure

# Robot physical parameters
robot:
  wheel_separation: 0.370        # meters
  wheel_diameter: 0.3556         # meters
  max_velocity: 2.0              # m/s
  max_angular_velocity: 3.14159  # rad/s

# VESC configuration
vesc:
  left_id: 28
  right_id: 46
  can_interface: "can0"
  command_frequency: 50          # Hz

# Safety parameters
safety:
  enable_watchdog: true
  watchdog_timeout: 0.5          # seconds
  velocity_timeout: 1.0          # seconds
  enable_emergency_stop: true

Integration Strategy

Current Phase: Modular Development

• Independent package development
• Isolated testing and validation
• Clear API definitions between modules

Future Phase: ROS2 Control Integration

• Hardware interface implementation
• Controller manager integration
• Simulation compatibility
• Real-time control support

Development Guidelines

Adding New Features

1. Update docs/plan_history.md with the feature plan
2. Create feature branch: git checkout -b feature/description
3. Implement with proper tests
4. Update documentation
5. Submit for review

Debugging Process

1. Use debug launch file: ros2 launch cmdvel_to_can_bridge_ros2 debug.launch.py
2. Monitor CAN traffic: candump can0
3. Check ROS2 topics: ros2 topic echo /cmd_vel
4. Review logs: ros2 log level set cmdvel_to_can_bridge debug

Code Review Checklist

• Code follows style guidelines
• All public APIs documented
• Unit tests added/updated
• No memory leaks (valgrind clean)
• Thread safety verified
• Performance impact assessed

Safety Considerations

• Watchdog Timer: Ensures robot stops if communication is lost
• Velocity Limits: Prevents dangerous speeds
• Emergency Stop: Immediate halt capability
• Input Validation: All cmd_vel messages validated
• Fault Detection: Monitors CAN communication health

Future Roadmap

1. Phase 1: Complete modular implementation (Current)
2. Phase 2: Hardware testing and validation
3. Phase 3: Performance optimization
4. Phase 4: ROS2 Control integration
5. Phase 5: Advanced features (trajectory following, path planning)

Contributing

See docs/plan_history.md for development history and decision rationale. All changes should maintain the modular architecture and follow established patterns.