ROS for GoPiGo3: What Can Be Learned From Turtlebot3

GoPiGo
, ,
1

While a ROS node for GoPiGo3 exists, the “Gold Standard” for differential drive ROSbots is generally accepted to be the Turtlebot family - now existing as Turtlebot3 Burger and Turtlebot3 WafflePi.

I have been porting the ROS(1) GoPiGo3 node to ROS2, while attempting to learn how to invoke and observe ROS nodes and topics, as well as learn what goes into a ROS differential drive robot node.

The ROS GoPiGo3 node implements a fair number of functions, albeit in simplistic fashion, so it is interesting to see how the Turtlebot ROS node is implemented.

Looking over the ROS2 Turtlebot3 node the following can be determined:

  • The Turtlebot3 node configuration is parameterized for:
    • wheel_separation, wheel_radius
    • acceleration_constant (214 rev/min2 - motors have internal velocity ramp control)
    • use_imu
    • publish_tf
    • odometry frame id (odom) and child_frame_id (base_footprint)
       
  • Publishes sensor_state “is_connected” for:
    • bumper forward
    • bumper backward
    • illumination (ambient light level?)
    • ir (cliff sensor)
    • sonar (ultrasonic distance sensor)
       
  • Publishes sensor data in a 50ms callback:
    • pushbutton 1 state
    • pushbutton 2 state
    • motor_torque_enabled left/right
    • encoder values left/right
    • battery voltage
    • bumper forward
    • bumper backward
    • illumination (ambient light level)
    • ir (cliff sensor)
    • sonar (ultrasonic distance sensor)
    • imu
    • magnetic_field (from imu)
       
  • Subscribes to cmd_vel topic
  • Provides a reset service
  • Provides a “sound” device service
  • The odometry callback publishes
    • left and right wheel joint_states
    • odom topic
    • if publish_tf, the new odometry tf
    • if use_imu, odometry pose angle is derived from imu instead of encoders
  • There is a 75/15ms joint_state and imu message filter synchronizer
  • Uses differential_drive_controller
  • Publishes a heartbeat counter every 100ms
  • Implements a 5 second IMU calibration at startup
2 Likes
2

I suspect that this parameter is used to scale how fast the robot should accelerate, (dv/dt). As in parameter “X” controls the maximum velocity and “acceleration constant” controls the maximum rate of change.

2 Likes
3

Gawd Almighty!

Reminds me of the 90’s when Windows callback loops and basic glue-logic for window instantiation all had to be hand coded as there was no “boiler-plate” code or templates.

I’ll stick with trying to decode nipple.js!

2 Likes
4

Indeed. I was looking for the acceleration constant use by the software, but acceleration control is actually implemented internal to the very expensive, USB interfaced Dynamixel motors.

Both Carl and Dave need acceleration control to keep them vertical.

Neither the base GoPiGo3 or EasyGoPiGo3 class offer acceleration control, so Carl is a bit out of luck. Perhaps in 2022. (Carl is constrained to 150 DPS for accuracy and safety due to lack of “a” control.)

Dave on the other hand will have acceleration control when I learn how to use the ROS differential_drive_controller node that can translate generic /cmd_vel topics to well-behaved /gopigo3/cmd_vel instructions. (… or perhaps to allow for multiple ROS GoPiGo3 robots on the same network I should use a /gopigo3/dave namespace.)

Am I figuring correctly that an acceleration constant of 214 rev/min2 is 0.059 rev/s2 and applied to Carl, whose max wheel velocity is 360 DPS would spread the acceleration to max wheel velocity across 17 seconds?

A long time ago, I computed Carl’s actual acceleration to be around 1.1m/s or 5.25 rev/s2 which spreads the acceleration to 360DPS across 0.2 seconds! That kind of unbridled power makes it clear why I have to slow Carl down for accuracy and safety.

2 Likes
5

You’re not planning on putting Dynamixel motors on your 'bots, are you? That seems like tremendous overkill.

Assuming you aren’t, then the acceleration constant becomes very relevant to your 'bots as they are both a bit top-heavy.

2 Likes
6

Never! GoPiGo3 plus ROS differential_drive_controller node software equals $200 saved. (“Sweat equity “)

2 Likes
7

:+1: :+1: :+1: :+1: :+1:

Not to mention that those things look like they’re for Beast Bots that even have cold beer on tap!

2 Likes