[CPP-36]Signals Tab Rough Draft #21

john-michaelburke · 2021-03-25T22:05:11Z

This implements most of the functionality of the Signals Tab and also changes a decent amount of the code structure. I'm hoping to get input on the organization of this code thinking toward scaling to other tabs.

Rust code is broken out to a file per tab (1 so far) and intending all tabs to implement TabBackend trait in types.rs.
- I think the structure in process_messages is somewhat conducive to drop in replacing the sequential approach with some asynchronous handling in the future.
- One thing I have not really thought through is how to send messages from the frontend through to a backend tab struct. I am interested in some suggestions.
- This Tracking Signals Tab does not have the functionality of turning on/off plots with checkboxes as this will require data sent from the frontend.
QML now broken up into nested tab structure.
Added a TrackingSignalsTab struct which implements most of the features from the original console but severed from the Observations tab interdependency.
Left the Velocity Tab untouched until we come to a consensus on design.

console_backend/src/process_messages.rs

console_backend/src/tracking_tab.rs

src/main/python/main.py

resources/TrackingTabComponents/TrackingSignalsTab.qml

resources/TrackingTab.qml

src/main/python/main.py

console_backend/src/constants.rs

console_backend/src/tracking_tab.rs

console_backend/tests/mem_benches.rs

src/main/python/main.py

…aelburke/signals_tab

silverjam · 2021-03-26T17:53:03Z

console_backend/src/tracking_tab.rs

+                }
+            }
+        }
+        //TODO(@johnmichael.burke)[CPP-83]Fix this once implemented reverse communication with backend tabs.


We already have two-way communication to kick off the connection to the Piksi, could we re-use this to populate a "shared state" data structure that would be able to record this kind of information? I agree that long term we should have some sort of framework around this, but it should be fairly simple to build a lock protected Dictionary that would allow the back-end to fetch bits of state like this.

That sounds reasonable to me

Alright I have something working probably could be polished but let me know what you think!

john-michaelburke · 2021-03-26T22:17:22Z

I'm not able run this on Linux using cargo make prod-run I am able to run the console with cargo make run though, however with prod-run I see:

[cargo-make] INFO - Running Task: prod-run
Traceback (most recent call last):
  File "/home/ubuntu/dev/console_pp/src/main/python/main.py", line 28, in <module>
    import console_backend.server  # type: ignore  # pylint: disable=import-error,no-name-in-module
  File "/home/ubuntu/miniconda3/envs/console_pp/lib/python3.8/site-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
    return original_import(name, *args, **kwargs)
ModuleNotFoundError: No module named 'console_backend'

And on Windows I see a different error (prod-run vs run doesn't see to matter:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\jason\dev\console_pp\src\main\python\main.py", line 67, in receive_messages
    TRACKING_SIGNALS_TAB[Keys.LABELS][:] = m.trackingStatus.labels
  File "capnp\lib\capnp.pyx", line 1038, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1036, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1032, in capnp.lib.capnp._DynamicStructReader._get
capnp.lib.capnp.KjException: capnp\layout.c++:2389: failed: expected expectedPointersPerElement <= pointerCount; Message contained list with incompatible element type.
stack: 7ffbde6b0254 7ffbde697f99 7ffbde69837d 7ffbde7a5c59 7ffbde7a532f 7ffbdb21b794 7ffbdb216d17 7ffbdb217c7e 7ffbdb1f0973 7ffbdb1f07a6 7ffbdb21c881 7ffbdb21978d 7ffbdb21b773 7ffbdb21978d 7ffbdb21b773 7ffbdb217b9c 7ffbdb2169eb 7ffbdb1f0973 7ffbdb23ee62 7ffbdb23ede9 7ffc26aa1bb1 7ffc27337033 7ffc291e2650

That looks like the issue fixed in my last PR. I only recently merged in main to this branch. Can you try fetch/pulling the latest of this branch and giving it a shot

resources/TrackingTab.qml

src/main/python/main.py

silverjam · 2021-03-27T19:32:52Z

And on Windows I see a different error (prod-run vs run doesn't see to matter:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\jason\dev\console_pp\src\main\python\main.py", line 67, in receive_messages
    TRACKING_SIGNALS_TAB[Keys.LABELS][:] = m.trackingStatus.labels
  File "capnp\lib\capnp.pyx", line 1038, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1036, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1032, in capnp.lib.capnp._DynamicStructReader._get
capnp.lib.capnp.KjException: capnp\layout.c++:2389: failed: expected expectedPointersPerElement <= pointerCount; Message contained list with incompatible element type.
stack: 7ffbde6b0254 7ffbde697f99 7ffbde69837d 7ffbde7a5c59 7ffbde7a532f 7ffbdb21b794 7ffbdb216d17 7ffbdb217c7e 7ffbdb1f0973 7ffbdb1f07a6 7ffbdb21c881 7ffbdb21978d 7ffbdb21b773 7ffbdb21978d 7ffbdb21b773 7ffbdb217b9c 7ffbdb2169eb 7ffbdb1f0973 7ffbdb23ee62 7ffbdb23ede9 7ffc26aa1bb1 7ffc27337033 7ffc291e2650

That looks like the issue fixed in my last PR. I only recently merged in main to this branch. Can you try fetch/pulling the latest of this branch and giving it a shot

I pulled in this merge before running, but just updated the branch to be sure and I'm still seeing this issue.

john-michaelburke · 2021-03-28T21:13:27Z

And on Windows I see a different error (prod-run vs run doesn't see to matter:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 932, in _bootstrap_inner
    self.run()
  File "c:\users\jason\miniconda3\envs\console_pp\lib\threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\jason\dev\console_pp\src\main\python\main.py", line 67, in receive_messages
    TRACKING_SIGNALS_TAB[Keys.LABELS][:] = m.trackingStatus.labels
  File "capnp\lib\capnp.pyx", line 1038, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1036, in capnp.lib.capnp._DynamicStructReader.__getattr__
  File "capnp\lib\capnp.pyx", line 1032, in capnp.lib.capnp._DynamicStructReader._get
capnp.lib.capnp.KjException: capnp\layout.c++:2389: failed: expected expectedPointersPerElement <= pointerCount; Message contained list with incompatible element type.
stack: 7ffbde6b0254 7ffbde697f99 7ffbde69837d 7ffbde7a5c59 7ffbde7a532f 7ffbdb21b794 7ffbdb216d17 7ffbdb217c7e 7ffbdb1f0973 7ffbdb1f07a6 7ffbdb21c881 7ffbdb21978d 7ffbdb21b773 7ffbdb21978d 7ffbdb21b773 7ffbdb217b9c 7ffbdb2169eb 7ffbdb1f0973 7ffbdb23ee62 7ffbdb23ede9 7ffc26aa1bb1 7ffc27337033 7ffc291e2650

That looks like the issue fixed in my last PR. I only recently merged in main to this branch. Can you try fetch/pulling the latest of this branch and giving it a shot

I pulled in this merge before running, but just updated the branch to be sure and I'm still seeing this issue.

@silverjam I'm not sure what could be happening. Everything seems to run fine run/prod-run on my windows nuc and linux vm. I believe they are running as intended on the self hosted runners as well, will know for sure once they pass the benchmarks.

silverjam · 2021-03-29T03:40:43Z

I pulled in this merge before running, but just updated the branch to be sure and I'm still seeing this issue.

@silverjam I'm not sure what could be happening. Everything seems to run fine run/prod-run on my windows nuc and linux vm. I believe they are running as intended on the self hosted runners as well, will know for sure once they pass the benchmarks.

Looks like it was an issue with how the console_backend module was being installed, see #22 for details.

…aelburke/signals_tab

…, lineseries smaller width, uprevved sbp.

john-michaelburke · 2021-03-29T22:28:04Z

PTAL @silverjam @jayvdb

…aelburke/signals_tab

jayvdb · 2021-03-29T22:59:22Z

console_backend/src/tracking_tab.rs

+                GLO_L10F,
+                GLO_L20F,
+                BDS2_B1_I,
+                BDS2_B2_I,


When this label is enabled/disabled, there is no effect. Same with QZS_L1CA. Seems like it might be related to the data stream not containing these signals, in which case they should be greyed out?

You are correct this is due to no streams from those satellites coming in. I think that is a decent idea to grey them out. I'll create a ticket to add it later on. This is the same behavior in the original console.

Here is the ticket:
https://swift-nav.atlassian.net/browse/CPP-91

silverjam

let's try to resolve @jayvdb's concerns then get this merged, for future PRs it would be great if we can implement some kind of simple unit tests

concerns addressed

john-michaelburke added 5 commits March 17, 2021 12:42

Signals Tab.

a120f5d

Keep working.

c47e04d

Fixed zigzag issue.

71b7744

Better formatting and cleaning up signals plot.

7d99016

Fixed zigzag issue.

5af4140

john-michaelburke commented Mar 25, 2021

View reviewed changes

console_backend/src/process_messages.rs Outdated Show resolved Hide resolved

john-michaelburke commented Mar 25, 2021

View reviewed changes

console_backend/src/tracking_tab.rs Show resolved Hide resolved

john-michaelburke commented Mar 25, 2021

View reviewed changes

console_backend/src/tracking_tab.rs Show resolved Hide resolved

john-michaelburke force-pushed the john-michaelburke/signals_tab branch 2 times, most recently from f88749c to bdeebab Compare March 26, 2021 00:24

Working draft of PR.

aeef1f4

john-michaelburke force-pushed the john-michaelburke/signals_tab branch from bdeebab to aeef1f4 Compare March 26, 2021 01:57