System monitor node #193
System monitor node #193
Conversation
Signed-off-by: Christopher Strøm <[email protected]>
Signed-off-by: Christopher Strøm <[email protected]>
Signed-off-by: Christopher Strøm <[email protected]>
…exntnu/vortex-asv into feature/system_monitor_node
|
I think it covers the functionality we need for now at least. Is there a reason why thruster_forces are set to zero in the system monitor and not as a part of the deactivate transition in thruster_allocator @chrstrom? |
lifecycle transitions in the allocator are really boilerplate/proof-of-concept at this point, but having both of them publish zero thrust could be a nice piece of redundancy to have? |
|
@theoam02 @alekskl01 @Andeshog Is this something you want cleaned up and merged into the test branch within the next few days? |
|
Yes, that would be great |
Signed-off-by: Christopher Strøm <[email protected]>
chrstrom
requested review from
alekskl01 and
Andeshog
and removed request for
alekskl01
|
Ready for review, note that I ended up not having the allocator publish zero-thrust on_shutdown since I ran into some weird deadlocks when disabling the wrench subscriber while an external node was publishing to it. If anyone knows a fix feel free to add it. Also: Why can there only be 1 reviewer? Would be nice for both @alekskl01 and @Andeshog to look at it and test it on hardware. |
Signed-off-by: Christopher Strøm <[email protected]>
|
Hmm, might be a free org private repo thing |
|
Software killswitch will shut down all the wrench publishers, could that fix the deadlock? |
Maybe, I'm not sure how the node topology looks with that in the mix. I suggest leaving the code as-is until its tested on hardware. An advantage of how things are right now is that the system-monitor node takes full authority without requiring any manual triggers, which could be extended to control other components as well (in the case of low battery voltage f.ex) |
| def publish_zero_force(self): | ||
| self.get_logger().info('Publishing zero-force on shutdown...') | ||
| message = Float32MultiArray() | ||
| message.data = [0.0] * 4 |
There was a problem hiding this comment.
maybe add num_thrusters as a parameter
@theoam02 pls allow draft pull requests.
This serves as an example of how a system monitor/supervisor can look. Note the comment in the truster allocator node source. Usually we would let lifecycle management be handled externally, but in this case the only feature we really need is the transition from activated to deactivated. As such, the intialization phase can happen instantaneously on node creation.