Apparently, it's likely that in a few months the Joey HD chips will have some sort of capacitive sensing for their pads, so it's probably about time to figure out how to add it to the model and macro language. According to Victor, we may get some notion of estimated volume (probably with about a +-20% error), but more likely we'll just get a presence/absence indication.
This has a few implications. First, we'll want to add sensed_drop (a boolean, not a Drop), sensed_volume, and sensed_volume_error (optional) properties to DropLoc and corresponding attributes to the macro language. Probably also a can_sense_drop and can_sense_volume. (I don't know if those are properties of the DropLoc, the Board or both.)
Second, we'll want to use this capability, if present, in drop motion inference. If we think that a pad should have a drop and it doesn't or if it shouldn't and it still does, we should at the very least try to have the model reflect reality. If we can sense volume, we may be able to do better with splits. A bigger question is what to do when what we predict doesn't match what we sense. Do we just accept it and move on? Do we print a warning? Do we throw an exception? Do we try to reason about a pad being broken?
Third, there's the question of what to do with higher-level operations when the motion they expect doesn't happen. Do we allow some notion of "try again a specified number of times"? Do we try to reroute by moving in a different direction? Do we give up?
Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 06, 2022 at 11:30 AM PDT.
Apparently, it's likely that in a few months the Joey HD chips will have some sort of capacitive sensing for their pads, so it's probably about time to figure out how to add it to the model and macro language. According to Victor, we may get some notion of estimated volume (probably with about a +-20% error), but more likely we'll just get a presence/absence indication.
This has a few implications. First, we'll want to add
sensed_drop(a boolean, not aDrop),sensed_volume, andsensed_volume_error(optional) properties toDropLocand corresponding attributes to the macro language. Probably also acan_sense_dropandcan_sense_volume. (I don't know if those are properties of theDropLoc, theBoardor both.)Second, we'll want to use this capability, if present, in drop motion inference. If we think that a pad should have a drop and it doesn't or if it shouldn't and it still does, we should at the very least try to have the model reflect reality. If we can sense volume, we may be able to do better with splits. A bigger question is what to do when what we predict doesn't match what we sense. Do we just accept it and move on? Do we print a warning? Do we throw an exception? Do we try to reason about a pad being broken?
Third, there's the question of what to do with higher-level operations when the motion they expect doesn't happen. Do we allow some notion of "try again a specified number of times"? Do we try to reroute by moving in a different direction? Do we give up?
Migrated from internal repository. Originally created by @EvanKirshenbaum on Jun 06, 2022 at 11:30 AM PDT.