-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding battery consumers and extra fixes #1811
Conversation
Signed-off-by: Marco A. Gutierrez <[email protected]>
Codecov Report
@@ Coverage Diff @@
## ign-gazebo6 #1811 +/- ##
===============================================
+ Coverage 64.73% 64.77% +0.03%
===============================================
Files 321 322 +1
Lines 26313 26374 +61
===============================================
+ Hits 17034 17083 +49
- Misses 9279 9291 +12
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass. Just caught some minor things.
Would be interesting to see this integrated with some actual system.
Signed-off-by: Marco A. Gutierrez <[email protected]>
Signed-off-by: Marco A. Gutierrez <[email protected]>
It might be worth having an example system (could be in this PR or a separate PR) that actually consumes the battery. Maybe perhaps the thruster or joint controller system? Alternatively an entirely new system would work too. If we merge this without a demo system there is no guarantee that later on we won't have to break ABI to actually use the battery component. |
Signed-off-by: Marco A. Gutierrez <[email protected]>
Signed-off-by: Marco A. Gutierrez <[email protected]>
Added battery consuming capabilities to the thruster plugin and included a test for it. |
@@ -0,0 +1,54 @@ | |||
/* | |||
* Copyright (C) 2018 Open Source Robotics Foundation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: 2022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks.
* limitations under the License. | ||
* | ||
*/ | ||
#ifndef IGNITION_GAZEBO_COMPONENTS_BATTERYCONSUMPTION_HH_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, this name should match the file name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true, left over from previous naming...
#ifndef IGNITION_GAZEBO_COMPONENTS_BATTERYCONSUMPTION_HH_ | ||
#define IGNITION_GAZEBO_COMPONENTS_BATTERYCONSUMPTION_HH_ | ||
|
||
#include <string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need this <include>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, leftover from previous commit.
/// and the name of the battery it uses. | ||
struct BatteryPowerLoadInfo | ||
{ | ||
/// \brief Name of the battery to use. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Entity
of the battery to use instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, thanks.
{ | ||
/// \brief Name of the battery to use. | ||
Entity batteryId; | ||
/// \brief Battery power load to add to the battery. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you specify the units here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Watts, added.
double batteryPowerLoad; | ||
}; | ||
|
||
/// A component that indicates the total consumption of a battery. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add \brief
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
// after it has been started by a topic. See this comment: | ||
// https://github.com/ignitionrobotics/ign-gazebo/pull/1255#discussion_r770223092 | ||
this->dataPtr->startDraining = this->dataPtr->startDrainingFromTopics; | ||
// Recaculate the toal power load among consumers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recal
culate the tot
al
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
this->dataPtr->consumerId, total_power_load); | ||
if (!success) | ||
ignerr << "Failed to set consumer power load." << std::endl; | ||
|
||
// Start draining the battery if the robot has started moving |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this block make sense with the new architecture? I mean, it seems that we're checking if the robot has some velocity in order to start draining the battery. Should that now be taken care by each battery consumer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't wanna remove this because it might be tricky without changing behavior. Maybe this could still be an option as I could see people wanting this behavior opposed to just start draining right away. Maybe the <start_draining>
parameter should inhibit this behavior but keep it when <start_draining>
was not set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's OK to leave it as it is for now for not changing behavior.
src/systems/thruster/Thruster.cc
Outdated
/// \brief Battery power load of the thruster. | ||
public: double powerLoad = 0.0; | ||
|
||
/// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add documentation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missed this one. Added.
Signed-off-by: Marco A. Gutierrez <[email protected]>
Signed-off-by: Marco A. Gutierrez <[email protected]>
This has introduced a new warning on macOS (https://build.osrfoundation.org/job/ignition_gazebo-ci-pr_any-homebrew-amd64/9636/clang/). @marcoag mind fixing it? |
Thanks for the catch, opened a PR with the fix here. |
🎉 New feature
Closes: osrf/lrauv#259
Summary
This PR includes the following changes to the battery plugin:
Improvement so entities can become battery consumers: With the changes included in this PR any
Entity
that contains aBatteryPowerLoad
component can become a consumer. They would have to indicate the name of the battery they want to use and the value of their consumption. This value can be updated at any point during the simulation and the battery will update the total consumption.Fix to battery tests: For some reason battery tests were testing against the
BatterySoC
component like it holds voltage values while it seems to save the state of charge that goes from 0 to 1. This PR updates the tests appropriately so they are performed according to this.Battery plugin weird behavior alternative: Even though
startDraining
was initialized totrue
the battery would never start draining at startup due tostartDrainingFromTopics
starting atfalse
and the fact that this value would take over the other here. So the only way to currently make the battery start draining is to setup a topic and send a message to it. Also there's no way to stop the battery draining. To provide an alternative and maintain behavior this PR introduces a<start_draining>
parameter that can be set through the SDFormat in order to make the battery start draining right away or not, this defaults tofalse
to preserve behavior. Also a topic can be set now through<stop_power_draining_topic>
to stop the battery draining.Fix to battery inital state of charge: Battery initial state of charge was being set to
1.0
no matter what the initial values of the parameters were. Given that the battery does not starts draining by default and before the only way to set it to drain was through a topic most of the times the battery state of charge would always stay at1.0
. Now the battery state is initially set to whatever the initial parameters indicate.Thruster battery consuming option: This also adds the option to make the thruster consume power load from a certain battery through the sdf config parameters. This is meant to provide an example on how to make any plugin set battery consumers. A test is added that includes an example sdf.
Test it
Examples on how to test it can be found on the test that was modified in this PR and the world file.
Checklist
ortutorialcodecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.