Welded Joints cannot be simulated

[KohmeiK]

Related Issue: https://github.com/orgs/PMKS-Web/projects/1/views/1?pane=issue&itemId=31041516

Explanation

Subset is a part of another link, and it differs from a neighboring link in that it is an additional part of the link that is not the main part.

We have encountered a problem where we cannot run the simulation. To fix this issue, you will need to understand how the data should be structured before being fed into the simulator class. Specifically, you will need to go through the getPathString function within the link class and ensure that neighboring links and joints are set up properly. Simulator does not take subsets into consideration, only neighboring joints and links.

Process to solve bug

1. Reproduce the bug: Try to reproduce the issue that you are experiencing consistently. This will help you to isolate the problem and identify the root cause of the issue.

2. Identify the source of the problem: Once you have reproduced the issue, identify which part of the code is causing the problem. In this case, it appears to be the getPathString function within the link class.

3. Review the code: Once you have identified the source of the problem, review the code to try to identify the specific code block that is causing the issue. In this case, you will need to review the code related to neighboring links and joints within the getPathString function.

4. Add debugging statements: Insert debugging statements into the code to help you track the flow of the program and identify where the issue is occurring. For example, you could add print statements to log the values of variables at various points in the code.

5. Test and verify the fix: Once you have identified the issue and made the necessary code changes, test the program to verify that the issue has been resolved. It is important to test the program thoroughly to ensure that the fix has not introduced any new issues.

By following these steps, you should be able to identify and resolve the issue with the welded joints and have simulator class working properly.

[AlexG1031]

Make sure that tracer joint for welded joints are also determined properly (#10)

[rkprad]

@Kohmei358 and @AlexG1031 The URL to the linkage is not working. Could you update it?

[KohmeiK]

Unfortunately, URLs containing welded joints won't work until we merge the new URL RP

[KohmeiK]

@AlexG1031

src/app/model/mechanism/mechanism.ts Line 136 determineDegreesOfFreedom()

This function is no longer correct since it doesn't consider welded joints.

return 3 * (N - 1) - 2 * J1 - J2;

(The calculation for this mechanism yields -1 instead of 1)

The welded joint should not be considered a type 1 joint. There should only be 4 type 1 joints for the mechanism above, not 5.

[AlexG1031]

Previously, the welded link stored the welded joint twice. This is corrected where now the welded joint is only stored once.

Another bug that occurred was that the neighboring joints were not updated properly. For the welded link, joints B and D (joint connected to C) did not know that they were neighboring joints. This should be fixed now.

In the image above, the simulation now can animate the positions that the mechanism can travel. This only considers the case for creating the mechanism. I will make sure the relations are established correctly when unwelding.

[AlexG1031]

So right now, simulation does work. However, there is a case where adding a link onto a welded link does not update properly...

[AlexG1031]

Alex: Hey Kohmei, just outta curiosity, do you have any ideas on how we can determine which subset is selected based on a mouseclick? I am not sure if we would want to update the activeSelectedObj to have subsets or to determine the subset based on knowing the upper left corner of where the context menu is after right-clicking on a link. I feel first option would be best to be consistent with your logic

From my perspective, I think this should be an easy fix (regarding the bug when adding a link onto a welded joint). Basically, when you add a link on a welded joint, the subset logic is not updated. I can add the logic on how to update properly, but just need to know which subset I am working with

[AlexG1031]

Kohmei: All great points! Here's what I'm thinking: The Active (Selected) Object doesn't need to be updated since as long as the main link is selected, you have access to all the subsets by doing link. subsets . A little off topic but the UI I was planning for this would use the related objects panel when a link is selected. Instead of just showing the length for a binary link, if a compound link is selected that is made of two welded binary links, it might show the length of both of those binary links in a editable field. Anyways, I see two ways to figure out what sublink is selected. One is to use the default HTML object selection detector, which would involve constantly rendering a invisible but clickable outline of each simple link of the compound link over the compound link. (Kinda like what happens now when you select a compound link and the dotted outline shows up). Then when that is right clicked (decorator contextmenu ) you can set the last simple right clicked and keep track of it. Another approach is to use the fuction isPointInsideLInk (src/app/model/link.ts/Line349) which takes in a Coord and RealLink. You could interate over and pass in all the sublinks of the selected link to this function along with the right click point coordinate to figure out which sublink the user meant to click. Let me know if this is confusing, I'm happy to get on a call to explain if needed.

[AlexG1031]

Alex: For the UI you were planning, I like this idea. I think it makes sense to do this. Maybe after this summer, Ansel can work on implementing this after most of the other impending tasks have been completed. For your suggestions, I like them both. Maybe this is a conversation that we should have with Ansel. He may have an idea of an implementation that he would like to do and there may be a way that he would want this to be implemented to make his life simpler. If this is not needed, then I would guess I would the first choice. I like the idea of subset being utilized differently than regular link. I think sometimes, the user can forget how links are attached to each other (which joints correspond to the corresponding subset) and having this be visual would be easiest to keep track off.

Alex: For this task, I imagine maybe it would be best for Ansel to work on this task... He may have better understanding within frontend than me and he will primarily work on this project for awhile.

Just on detecting the desired subset. I am okay on updating the dataset in the backend, unless he would want to do that as well and get an understanding on this. We can discuss this more during scrum and get a feel there.

[KohmeiK]

I'll create a variable that will let Alex know which subset the context was opened from. Also when they left click.

We will add a new variable to the link class lastSelectedSubset By default, it will be undefined If a user clicks on the fillet section it will also be undefined If a user clicks on section with two overlapping subsets it will be undefined Otherwise, this variable will hold the last subset (a pointer) the user selected Alex will use this like a grid.LastLeftClickObj.lastSelectedSubset also grid.lastRightClickObj.lastSelectedSubset

[KohmeiK]

Done with the function!

Use Link.isWelded to see if this this a simple or welded (compound) link. Use If it's welded use link.lastSelectedSublink

[AlexG1031]

User can now add and delete link's onto subsets and update properly. @Kohmei, I believe there is a problem where link.lastSeelctedSublink that does not get updated to be undefined.

This GIF showcases login incorrectly being called. The first instance this is called is correct since the joint was attached to a welded link. However, in the second case, where I delete the floating joint, it should not have recognized there to be a welded link, but there was.

[AlexG1031]

I believe that after this part is finished, I believe welded joints should be 100% ready to be merged with main (trust but verify)