search

Field-Robotics-Lab / glider_hybrid_whoi

(Hybrid-) AUG Simulator
8 stars 9 forks source link

New UW Glider simulator interface #34

Closed woensug-choi closed 2 years ago

woensug-choi commented 3 years ago

uw_glider_interface @bsb808 @daewok

daewok commented 3 years ago

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.

daewok commented 3 years ago

Forgot to attach the diagram. uw_glider_interface_revised

woensug-choi commented 3 years ago

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

woensug-choi commented 3 years ago

@daewok Could you share the diagram graphml file?

greg-burgess commented 3 years ago

@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?)

bsb808 commented 3 years ago

I told Woensug I'd take a swing at a standalone ROS node to implement the DR estimation. Will have something for tomorrow.

daewok commented 3 years ago

@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.

woensug-choi commented 3 years ago

The final interface we are converging into. image