Robot Not a Dev? Buy Now
Not a Dev?

Misty Community Forum

Definition of parts of battery level

I want to estimate when the robot must return to the charging pad. For this, I am recording sequences of values of the battery level response of GET /api/battery. While some parts of the response are easy to interpret, e.g., isCharging, others are not obvious, e.g., healthPercent vs. chargePercent. Ideally the documentation would have full definitions of each, but assuming there is not time to write it all, here are my questions:

  1. what is the set of all feasible values of state? is it only {"Charging", "Discharging"} ?

  2. is there some intuition about how current changes with respect to robot actions? in particular, does change in current predict discharge rate? (for example, does large and negative current imply rapid discharge?)

  3. what is expiry ?

@slivingston Looking into this with someone who’s closer to the details of battery data. We’ll update you here & push an update to the docs with more information :slight_smile:

While we’re gathering information:

I believe state can be one of the following: "Charging", "Discharging", "Charged", "Unknown", or "Fault". Confirmation and more details on what each of those means to come.

I need to check this, but my understanding is that the value of expiry can be thought of as the moment when the returned data should no longer be considered accurate/valid (because these values are always in flux), and new data should be obtained.

Short answer: Yep. Negative current values mean the battery is discharging, and positive values mean it’s charging. Discharge rate increases (shown by a higher negative value for current) during activities that require more power (like movement).

@slivingston How is this coming? I find this sort of problem fascinating. Needing to estimate both the energy remaining in the battery, and the energy required to return to the charger are complex and difficult on their own! It seems like you could scale the amount of information you use for the estimates from simple (and less accurate) to incorporating nearly every sensor in the robot.

How are you estimating the energy required to return to the charger? Using battery discharge current, voltage and time to calculate energy expended since leaving the charger, and assuming similar average expenditure to traverse the most direct path back to the charger?

Would love to see this in Show & Tell when you get far enough along!

1 Like

Just as a point…its probably better to use the values reported by the on-board fuel gauge to understand how much energy has been used and how much remains in the battery. Mostly I say that because at the skill level, the frequency that you would be reading the motor-current values would be slow enough that your estimates could be fairly inaccurate. The fuel gauge is integrating on a MUCH faster cycle than we can do even at the low FW levels. Just saying as an FYI.

I just went up and read the rest of this post. The possible states for the battery state are:
Unknown (should really only happen at power-up or reset of the RT board before it has had a chance to learn the actual state)
Charge (Plugged in/on charging pad, and conditions of finished not met)
Charged (Plugged in, conditions of finished met: voltage above 8.3 V and current to 1/10th max charge current).
Discharge (Not plugged in, voltage above 6.3 V)
Battery Dead (Not plugged in, voltage below 6.3V)
Fault (Charger not detecting the battery, or several other fault conditions)

1 Like

Thinking about the “when to return to charger” problem, I’ve always had it in my head to build a gradient map on top of the maps being built of the area in which the robot is moving. Think of it like a topographic map that shows how much energy it takes to get to that point from the charger. Like a topo-map shows the altitude above sea-level. Think of the charger as sea-level, and each line shows how many mAh it takes to get to the charger. After enough time moving around it should be possible to have a pretty good map for this. If you use an optimization algorithm (like A* or floodfill or other type of gradient-descent algorithm) to just always go “downhill” on the topo-map, knowing how much energy that needs, and it should be possible to know when to return to the charger. We need to establish non-volatile maps, and there would need to be a bit more additional information coming up from the fuel gauge. Fuse that with other sensors, add a bit of a fudge factor to play it safe, and this seems like it should work for getting back to charger when needed. Eh, just a thought anyway.

3 Likes