AC Recorder

[9and3]

Description 🤖

This is the PR for the development of the AC Recorder. The objective is to record the 3d fabrication in AC by logging all the informations so that it can be replayed later on Grasshopper.

Here's the features to track and record:

• position of the timber
• position of all the cuts and holes (acim in time?)
• the trajectory of camera
• trajectory of tool head
• type of tool head
• model of tool head (needs to be cached)
• I might miss some ..

Type of feature/changes 🌲

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

[9and3]

Hello @Petingo, as a general approach for the implementation I would start by creating a new space in the code base and work on a brand new layer:

    AIAC::ApplicationSpecification appSpec;
    appSpec.Name = "augmented_carpentry";  // かくちょう_だいく
    appSpec.WinWidth = 800;
    appSpec.WinHeight = 480;
    appSpec.IsResizable = false;
    appSpec.VSync = true;
    appSpec.WindowBackColor = ImVec4(1.00f, 1.00f, 1.00f, 1.00f);

    std::unique_ptr<AIAC::Application> acApp_ptr = std::unique_ptr<AIAC::Application>(new AIAC::Application(appSpec));

    acApp_ptr->GetWindow()->Init();

    acApp_ptr->GetGORegistry()->Init();

    acApp_ptr->PushLayer<AIAC::LayerCamera>();
    acApp_ptr->PushLayer<AIAC::LayerCameraCalib>();
    acApp_ptr->PushLayer<AIAC::LayerSlam>();
    acApp_ptr->PushLayer<AIAC::LayerModel>();
    acApp_ptr->PushLayer<AIAC::LayerToolhead>();
    acApp_ptr->PushLayer<AIAC::LayerFeedback>();
    acApp_ptr->PushLayer<AIAC::LayerUI>();
    acApp_ptr->PushLayer<AIAC::LayerUtils>();
    acApp_ptr->PushLayer<AIAC::LayerRecorder>();    // <------------- here the new layer

    acApp_ptr->GetRenderer()->Init();

    acApp_ptr->GetEventBus()->Init();
    acApp_ptr->Run();

    return 0;

Let's keep the discussion here for the development of this feature! ⭐

[Petingo]

Here's my draft about the overall design:

• Using spdlog's basic file logger function.
• Separate into 2 files, TSlam & TTool

Content in Log File

TSlam

• Frame ID
• Timestamp
• 1 / 0 indicating if the frame is tracked
• If the frame is tracked
  • Translation Vector + Quaternion = 7 floating point number
  • Number of valid Marker ( + ID of the marker seen in the frame, so that we can highlight the marker that is seen in the frame when visualizing?)

TTool

Only record whenever there is an event

• Frame ID
• (Timestamp - optional, I guess it’s better to just use frame ID to align with them timestamp recorded in TSlam’s log)
• Event type
  • Change the type of tool ← initialization step can also be this
  • Manual adjustment
  • Refinement
• Position and Rotation can follow the form of TSlam

[9and3]

Hello @Petingo thanks for the draft!

Here are my general feedback:

• we are missing the .acim model, it evolution (joint fabricated, which joint is active etc) should be tracked too.
• I still have doubts about splitting the log in two. Wouldn't be better to have everything in one?
• the event-based tracking of the ttool is a nice idea but maybe a bit too cumbersome. I would reccomend to record only frames when TSlam is valid andin any case print the: a) type of tool, b) pose (as you suggest for TSlam)
• we should also log the general information such as the http of the zenodo doi (to later redownload the meshes of the tool heads) and the initial pose of the tools.

On a separate note the UI should also be integrated as a floating window maybe (since we will use it very often).

Let me know what you think! ✋

[Petingo]

Hey @9and3,
Thanks for the feedback.

• I totally forgot .acim. I'll look into how to log its information.
• The main purpose of separating the file is to simplify the parser (later when generating the animation). Perhaps it's not needed.
• I suggest only logging the change for TTool since it can dramatically reduce the file size. Given that it'll be a very long sequence, I believe it will be better to log in this way.
• We should have a header block for all the other information.

I'll be in the lab on Wednesday. Hopefully, we can finalize the spec and start the implementation.

[9and3]

• I suggest only logging the change for TTool since it can dramatically reduce the file size. Given that it'll be a very long sequence, I believe it will be better to log in this way.

Sounds good. It will just require to be well thought "when" to fire the event (e.g. when the pose is saved + change of tools as you mentioned before)

I'll be in the lab on Wednesday. Hopefully, we can finalize the spec and start the implementation.

👍

[9and3]

@Petingo , why the hungarian notation m_, it's not needed right?

[Petingo]

You're right. I forgot the naming convension. Updated in 2e66de1

[9and3]

After practical test here's the todos:

• containerize the .ply scan model, the .acim and the TTool's files (config) into one folder than zipped with a custom extension e.g.: .AClog
• add legend at the top of the log
• make button bigger

[Petingo]

I think it's ready to merge now!

[9and3]

LGTM @Petingo ! Did you also patched the bug in #43 by any chance?

[Petingo]

LGTM @Petingo ! Did you also patched the bug in #43 by any chance?

Not yet, should we merge after fixing it?

[9and3]

Not yet, should we merge after fixing it?

No it's ok we can merge this, we'll open another PR for #43