Fair enough. So the shell program then launches the launch.py programs? I did just now notice that you do have the launch.py programs on your GitHub.
As I think about the different sensors with potentially redundant information, I’m reminded of the saying “The man with a watch always knows what time it is; the man with two watches is never sure.” Perhaps the follow on is “the robot with multiple sensors can do statistical weighting to improve their chance of having a correct reading”.
or the entry point listed in the gopigo3 node’s setup.py launch configuration ( gopigo3_node, the distance sensor and the ultrasonic sensor)
the launch files for the LIDAR and the gamepad.
(Interesting that the LIDAR launch also launches a tf2 static_transform. I don’t know how that plays with the robot_state_publisher and joint_state_publisher putting out a static transform from the URDF when they start up - I think they do that.)
# ros2 run ros2_gopigo3_node gopigo3_node &
ros2 run ros2_gopigo3_node gopigo3_node --ros-args -p S1LPW:=2094 -p S1RPW:=750 -p S1SECTOR:=2.443 &
# ros2 run ros2_gopigo3_node gopigo3_node --ros-args --params-file ./src/ros2_gopigo3_node/gopigo3_node_params.yaml &
ros2 run ros2_gopigo3_node distance_sensor &
ros2 run ros2_gopigo3_node ultrasonic_ranger &
# start SNES gamepad node (cntrl-c to stop this script will kill it automagically)
ros2 launch teleop_twist_joy teleop-launch.py joy_config:="snes" &
# Don't know how to kill it by name, so don't run in background - use cntl-c
ros2 launch ydlidar_ros2_driver ydlidar_launch.py
Since Dave doesn’t have bumpers and I haven’t yet figured out if we can use get_motor_status() as a virtual bumper, I’ll be really happy if any one of the three sensors alert that there is something 6 to 8 inches in front of him. He needs 5.5 inches to turn 180 and run away.