How to correctly configure battery_system and related properties in fleet adapter config (#457)

Open-RMF Open-RMF General
1

Posted by @cwrx777:

Hi,

rmf release: iron 20231229

in my fleet adapter config, I have configured recharge_threshold to 0.10 and recharge_soc to 0.20 but there were warnings as shown below when the robot (MiR250) battery was still more than 80% (confirmed by replaying rosbag).
The robot was to perform a patrol task to a waypoint on another floor for 1 iteration, with distance from current position to the lift and from lift to the destination waypoint less than 20 meters

Unable to estimate final state for direct task request [patrol_71a3814d-285f-4230-93a9-4b055b4adfcd]. This may be due to insufficient resources to perform the task. The task will be still be added to the queue.
Robot [WardRobot_051] needs to be charged but has insufficient battery remaining to retreat to its designated charger.

For the rest of the robots (same model) with battery percentage around 70-80% didnt show this warning.
fleet adapter config:

  battery_system:
    voltage: 48.0 # V
    capacity: 34.2 # AHr
    charging_current: 30.0 # A
  mechanical_system:
    mass: 97.0 # kg
    moment_of_inertia: 9.5 #kgm^2
    friction_coefficient: 0.20
  ambient_system:
    power: 20.0 # W
  tool_system:
    power: 0.0 # W
  recharge_threshold: 0.10 # Battery level below which robots in this fleet will not operate
  recharge_soc: 0.20 # Battery level to which robots in this fleet should be charged up to during recharging tasks
2

Posted by @mxgrey:

Sometimes I wonder if we went a little overboard with modeling batteries based on physical parameters, since those parameters aren’t always known or don’t do the best job of really modeling the battery usage. In most cases the robot vendors will simply tell you how many meters that robot can travel before running out of battery, so that’s probably the information that we should really work off of.

I can suggest two ways of dealing with this:

1. Figure out what battery parameters will achieve the correct battery life

The calculation of battery usage while traveling can be found here. You could try adjusting the battery parameters until you get a range that matches your real robot.

This will probably be tedious, error prone, and sensitive to any changes you make in the robot’s nominal velocity and acceleration settings.

2. Introduce a distance-based motion sink

The fleet adapter accepts any type that implements the motion power sink interface.

You could make a new type of motion power sink, e.g. DistanceSink, that simply drains the battery proportional to the distance being traveled. Then you can pass an instance of that into the fleet adapter to be used by the task planner.

I would be happy to accept an implementation of that sink as a PR to rmf_battery alongside the existing sink types.