Transition magnetometer and calibration tools about subjugator HOT 4 CLOSED

What exactly was the resolution for all this stuff? I thought what happened
was something along the lines of:

Forrest: There's no reason this stuff can't be written in Python.
Ralph/Jake: Great!

And I don't see how that meshes with closing all these issues.

On Fri, Oct 2, 2015 at 12:03 AM, Jake [email protected] wrote:

Closed #10 #10.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from subjugator.

Cause was additional offline discussion:

• What do we gain from reimplementing this?
  -- Ownership
• Does the code do anything we need to own?
  -- No, it reads data and publishes it
• Do people need to edit this often?
  -- No, it will probably never be touched again

So it is neither wise nor a prudent use of our time to re-do these, when we'd be making no functionality changes. => closing these as wontfix.

A counterpoint to this is that sensor failure alarms must be added. But those changes comprise a different issue group imo.

Do you agree with the above?

• Jake

On Oct 2, 2015, at 12:49 AM, Forrest Voight [email protected] wrote:

What exactly was the resolution for all this stuff? I thought what happened
was something along the lines of:

Forrest: There's no reason this stuff can't be written in Python.
Ralph/Jake: Great!

And I don't see how that meshes with closing all these issues.

On Fri, Oct 2, 2015 at 12:03 AM, Jake [email protected] wrote:

Closed #10 #10.

—
Reply to this email directly or view it on GitHub
#10 (comment).

—
Reply to this email directly or view it on GitHub.

from subjugator.

I'd say that it's very important that at least one person understands the
magnetic hard/soft compensation algorithm and calibration algorithm. And
ooh, the calibration algorithm is actually commented! (Probably because it
absolutely needs it. :P)

Dynamic magnetic compensation wasn't used on Sub2015 because none of the
motors were very close to the IMU (since it was centered), but I'm not sure
if that still applies with the new navigation vessel.

As for the drivers, I suppose it's not very important to rewrite/understand
them, especially for the IMU and depth sensor, which are simple and will
both be replaced anyway.

The DVL, however, does have a lot of different settings and modes, so I
think it's important for someone to be familiar with it. For example, you
didn't know that it tracks the bottom rather than the water mass and
Zach/Jason didn't know that it's configured to output beam velocities
instead of a 3D velocity... Other things that probably aren't generally
known: It's currently configured for a maximum depth of 15 meters, so it
will (presumably) stop tracking if the distance from the DVL to the bottom
is ever greater than that. It has an RTC and a weird bug that's triggered
if the RTC runs for too long, so we set the time/date to "2012/03/04,
05:06:07" on every startup to avoid it. If outputs the distance to the
bottom on /dvl/range, which a lot of missions made use of.

FYI, the DVL manual is available here:
http://www.otronix.com/kr/data/p02/ExplorerDVL_Operation_Manual.pdf , which
is funny since I thought it was covered by an NDA.

So, none of that necessarily necessitates a rewrite, but writing something
yourself is the best way to ensure that you understand it...

On Fri, Oct 2, 2015 at 1:13 AM, Jake [email protected] wrote:

Cause was additional offline discussion:

• What do we gain from reimplementing this?
  -- Ownership
• Does the code do anything we need to own?
  -- No, it reads data and publishes it
• Do people need to edit this often?
  -- No, it will probably never be touched again

So it is neither wise nor a prudent use of our time to re-do these, when
we'd be making no functionality changes. => closing these as wontfix.

A counterpoint to this is that sensor failure alarms must be added. But
those changes comprise a different issue group imo.

Do you agree with the above?

• Jake

On Oct 2, 2015, at 12:49 AM, Forrest Voight [email protected]
wrote:

What exactly was the resolution for all this stuff? I thought what
happened
was something along the lines of:

Forrest: There's no reason this stuff can't be written in Python.
Ralph/Jake: Great!

And I don't see how that meshes with closing all these issues.

On Fri, Oct 2, 2015 at 12:03 AM, Jake [email protected] wrote:

Closed #10 #10.

—
Reply to this email directly or view it on GitHub
#10 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from subjugator.

Anyway, as you want to get into the pool soon, perhaps it is wise to
postpone this for now. Just something to be aware of.

On Fri, Oct 2, 2015 at 2:10 AM, Forrest Voight [email protected]
wrote:

I'd say that it's very important that at least one person understands the
magnetic hard/soft compensation algorithm and calibration algorithm. And
ooh, the calibration algorithm is actually commented! (Probably because it
absolutely needs it. :P)

Dynamic magnetic compensation wasn't used on Sub2015 because none of the
motors were very close to the IMU (since it was centered), but I'm not sure
if that still applies with the new navigation vessel.

As for the drivers, I suppose it's not very important to
rewrite/understand them, especially for the IMU and depth sensor, which are
simple and will both be replaced anyway.

The DVL, however, does have a lot of different settings and modes, so I
think it's important for someone to be familiar with it. For example, you
didn't know that it tracks the bottom rather than the water mass and
Zach/Jason didn't know that it's configured to output beam velocities
instead of a 3D velocity... Other things that probably aren't generally
known: It's currently configured for a maximum depth of 15 meters, so it
will (presumably) stop tracking if the distance from the DVL to the bottom
is ever greater than that. It has an RTC and a weird bug that's triggered
if the RTC runs for too long, so we set the time/date to "2012/03/04,
05:06:07" on every startup to avoid it. If outputs the distance to the
bottom on /dvl/range, which a lot of missions made use of.

FYI, the DVL manual is available here:
http://www.otronix.com/kr/data/p02/ExplorerDVL_Operation_Manual.pdf ,
which is funny since I thought it was covered by an NDA.

So, none of that necessarily necessitates a rewrite, but writing something
yourself is the best way to ensure that you understand it...

On Fri, Oct 2, 2015 at 1:13 AM, Jake [email protected] wrote:

Cause was additional offline discussion:

• What do we gain from reimplementing this?
  -- Ownership
• Does the code do anything we need to own?
  -- No, it reads data and publishes it
• Do people need to edit this often?
  -- No, it will probably never be touched again

So it is neither wise nor a prudent use of our time to re-do these, when
we'd be making no functionality changes. => closing these as wontfix.

A counterpoint to this is that sensor failure alarms must be added. But
those changes comprise a different issue group imo.

Do you agree with the above?

• Jake

On Oct 2, 2015, at 12:49 AM, Forrest Voight [email protected]
wrote:

What exactly was the resolution for all this stuff? I thought what
happened
was something along the lines of:

Forrest: There's no reason this stuff can't be written in Python.
Ralph/Jake: Great!

And I don't see how that meshes with closing all these issues.

On Fri, Oct 2, 2015 at 12:03 AM, Jake [email protected] wrote:

Closed #10 #10.

—
Reply to this email directly or view it on GitHub
#10 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#10 (comment).

from subjugator.