-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add SpringController valve command #51
Conversation
Signed-off-by: Michael Anderson <[email protected]>
…m/osrf/buoy_sim into andermi/springcontroller_commands
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
Looks good, nice way to characterize mass flow as a function of pressure differential abasement. absement is a new one for me: http://wearcam.org/absement/examples.htm This same technique will apply to the pump command as well, different sign and magnitude of course... It looks like you have test code in there to control the time this valve is active, I'll be watching to see how you integrate the command and timeouts from the ROS2 spring controller code and will copy for similar behaviors in ElectroHydraulicPTO. At the moment I simply respond to ignition transport callouts and maintain a time-out in the plugin. |
Signed-off-by: Michael Anderson <[email protected]>
I made use of the ignition::math::Stopwatch in my SpringState component in the ECM
and manage the stopwatch like this:
I changed the implementation of this a bit in d7e4747 |
I added (osrf/mbari_wec_utils#11) a |
Signed-off-by: Michael Anderson <[email protected]>
In both the pump and valve commands, the behavior of the hardware is a new command sets the timeout to the new specified value. So if you send a "valve 10" and then 5 seconds later send another "valve 10", the valve will be open for a total of 15 seconds. Same for the pump. |
Ok, I'll modify the behavior then. |
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 did a high-level review and didn't look into the math or output behaviour.
Can close the valve with:
ros2 service call /valve_command buoy_msgs/srv/ValveCommand duration_sec:\ 0\
Should I see a message like "Valve closed" printed when I run this command?
buoy_gazebo/src/PolytropicPneumaticSpring/PolytropicPneumaticSpring.cpp
Outdated
Show resolved
Hide resolved
buoy_gazebo/src/PolytropicPneumaticSpring/PolytropicPneumaticSpring.cpp
Outdated
Show resolved
Hide resolved
buoy_gazebo/src/PolytropicPneumaticSpring/PolytropicPneumaticSpring.cpp
Outdated
Show resolved
Hide resolved
buoy_gazebo/src/controllers/SpringController/SpringController.cpp
Outdated
Show resolved
Hide resolved
buoy_gazebo/src/controllers/SpringController/SpringController.cpp
Outdated
Show resolved
Hide resolved
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
I changed these to ROS2 console prints now. In the latest commits, I modified behavior to follow what @hamilton8415 mentioned. Also, cleaned up the command logic, and addressed PR comments. Behavior when issuing console commands (don't mind the truncated duration errors for printing):
|
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
I think real time and sim time are getting mixed somewhere. I'm trying to run this scenario like this:
|
@chapulina Is this an issue with using Stopwatch? Would Timer follow sim time? Hmm, the comments at the top of the file say wall time. Is there a timer that follows sim time? |
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
@chapulina I made my own 🤓 your test should now work with sim time:
step sim ~5sec:
send another command:
step again ~10sec:
|
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
Signed-off-by: Michael Anderson <[email protected]>
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.
Works for me! Nice ROS-based sim time stopwatch!
/// timeSys.ElapsedRunTime()).count() << " ms\n"; | ||
/// watch.Stop(); | ||
/// ``` | ||
class StopwatchSimTime |
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.
Nice! This looks like something that could be generally useful. We should consider moving it somewhere like ros_ign_gazebo
.
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.
It should also work with pure ROS2 using /clock
published from any source (and use_sim_time
param set per node). May want to put it in rclcpp
somewhere?
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.
Actually, should work in ROS2 with any time source really. It just takes an instance of an rclcpp::clock
from the rclcpp::Node
.
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.
Yeah true this is way more generic than I originally thought. I'm not sure what the best place would be, the rclcpp
repo already looks very large. I'll ask around
Signed-off-by: Michael Anderson <[email protected]>
Addresses #44 Valve command
Test with:
ros2 service call /valve_command buoy_msgs/srv/ValveCommand duration_sec:\ 10\
Can watch
/sc_record/range_finder
in rqt_plot. Value should rise ~0.25 m in 10 secCan close the valve with:
ros2 service call /valve_command buoy_msgs/srv/ValveCommand duration_sec:\ 0\
Modeling the valve (need to clean up w/ parameter):
opening for 5 seconds using component:
lowers piston from 0.72 to 0.85 meters (
range_finder
value measured from top of upper chamber) in ~5.5 secondsresults in dropping 0.0236 (~1 inch) per second
Todo: