I'm not seeing some kind of thread suited to
Robowaifu Motion Planning, or am I missing it? It seems to me this is a very-important topic, and one that is kind of general as well. That is, we need to plan the motions of:
-the robowaifu herself (as a unified system), through say, Anon's flat
-the robowaifu's arms & other (internal/onboard) skellington components, as she's going about her day-to-day tasks
-other 'objects' in motion around the robowaifu (say, of Anon himself), for her predictive planning purposes.
<--->
What got me thinking about this need was trying to figure out where to post this link :
https://www.youtube.com/watch?v=8D7vpR9WCtw
Making Hard C++ Tests Easy: A Case Study From the Motion Planning Domain - Chip Hogg - CppCon 2024
>If you've ever struggled to write tests for domain-specific functions with complicated, real-world inputs, this talk is for you! We'll use the Motion Planning component in a self-driving stack as a case study (although you won't need any prior Motion Planning experience to follow the talk). In building objects for our test inputs, we faced the classic dilemma. If we make the objects simple, they're hardly meaningful, and the tests amount to little more than smoke tests. If we try constructing more realistic objects, it takes tremendous amounts of boilerplate code (which obscures what is actually being tested) --- and what's worse, these finicky construction methods go stale and break easily as implementation details evolve.
>There is a better way! To find it, we take our inspiration from a (paraphrased) Kent Beck quote: "First, make the test easy. (Warning: this may be hard!) Then, write the easy test." What this means is investing in full-fledged testing support libraries. First, we build foundational domain-specific APIs: user-friendly paths, poses, and speed profiles. Then, we provide APIs that bridge the gap between what the user pictures in their head when they want to write a test (a "scene"), and the data structures that represent that situation in the software (a sequence of planner input messages on different channels). This "scene description" that the user writes is high level and doesn't depend on implementation details, so it resists going stale, as we'll illustrate with an example involving road construction zones. On the implementation side, the problem decomposes beautifully: each planner input (map, actors, etc.) can be constructed from the information in the scene description, independently of all other inputs, helped along by the paths and speed profiles.
>These ideas could be implemented in many languages, but C++ particularly excels at delivering performance, robustness, and flexible, natural APIs. As an example, we'll explain the benefits of describing each planner input with a "smart" tag type, containing both the name and the message type. On the implementation side, variadic templates make it easy to conjure up containers and interfaces that operate on "all planner inputs", eliminating the risk of forgetting to update some callsite when we add a new one. On the interface side, end users see none of this complexity: they can simply use instances of these tag types as "indexes" into these containers in a natural way. This fluency and power makes more complicated test cases possible: it becomes easy to select and "tweak" any planner input to ensure we respond correctly when the messages are malformed, delayed, or absent. Overall, we hope our experience enabling high-quality Motion Planning testing at scale will have lessons that can be adapted to a variety of other domains.
<--->
I thought about using our systems engineering bread : (
>>98 ), b/c solving this certainly involves making a lot of different 'moving parts' work successfully together. I thought about our self-driving car bread : (
>>112 ), for obvious reasons. I briefly considered just using the C++ bread(s) for this, since it's definitely a 'real-time performance needs' set of engineering tasks. I also thought of our 'Newton's Dance' bread : (
>>7777 ). :^)
Ideas? Am I missing something here Anons?
>===
-
minor editEdited last time by Chobitsu on 02/20/2025 (Thu) 17:50:37.