I made two PRs recently (1468 and 1470) that I wanted to propose for community discussion and feedback. They’re quite extensive, but I think they would be very valuable for the repo.
PR 1468 changes the visualizer from updating based on state updates (which results in discrete “teleportation” updates) to modeling how the STAR actually responds to firmware commands with kinematic motion profiles. In my opinion this looks much better, and allows us to reason about protocol timing in a way we could not before. All of the timings are based on a factor model derived from real firmware logs, although I can’t say whether they are 100% accurate for all STARs.
PR 1470 builds on this by incorporating a collision detection feature in the visualizer (which I suppose makes it more of a simulator). Now that we have a complete model of 3D resources and motion profiles, collision detection is not hard in a general sense. It is, however, hard to do quickly and accurately without compromising in either category. PR 1470 solves this in a few ways.
First, it uses convex hull decompositions of certain resource meshes like the iSWAP as a middle ground between collision detection using triangle meshes (millions of triangles in the scene) and bounding boxes (extremely coarse grained, the bounding box for the iswap is enormous). Then, it uses a swept profile of the entire motion path to do a coarse grained check that is expected to quickly return a true negative (ie, an immediate result of no collision) in the vast majority of cases. This prevents us from having to run fine-grained sampling for collisions on each time point when we can easily verify that they will succeed. Finally, only in the case of a potential collision detected in the swept profile, it runs fine-grained sampling on the motion path to detect collisions. It then uses this information to run the motion path and show the user exactly where the collision arises. I’ve found that this all runs very fast on a performance-limited computer.
I would argue that this is quite a useful set of additions that justify their increased complexity. One of the limits of developing robot protocols is there isn’t a really good way to convey to the user exactly what is going to happen when they press go. One of the most common types of collisions is an iswap hitting a deep well plate nearby or opening the gripper too wide. There is basically no way to generically check against this class of error without a fine grained spatial and temporal representation of movements, which these PRs provide. I’d appreciate any and all feedback from the community on these.
