There are many places in the code that assume control inputs (i.e., x, y, and theta) are valid floating point numbers. As a result, when one of nan, -nan, inf or -inf is given, the turtle's position becomes infeasible (e.g., x being nan), sometimes even become rendering it uncontrollable.

• Case 1: teleport_absolute service
  • In Turtle::update(), the requested x is directly used to set position (pos_.setX(req.pos.x());).
  • When nan or -nan is provided, turtle's x position becomes nan.
  • Requests with theta set to nan or inf make x, y, and theta of the turtle's pose nan, removing the turtle from the frame.
• Case 2: teleport_relative service
  • Similarly, if linear and/or angular of teleport_relative request is set to nan or inf, turtle's position becomes infeasible.
• Case 3: rotate_absolute action
  • Sending goal with theta set to nan or inf can have the turtle rotate indefinitely, as remaining becomes either nan or -nan.
  • This forces ang_vel_ to become 1.0 after executing the following statement: ang_vel_ = remaining < 0.0 ? -1.0 : 1.0;, as nan < 0.0 always evaluates to False.
• Case 4: cmd_vel topic
  • linear.x, linear.y, and angular.z are not sanitized before being used. Similar to the previous cases, x, y and/or theta of turtle's pose are easily set to nan.

I suggest adding checks before using these variables, e.g., std::isnan and std::isinf, to prevent unexpected input values from polluting the turtle's state.