New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mag[i]cal graph #4145

Closed
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@guludo
Contributor

guludo commented May 17, 2016

Hi all,

magcal_graph
The main contribution of this PR is the addition of the local mavproxy module magcal_graph (a.k.a. magical_graph :P).

That module shows the geodesic sections hit by the samples collected during compass calibration, and also some status data. The objective of this module is to provide a reference on how to interpret the field completion_mask from the MAG_CAL_PROGRESS mavlink message. That information can be used in order to guide the vehicle user during calibration.

The plot shown by this module isn't very helpful to the end user, but it might help developers during development of internal calibration support in ground control stations.

The only command provided by that module is magcal_graph, which will open the graphical user interface.

I've done a quick demo using it in combination with compass calibration simulation: https://youtu.be/HSrXM2ETjdI

Note: I've added a file Tools/mavproxy_modules/lib/geodesic_grid.py, which might be seen as a duplication of things in libraries/AP_Math/tools/geodesic_grid/icosahedron.py and libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. However, I think the former is very simple and I thought that wasn't worth moving and editing files around just to make both Tools/mavproxy_modules/lib/geodesic_grid.py and libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py use the same module. Furthermore, @tridge showed interest on applying this to mavproxy's tree during the las devcall and this would make it simpler to do it.

Previous commits
This PR also does:

  • add a new option --section to libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. That was helpful for me to check that the magcal_module was working properly.
  • enable the use of the "calibration" model in sim_vehicle.py.
  • and other minor enhancements.

Best regards,
Gustavo Sousa

guludo added some commits May 12, 2016

Tools: sitl_calibration: add note on using calibration model
This can avoid users having problems as reported at issue #4088 ("Calibration
not working in sitl").
Tools: sim_vehicle: add calibration frame
The module `sitl_calibration` is loaded for convenience.
Tools: sim_vehicle: allow passing keywords to run_cmd_blocking
That is redirected to subprocess.Popen().
Tools: sim_vehicle: add local mavproxy modules path to PYTHONPATH
That's helpful for users that don't have that in their PYTHONPATH environment
variable and want to load a local module.
Tools: magcal_graph: add mavproxy module
That is added as a reference implementation on how to interpret the field
`completion_mask` from the `MAG_CAL_PROGRESS` mavlink message.
@WickedShell

This comment has been minimized.

Show comment
Hide comment
@WickedShell

WickedShell May 17, 2016

Contributor

I haven't looked into the onboard cal stuff extensively yet, but is there a
way to get a feedback for the grid for where the user is pointing the
aircraft? IE thats the most helpful part of MP's white dot that rotates is
thats the last sample and gives you an idea where to move the aircraft.

On Tue, May 17, 2016 at 6:33 AM, Gustavo José de Sousa <
notifications@github.com> wrote:

Hi all,

magcal_graph
The main contribution of this PR is the addition of the local mavproxy
module magcal_graph (a.k.a. magical_graph :P).

That module shows the geodesic sections hit by the samples collected
during compass calibration, and also some status data. The objective of
this module is to provide a reference on how to interpret the field
completion_mask from the MAG_CAL_PROGRESS mavlink message. That
information can be used in order to guide the vehicle user during
calibration.

The plot shown by this module isn't very helpful to the end user, but it
might help developers during development of internal calibration support in
ground control stations.

The only command provided by that module is magcal_graph, which will open
the graphical user interface.

I've done a quick demo using it in combination with compass calibration
simulation: https://youtu.be/HSrXM2ETjdI

Note: I've added a file Tools/mavproxy_modules/lib/geodesic_grid.py,
which might be seen as a duplication of things in
libraries/AP_Math/tools/geodesic_grid/icosahedron.py and
libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. However, I think
the former is very simple and I thought that wasn't worth moving and
editing files around just to make both
Tools/mavproxy_modules/lib/geodesic_grid.py and
libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py use the same
module. Furthermore, @tridge https://github.com/tridge showed interest
on applying this to mavproxy's tree during the las devcall and this would
make it simpler to do it.

Previous commits
This PR also does:

  • add a new option --section to
    libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. That was
    helpful for me to check that the magcal_module was working properly.
  • enable the use of the "calibration" model in sim_vehicle.py.
  • and other minor enhancements.

Best regards,

Gustavo Sousa

You can view, comment on, or merge this pull request online at:

#4145
Commit Summary

  • AP_Math: geodesic_grid tool: add option --section
  • AP_Math: geodesic_grid tool: show triangle number for sections too
  • Tools: sitl_calibration: add note on using calibration model
  • Tools: sim_vehicle: add calibration frame
  • Tools: sim_vehicle: allow passing keywords to run_cmd_blocking
  • Tools: sim_vehicle: add local mavproxy modules path to PYTHONPATH
  • Tools: magcal_graph: add mavproxy module

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4145

Contributor

WickedShell commented May 17, 2016

I haven't looked into the onboard cal stuff extensively yet, but is there a
way to get a feedback for the grid for where the user is pointing the
aircraft? IE thats the most helpful part of MP's white dot that rotates is
thats the last sample and gives you an idea where to move the aircraft.

On Tue, May 17, 2016 at 6:33 AM, Gustavo José de Sousa <
notifications@github.com> wrote:

Hi all,

magcal_graph
The main contribution of this PR is the addition of the local mavproxy
module magcal_graph (a.k.a. magical_graph :P).

That module shows the geodesic sections hit by the samples collected
during compass calibration, and also some status data. The objective of
this module is to provide a reference on how to interpret the field
completion_mask from the MAG_CAL_PROGRESS mavlink message. That
information can be used in order to guide the vehicle user during
calibration.

The plot shown by this module isn't very helpful to the end user, but it
might help developers during development of internal calibration support in
ground control stations.

The only command provided by that module is magcal_graph, which will open
the graphical user interface.

I've done a quick demo using it in combination with compass calibration
simulation: https://youtu.be/HSrXM2ETjdI

Note: I've added a file Tools/mavproxy_modules/lib/geodesic_grid.py,
which might be seen as a duplication of things in
libraries/AP_Math/tools/geodesic_grid/icosahedron.py and
libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. However, I think
the former is very simple and I thought that wasn't worth moving and
editing files around just to make both
Tools/mavproxy_modules/lib/geodesic_grid.py and
libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py use the same
module. Furthermore, @tridge https://github.com/tridge showed interest
on applying this to mavproxy's tree during the las devcall and this would
make it simpler to do it.

Previous commits
This PR also does:

  • add a new option --section to
    libraries/AP_Math/tools/geodesic_grid/geodesic_grid.py. That was
    helpful for me to check that the magcal_module was working properly.
  • enable the use of the "calibration" model in sim_vehicle.py.
  • and other minor enhancements.

Best regards,

Gustavo Sousa

You can view, comment on, or merge this pull request online at:

#4145
Commit Summary

  • AP_Math: geodesic_grid tool: add option --section
  • AP_Math: geodesic_grid tool: show triangle number for sections too
  • Tools: sitl_calibration: add note on using calibration model
  • Tools: sim_vehicle: add calibration frame
  • Tools: sim_vehicle: allow passing keywords to run_cmd_blocking
  • Tools: sim_vehicle: add local mavproxy modules path to PYTHONPATH
  • Tools: magcal_graph: add mavproxy module

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#4145

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi May 17, 2016

Contributor

With this current PR, no. But it could be added on top

Contributor

lucasdemarchi commented May 17, 2016

With this current PR, no. But it could be added on top

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi May 17, 2016

Contributor

A little bit more context: in this PR it's exposing only the bitmask of the onboard magcal (for each mag). GCS is expected to use this information and others it already has in order to do a useful user interface.

Contributor

lucasdemarchi commented May 17, 2016

A little bit more context: in this PR it's exposing only the bitmask of the onboard magcal (for each mag). GCS is expected to use this information and others it already has in order to do a useful user interface.

@WickedShell

This comment has been minimized.

Show comment
Hide comment
@WickedShell

WickedShell May 17, 2016

Contributor

Is it reasonable for the GCS to just overlay the current orientation over
that grid? Or at a higher level does more need to be communicated to the
GCS?

On Tue, May 17, 2016 at 2:05 PM, Lucas De Marchi notifications@github.com
wrote:

A little bit more context: in this PR it's exposing only the bitmask of
the onboard magcal (for each mag). GCS is expected to use this information
and others it already has in order to do a useful user interface.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4145 (comment)

Contributor

WickedShell commented May 17, 2016

Is it reasonable for the GCS to just overlay the current orientation over
that grid? Or at a higher level does more need to be communicated to the
GCS?

On Tue, May 17, 2016 at 2:05 PM, Lucas De Marchi notifications@github.com
wrote:

A little bit more context: in this PR it's exposing only the bitmask of
the onboard magcal (for each mag). GCS is expected to use this information
and others it already has in order to do a useful user interface.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4145 (comment)

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi May 18, 2016

Contributor

@WickedShell I think it is. However we will need to experiment with it to make the best user experience.

Contributor

lucasdemarchi commented May 18, 2016

@WickedShell I think it is. However we will need to experiment with it to make the best user experience.

@lucasdemarchi

This comment has been minimized.

Show comment
Hide comment
@lucasdemarchi

lucasdemarchi May 18, 2016

Contributor

Applied, thanks.

Contributor

lucasdemarchi commented May 18, 2016

Applied, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment