[Energy] Add radio states and energy consumption - Part 3 of RTEA

[Vinggui]

Contribution description

This PR is part of the process of breaking PR #235 into small steps, a process nominated "Road to Energy Analysis" (RTEA). These small modifications will lead to the whole improvement started on March 2022. At the end of these steps, OT-NS will be capable of precisely estimating energy consumption, collision events (channel aware), and plot all the data in real-time as the simulation progress.

At the moment, OT-NS can not estimate energy, collisions, nor transmission energy. Also, even though OT is working well in simulation, many of its recovery properties are not correctly simulated as they would happen in real devices due to its incorrect timing events at the simulated radio part.

This PR adds functions to handle the radio state pushed by each simulated device.
It is still compatible to the current implementation of the OT.

This PR also introduces:

• A new CLI called energy save [output name], allowing the user to store the energy results obtained out of their simulation;

This energy simulation is based on the STM32WB55rg at 3.3V:

	RadioDisabledConsumption float64 = 0.00011 //To be confirmed
	RadioTxConsumption       float64 = 0.01716 //5.2 mA
	RadioRxConsumption       float64 = 0.01485 //4.5 mA
	RadioIdleConsumption     float64 = 0.01485 //4.5 mA

Main modifications

• A new energy analysis module (Go);

NodeEnergy struct is implemented from the gRPC to avoid redundant information in the code and keeping the standard around the system. For now, it could be implemented in another point of the code, but in the next PRs, we will use this same code in the web visualization, which is why it makes sense to centralize it in the PROTO.

This PR addresses only the following files:

• /ot-ns/cli/ast.go
• /ot-ns/cli/CmdRunner.go
• /ot-ns/dispatcher/dispatcher.go
• /ot-ns/dispatcher/Node.go
• /ot-ns/energy/core.go
• /ot-ns/energy/node.go
• /ot-ns/energy/types.go
• /ot-ns/simulation/simulation.go
• /ot-ns/types/types.go
• /ot-ns/pylibs/otns/proto/visualize_grpc_pb2.py
• /ot-ns/visualize/grpc/pb/visualize_grpc.pb.go
• /ot-ns/visualize/grpc/pb/visualize_grpc.proto

Requirements

None (if intended to be used with current Openthread repository). But, this is a walk to the road of PR #7500 in Openthread repository that will allow all the new features in the simulation to work.

Testing procedure

Just install OTNS the same way as before, using the "OTNS=1" for the building parameter.

To obtain the energy results, just use the command energy save, but if you want a specific name for the files, use energy save "name"

Roadmap

This is part 3 of the RTEA (Road to Energy Analysis) steps to PR #235 and PR #7500.

Part 1: PR #357;
Part 2: PR #8144;
Part 3: This PR;
Part 4: PR #8152;
Part 5: PR #362;
Part 6: PR #8165;
Part 7: PR #363;
Part 8: PR #8173;
Part 9: PR #365;
Part 10: PR #366;
Part 11: PR #367.

[codecov-commenter]

Codecov Report

Merging #359 (f2d7703) into main (c616148) will decrease coverage by 1.58%.
The diff coverage is 16.36%.

@@            Coverage Diff             @@
##             main     #359      +/-   ##
==========================================
- Coverage   49.97%   48.39%   -1.59%     
==========================================
  Files          38       40       +2     
  Lines        4608     4794     +186     
==========================================
+ Hits         2303     2320      +17     
- Misses       2123     2290     +167     
- Partials      182      184       +2     

Impacted Files	Coverage Δ
cli/CmdRunner.go	22.62% <0.00%> (-0.51%)	⬇️
cli/ast.go	66.66% <ø> (ø)
types/types.go	65.38% <ø> (ø)
web/site/bindata.go	99.00% <ø> (-0.01%)	⬇️
visualize/grpc/pb/visualize_grpc.pb.go	18.77% <3.63%> (-0.66%)	⬇️
energy/core.go	7.31% <7.31%> (ø)
dispatcher/dispatcher.go	56.25% <13.33%> (-0.86%)	⬇️
energy/node.go	40.00% <40.00%> (ø)
dispatcher/Node.go	26.98% <44.82%> (-3.30%)	⬇️
simulation/simulation.go	57.94% <50.00%> (-0.31%)	⬇️
... and 2 more

[EskoDijk]

@Vinggui This looks good, very useful that the new code works with the existing OT node. (I just updated my own radiomodel PR in such a way that existing OT nodes can work with it.) And the radio_state event here is new, so it won't be emitted yet by the legacy OT nodes right? I'll give it a try, did not see anything to comment on yet in the code, it follows the design cleanly.

The "Develop" Github action seems to have the same strange error that I had, as detailed in: https://github.com/openthread/ot-ns/actions/runs/3041189606/jobs/4898059950#step:5:3534

[Vinggui]

@Vinggui This looks good, very useful that the new code works with the existing OT node. (I just updated my own radiomodel PR in such a way that existing OT nodes can work with it.) And the radio_state event here is new, so it won't be emitted yet by the legacy OT nodes right? I'll give it a try, did not see anything to comment on yet in the code, it follows the design cleanly.

@EskoDijk Actually, the radio_event is already implemented as a // TODO in the main/OT-NS branch. I made that in a previous PR trying to break the chicken and the egg problem of using both repositories so tightly implemented. However, as development went on, I saw that many more changes were necessary (which are now ready). I hope that our codes will still be very compatible, since your transmission model looks interesting.

The "Develop" Github action seems to have the same strange error that I had, as detailed in: https://github.com/openthread/ot-ns/actions/runs/3041189606/jobs/4898059950#step:5:3534

Don't bother about it, it is something else not related to these PRs. Soon, they'll fix that, and we can merge it.

[EskoDijk]

Out of curiosity I did a merge of this PR with PR #316 - with some manual merging, it works ok: https://github.com/EskoDijk/ot-ns/tree/energy-and-radiomodel.

As a future improvement, I think the radiomodel could output events to the queue about radio state as well. These flow back to the dispatcher and could be handled as reports/updates to the energyAnalyser to have some further fine-grained energy use tracking. For example while the radio is doing the mandatory wait periods or during "turn around time" it may have different power consumption from regular Rx/Tx states?

[Vinggui]

For example while the radio is doing the mandatory wait periods or during "turn around time" it may have different power consumption from regular Rx/Tx states?

Do you mean the current oscillations/peaks during the transition of states? If so, I agree that those transitions are not taken into account for the moment. I believe that they could be considered, but its model/values are not clear right now to me. Also, I wonder how much would this actually impact at the end. Certainly, it is considerable.

[Vinggui]

Maybe here, we should fix the Issue 272. It seems like the best PR to do it.