Comments (4)
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:
—
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:
—
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 againSo 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:
—
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 againSo 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:
—
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.
Related Issues (20)
- Thrusters...? HOT 1
- Kinematic Simulator HOT 1
- ROSify DVL???? HOT 1
- Fix barebones launch file for simulator
- MOTD for basic system check
- Clean up the Torpedo Challenge Code HOT 1
- Sever / Server typo
- Implement Adaptive Controller HOT 5
- Integrate mil_passive_sonar
- Use mil_pneumatic_actuator HOT 1
- Simulate/Fix kinemetics in gazebo
- Model SubjuGator using URDF
- High Level Archecticure Graph
- Kinematic Simulator HOT 1
- Use dynamics model in state estimation
- Basic Move Test
- SIMULATION: simulate state sensors
- SIMULATION: simulate individual thrusters
- HARDWARE: interface for new thruster board HOT 1
- Model SubjuGator's drag
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from subjugator.