zhrandell / Seattle_Aquarium_CCR_development

This repo serves as a landing pad for active areas of development of our Coastal Climate Resilience (CCR) program. Specifically, this repo houses 1-pager .md documents ready for development, and also a hub to communicate via the Issues tab.
5 stars 1 forks source link

How much control do we want over the USBL integration? #12

Open zhrandell opened 1 week ago

zhrandell commented 1 week ago

An open question to the team: how much control do we want over the USBL integration? Another way to phrase this: do we want to pull roll / pitch data off the GNSS compass?

I ask, as the one remaining (known) source of (avoidable, or minimizable) noise associated with our USBL system is the G2 box's gyros / IMUs, which are likely noisy (if the noisy GPS / compass sensors in the G2 box are any indication), and based on our data thus far from the field, contribute to degraged USBL performance in choppy waters, or when swell is present.

The GNSS compass, however, has super precise roll / pitch, though Clyde confirmed that we cannot feed those data to the G2 box in the same way one of his extensions feeds the GPS / compass data for subsequent integration with the acoustic data.

So, my question . . . if we are going to all of this effort to develop a super slick EKF . . . do we want to rely on the gyros / IMUs in the G2 box, or would we want to pull roll / pitch off the GNSS compass?

I suspect that pulling those data off the GNSS and bypassing the G2 box's gyros / IMUs would require developing our own integration of (1) the raw acoustic data (which would need to be logged; see here) + (2) topside GPS, compass data (which would need to be logged; see here) + (3) topside roll / pitch data (which could very likely be gathered / logged in the same fashion as (2) above).

Another way to think about this . . . would it be useful to compile the integration between (1) - (3) above ourselves? Right now that happens in the proprietary "black box" of WaterLinked's hardware (I think). Would it be useful to have explicit control over the models (and their underlying statistical structure, noise params, etc.) that generate positioning from the USBL system?

I can see appeal here from the perspective of entities that are able to operate the "top-tier" ROV survey system, with USBL + DVL + camera for VO (down the road, of course). On the other land, entities opting for, e.g., VO only via an inexpensive integrated camera, would not have need for this custom (1) - (3) integration (or the USBL at all).

This is without question more work, and thus I'm uncertain if it's a good idea to propose focusing attention here ontop of the ever growing list of mini-projects. This may well not be the direction we want to go. I could also see this as a "down the road" item to pursue if that functionality is still desired, and if bandwidth allows.

Just figured I'd pose the question . . .

What do you think, @clydemcqueen?

clydemcqueen commented 1 week ago

Hmmm... I don't know what the data will tell us. I can think of a bunch of possible solutions, depending on what we see in the data:

So... I suppose I'm saying:

LOG ALL THE THINGS! (insert all-the-things meme)

Re: VO: the SVO implementation I mentioned is feature-based, and so it should do a good job with position hold, but it is not a replacement for a USBL. It will report pos=(0,0) and vel=(0,0) when it can't see the seafloor. Also, it does not maintain a database of features, so it can't do pose recovery and loop closure.

Update: I don't see a way to get roll and pitch out of the G2 box, so we can't compare the sat compass to the G2 box. Worth a query to WL. API here: https://demo.waterlinked.com/swagger/

clydemcqueen commented 1 week ago

Added logging issues #13 #14 #15