Consistency of the power consumption model

[oceank]

We observed some consistency issues in the power consumption model and would like to share them here and get some feedback.

The goal of the investigation is to check two hypotheses on the power consumption model, which are important for designing the data collection for learning the power consumption model in the lander. (The learned power consumption model will then be used to assist the autonomy for planning and adaptation.)

Two Hypotheses we are interested in:

• Hypothesis 1: the operations of the same kind with the same context, e.g., grinding at the location A, are expected to result in similar energy consumption, i.e., similar reduced RUL. If the energy consumption of the two runs differs, how does the variation look like?
• Hypothesis 2: the operations of the same kind with different work loads are expected to result in different energy consumption, i.e., reduced RUL, correspondingly. For example, we expect to see the energy cost of delivering a sample from location A to location B is smaller than that of delivering the sample from location A to location C if distance(A, B) < distance(A, C).

Investigation Setup

• Use Remaining Useful Life (RUL) as the proxy of the battery level: according to the document, the RUL estimates the time remaining before the battery reaches the set threshold for the State Of Charge (SOC) and a fault will be detected when the SOC level is below the set threshold.

• Use existing PLEXIL Lookup, RemainingUsefulLife to track RUL: we use ReferenceMission1.plp to conduct the investigation by tracking the reduced amount of RUL for each operation. And for some operations, e.g., DigTrench, we put the tracking hook inside it to see how the low-level operations, e.g., Grinding and Deliver, consume the RUL.

• The version ow_simulator used in the investigation is release 9 with commit a92698a in the master branch.

• Scenario 1 (ReferenceMission1.plp):

  • The operation flow of ReferenceMission1 is listed below for your quick reference

    • ImageLandingSite
    • IdentifySampleTarget
    • DigTrench
    • RemoveTailings
    • CollectSample
    • Unstow
    • Stow
    • StartSampleAnalysis

  • The DigTrench operation creates a trench with a length of 0.6m at the location, [1.73, 0.1, -0.16]. The z-coordinate -0.16 was obtained by running GuardMove operation. During excavation, there are two passes of grinding with a bite depth of 0.05m. The location for dumping tailing is [1.5,0.8,0.65]. After the trench is ready, collect the sample from the trench and deliver it to the container on the lander, whose location is [0.55,-0.3,0.84].

• Scenario 2 (Use a new dump location in ReferenceMission1.plp)

  • The new dump location is [1.6,0.5,0.65]. The rest part is the same as that in Scenario 1. Since the new dump location is closer to the trench when compared to the dump location specified in Scenario 1, we expected that the consumed RUL for sample delivery in Scenario 2 should be less than that in Scenario 1.

Observations The experiment result is ploted in figures, figure 1 and figure 2. For the tracked RUL values, please refer to the Google Sheet.

• It seems that there is a bug related to the energy consumption of unstow and stow operations. In scenario 1, as shown in figure 1, the remaining useful battery life was changed 2492 to 0 after finishing unstow operation, then it changed from 0 to 2435 after finishing stow operation.

• In scenario 2, as shown as the red curve in figure 2 (data points related to Unstow is removed), sometimes the remaining useful life will increase after finishing some operation, e.g., Deliver and DigCircular operations.

• The energy consumption of Downlinking seems to be considered in the current power model. In scenario 1, for the period between “StartSampleAnalysis finishes” and “Mission finishes”, the remaining useful life changed from 2435 to 2420 while the communication "Downlinking" happened during the period according to the log. So, the reduced useful life "15" seems to be caused by the Downlinking.

• The two hypotheses in our study design failed to be validated based on the current investigation.

  • Hypothesis 1: the Grind operations used in DigTrench are the same operation with the same context in both scenario 1 and scenario 2. It is expected that the reduced RUL is similar, but, as seen in the left-most green rectangle in figure 2, the reduced RUL for Grind in scenario 2 is much smaller than that in scenario 1. Similar observations are discovered for other operations (with the same context), e.g., DigCircular operations in RemoveTailing and CollectSample. The tracked RUL of all these operations are highlighted in green rectangles in figure 2. The behavior of RUL disagrees with our hypothesis 1.
  • Hypothesis 2: in scenario 2, we set the dump location closer to the trench than it in scenario 1 and expect the dump operation using the Deliver command would reduce a less RUL in scenario 2 when compared to scenario 1. But the dump operations highlighted in purple rectangles do not support our hypothesis 2.

Figure 1

Figure 2

Follow-up study As suggested by @Samahu in the ARROW/COLDTech meeting, we will go to use the raw/average measurement of the mechanic power instead of RUL to check our two hypotheses. Two corresponding ROS topics in ow_simulator are:

• mechanical_power/raw
• mechanical_power/average

[kmdalal]

@oceank , thanks for the detailed report. Here's some feedback:

• If you've been reading our weekly updates, the power model has had a lot of work recently, to correct many known problems in Release 9. Many fixes and improvements just got merged to the noetic-devel branch -- please use this branch and not master for any continued work.
• The erratic RUL problem you report is a known problem in Release 9 and still under investigation. Do not use RUL for now. From prognostics, use state of charge and temperature; or use the mechanical_power telemetry you have mentioned. This should change your results quite a bit!
• Both of your hypotheses sound reasonable to me, up to two factors we have not studied. One is the stochasticity of the prognoser (GSAP) and variances this produces. The second is the difference in battery state between two different operations; e.g. is the rate of discharge different at various points in the battery's life. @chetankul can comment more in this area.
• Energy consumption of Downlinking is not modeled -- it is a stub. In fact, communications are not modeled at all in this testbed.

[chetankul]

@oceank Thank you for the report and questions on the power module.

My response to the two hypothesis is as below

Hypothesis 1: the operations of the same kind with the same context, e.g., grinding at the location A, are expected to result in similar energy consumption, i.e., similar reduced RUL. If the energy consumption of the two runs differs, how does the variation look like?

If the energy consumption in the two runs is within 10 watts no significant change would be observed in the RUL. But if the energy consumption is high RUL values may be different. This difference also depends on where in the SOC the actions are performed. If early in the discharge cycle or later in the discharge cycle. As @kmdalal mentioned GSAP battery model does have variance in outputs which are within a low threshold boundary envelope.

Hypothesis 2: the operations of the same kind with different work loads are expected to result in different energy consumption, i.e., reduced RUL, correspondingly. For example, we expect to see the energy cost of delivering a sample from location A to location B is smaller than that of delivering the sample from location A to location C if distance(A, B) < distance(A, C).

This hypothesis is correct. If the same operation with a different workload is performed the amount of energy drawn will be different and the RUL will depend on load profile as mentioned in the question.

[kmdalal]

@oceank , has the information provided so far helped you to progress with your work? Have you tried the noetic-devel branch of ow_simulator? Is any part of your work blocked by the issues you brought up? This information will help us prioritize what we need to develop or document.

[oceank]

@kmdalal and @chetankul , the information provided clears questions and is useful for us in building a machine-learning model to predict energy consumption. Thanks a lot! Let's close this issue.

I tried with the noetic-devel branch of ow_simulator with the most recent commit 0a6f5ba, but I encountered a build error for the package, ow_regolith, which complains the 'Contacts' is not declared inside ow_simulator/ow_regolith/src/ContactSensorPlugin.cpp.

After looking around, I find a way to fix it by adding in ow_simulator/ow_regolith/CMakeList.txt the dependence for the library target, ContactSensorPlugin.

add_dependencies(ContactSensorPlugin
  ${${PROJECT_NAME}_EXPORTED_TARGETS}
  ${catkin_EXPORTED_TARGETS})

But with the successful build of the noetic-devel branch, the issue (#236 ) related to the guarded move still pops out. Having the issue of the guarded move fixed will benefit our testing since it is kind of the first and also important operation in the excavation scenario. One thing related to issue #236 I just noticed is that when sending the same parameters through rqt UI to the guarded move action, it shows success in the rqt while the log of os_simulator shows:

[INFO] [1652841963.264785, 1916525729.540000]: Ground Detected ? True [INFO] [1652841963.266126, 1916525729.540000]: Guarded Move arm activity completed

While driving the guarded move using TestGuardedMoves.plp, the log of os_simulator is as below:

[INFO] [1652842016.680779, 1916525782.835000]: Ground Detected ? True [INFO] [1652842017.309781, 1916525783.530000]: GuardedMove: Failed

The difference between these two tests might be something interesting to look at to fix the issue.

[mogumbo]

add_dependencies(ContactSensorPlugin ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})

I was working on the same bug earlier today. We should have a fix in noetic-devel within a couple days.

[kmdalal]

Thanks for the feedback, @oceank . @anjan1984 has fixed the GuardedMove problem and we should have that fix merged soon. The RUL problem is being worked right now. I'll close this issue for now.

[mogumbo]

add_dependencies(ContactSensorPlugin {PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})

I was working on the same bug earlier today. We should have a fix in noetic-devel within a couple days.

The missing Contacts.h bug has been fixed: https://github.com/nasa/ow_simulator/pull/242