Closed woensug-choi closed 2 years ago
@bsb808 @daewok
I want to point out some things have changed on our side as well since our
first draft at this architecture (the slocum_glider_sim_driver
and
slocum_glider_sim_console
nodes were not originally planned).
Originally, the UwGliderStatus
message was meant to communicate directly with
the nodes bundled in the backseat driver group. However, when I went to
implement that, I realized that doing so would mean that the backseat driver
nodes would have to behave differently in simulation vs real hardware (by
changing the topics they subscribe to) and it would also drastically change how
operators interact with the glider in simulation vs. real hardware. Both no
good. So, the sim_driver node is basically an implementation of the Glider's
"frontseat" driver to provide the interface between the backseat driver and the
simulator. It looks exactly the same as real hardware to the backseat driver
nodes and it also parses and executes glider mission files exactly like real
hardware does (well... maybe not exactly, but very close).
Why is this important? Well, the uw_glider_backseat
node was originally
spec'ed to do some of the frontseat driver functions (reporting sensors to the
backseat at ~0.25 Hz and state estimation). Now that we have an explicit node
to simulate the frontseat, maybe it makes sense to just forget about the
uw_glider_backseat
node.
Attached is my proposed revision to the architecture. Note that the dead reckoning node is still separate. I'd be happy to integrate that into the sim_driver as well if that makes the most sense. My main requirement is just that I'm not the one implementing it, so I'll leave it up to whoever does implement it how they want to do it.
Three other things to note:
The glider's frontseat does no reasoning over the DVL outputs: that's handled by nodes running on the backseat driver. So if the sim_driver ever subscribes to the DVL, it will be simply to log data to file (all the real front seat does as well).
The contents of the UwGiderStatus
message can probably be pared down to
include only the glider specific things (like motor power, pumped volume,
battery position, etc.).
We probably have to wrap the Hector GPS sensor somehow so it stops reporting the position once we're underwater.
Forgot to attach the diagram.
Thank you for the quick reply as always! I agree with pretty much everything you suggest. Also agree that the dead reckoning is a better fit for the sim_driver and leave the gazebo part solely as a hardware substitute. Will talk to Rich and Greg about this.
My To-dos on top of your diagram
@daewok Could you share the diagram graphml file?
@woensug-choi I agree Woensug, I believe the best place for the DR would be in the slocum_glider_sim_driver. I can help with the implementation side of things. I think a good starting point would be to try and put into effect the equations I outlined in Issue #3 (simulate glider-dead reckoning).
So the DR EST node would need to subscribe to the following from the sensors: Depth/ascent/descent rate Pitch Heading Time
To calculate glider angle, we can assume a constant angle of attack of ~3 degrees for now.
Then, sim_driver would send this message to the BSD, ideally in the same format that the glider front seat computer currently does. (@daewok probably has the best knowledge of this?)
I told Woensug I'd take a swing at a standalone ROS node to implement the DR estimation. Will have something for tomorrow.
@woensug-choi Github won't let me attach it here, so I'll email you.
@bsb808 @greg-burgess Awesome. The sim_driver is currently grabbing position from the UwGliderStatus message from the kinematics plugin and already providing it to the BSD in the correct format. Should be trivial to switch that to another source.
The final interface we are converging into.