Skip to content
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

Separate logic in various components #1

Closed
mariuszhermansdorfer opened this issue Apr 3, 2019 · 6 comments
Closed

Separate logic in various components #1

mariuszhermansdorfer opened this issue Apr 3, 2019 · 6 comments
Labels
enhancement New feature or request

Comments

@mariuszhermansdorfer
Copy link
Owner

mariuszhermansdorfer commented Apr 3, 2019

Create separate components for:

  1. Initial calibration (including tick rate setting)
  2. Meshing
  3. Point-cloud output
@philipbelesky
Copy link
Collaborator

As part of this separation it would be great if in splitting of (1) the other components could be edited to provide default values for all of the setup parameters.

When initially setting up a definition it is very unclear what the expected number ranges for things like depth or smoothing are. It would also help in the 'out of the box' scenario to be able to just create a new component and be able to immediately see at least some form of output.

@mariuszhermansdorfer
Copy link
Owner Author

Thanks for your feedback, Always good to know what was confusing for first-time users.
Let's brainstorm a bit how the components could work before we create any PRs, shall we? I'll sketch something out and post here.

@mariuszhermansdorfer
Copy link
Owner Author

mariuszhermansdorfer commented Sep 5, 2019

Here are some ideas for the calibration component:

  1. Measure the distance from the sensor to the table. Average the measurement over 100x100 pixels. Output the measurement as the sensorHeight variable

  2. Create a depth value lookup table correcting for inaccuracies in measurement and sensor tilt. Background info here and here

  3. Trim the mesh to the extent of the sandbox

Not sure about the last one. What do you think, @philipbelesky ? Should this be done interactively, like it is now, or moved to an initial setup component and then hidden from the end-user to avoid visual clutter?

@philipbelesky
Copy link
Collaborator

For 1: shouldn't sensorHeight measure the lowest possible point on the model that? E.g. if it is being used to make the size of the elevation color table it seems like it should bottom out there. Automatic measuring wouldn't be able to tell that, although I guess it would give a good enough value for users to tweak later.

I think moving it to a distinct setup component in the long-term would be useful, particularly if additional optional settings are added (to reduce clutter). It would also be useful if additional components are added - e.g. for a raw Point output or for isolating tokens within the sandbox - as it would allow for a number of components to share a single 'setup' parameter rather than needing to rewire everything.

@mariuszhermansdorfer
Copy link
Owner Author

Ad 1. The measurement would happen during the calibration phase, or any time the sensor is moved. One would then calibrate on a flat table, which also represents the lowest possible point on the model.

Let's keep adding our ideas to the list for the setup component and once happy with the overall scope, break these down into individual issues.

@mariuszhermansdorfer
Copy link
Owner Author

Closing this and opening #24 and #40 to track the ideas listed in this thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants