Our 'ros-car connector' node, ackermann_can.cpp has too many responsibilities. It currently
Handles the VCU's AS_STATE modes
Sends messages on CAN bus, publishes /vcu2ai messages on ROS.
Handles VCU handshakes
This means it will be difficult to test the logic performed by this node on a small scale car that is not fitted with can bus.
My suggestion is to decouple the CAN bus communication from the AS_STATE logic, so that we can easily switch to a scale car that does not have CAN bus. In the new setup, we would have
a new node (possibly python) handling the AS_STATEs (1.), and publishing ROS /ai2vcu messages
a 'ros-car connector' node translating from ROS (/ai2vcu, /vcu2ai) to CAN bus (2.).
This way, we could easily switch out the 'ros-car connector' for whatever communication protocol we want to use on the small scale car and test the rest of the logic.
(3. vcu handshakes - could go to either of them depending on whether we want handshakes on the small scale car or not)
Our 'ros-car connector' node, ackermann_can.cpp has too many responsibilities. It currently
AS_STATEmodes/vcu2aimessages on ROS.This means it will be difficult to test the logic performed by this node on a small scale car that is not fitted with can bus.
My suggestion is to decouple the CAN bus communication from the AS_STATE logic, so that we can easily switch to a scale car that does not have CAN bus. In the new setup, we would have
/ai2vcumessages/ai2vcu,/vcu2ai) to CAN bus (2.).This way, we could easily switch out the 'ros-car connector' for whatever communication protocol we want to use on the small scale car and test the rest of the logic.
(3. vcu handshakes - could go to either of them depending on whether we want handshakes on the small scale car or not)