Add drop-test protocol, Edison synthesis, and first-data analysis#82
Conversation
|
@claude are you able to work on this new PR? |
|
Claude finished @sgbaird's task in 1m 24s —— View job Yes — I'm able to work on this PR ✅I successfully checked out Current state of this branch
Ready when you arePer the triggering comment on #67, the outstanding asks appear to be: (1) pick up the analysis where the earlier Claude run left off, and (2) verify that all raw CSV files posted across PR #67's comments are committed and organized on the branch. I can do both here — just @-mention me with the go-ahead (or point me at any specific comment attachments you want cross-checked), and I'll audit the committed CSVs against the PR #67 comment history and commit anything missing. |
…sis + data-completeness audit
@claude Yes, do this. Make sure you're using the GitHub CLI or similar so that you're not missing hidden comments on a pull request @ctrhjk looks like for whatever reason, we won't be able to use the prior pull request. Maybe has something to do with how many comments we've put on there 😅 |
|
Claude finished @sgbaird's task in 8m 25s —— View job Audit complete — all raw data from PR #67 is committed, verified byte-for-byte ✅
1. Data-completeness audit (via GitHub API, full pagination)I fetched all 98 issue comments plus the PR body, review comments, and reviews for #67 through I then downloaded every one of the 269 unique CSV URLs and all 16 ZIPs and SHA-256-compared them against the committed files, not just name-matched:
Notes resolved along the way:
Verdict: no gaps. All 669 raw CSVs on the branch are byte-identical to what was posted on the thread, and no posted CSV/ZIP is absent from the repo. @sgbaird this branch is safe to use as the new home for the thread — the full data record from #67 is here. 2. Picking up where the earlier Claude runs stalledThe stalled runs were on @ctrhjk's check2 ask (#67 comment: "another 30 drops… diagnose whether the same problem exists"). That work already landed on this branch in 3. What I changed (1 commit,
|
…e-level (SHA-256) completeness audit of every PR #67 attachment Co-authored-by: Sterling G. Baird <45469701+sgbaird@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@claude do what Jinkwan was requesting in that other PR this was based on
Double check this. Sometimes you say things are identical but they're actually not Make sure that you aren't missing files or commits from that old branch to this new branch |
|
Claude finished @sgbaird's task in 5m 30s —— View job Re-verified from scratch — all three checks pass, nothing missing ✅
1. Jinkwan's request: check2 diagnosis — independently reproduced, numbers confirmedJinkwan's outstanding ask on #67 (comment, re-pinged here) was to analyze the 30
2. The "436 attachment links" claim — re-derived independently, and it holdsI re-fetched the PR #67 body, all 98 issue comments, review comments (0), and reviews (0) via Then, instead of reusing anything from the previous run, I re-downloaded all 285 unique file attachments fresh (644 MB of loose CSVs + 321 MB of ZIPs), extracted the ZIPs (400 member CSVs —
So the earlier "byte-identical" claim was accurate — this time established from a clean re-download rather than asserted. 3. Old branch → new branch: nothing missing
Bottom line: Jinkwan's check2 analysis is complete and its numbers reproduce exactly; the 436-link count and the byte-level completeness audit both survive an independent redo; and this branch is a strict superset of the old one. No changes were needed, so nothing new was committed. --- · Branch |
|
Based on your analysis in #67 (comment), present some reasons why the ch4 and ch5 triggers couldn't detect the acceleration in 5 in drop test. |
|
Claude finished @ctrhjk's task in 4m 13s —— View job Why the CH4 and CH5 triggers (1000 G) missed the 5-in drops on
|
| run | CH4 raw |peak| | CH5 raw |peak| | margin over 1000 G |
|---|---|---|---|
RW5F61, 13 in (CH4-trigger, 50 drops) |
3,239–3,655 G | 5,500–8,100 G | 3.2–8.1× |
7xadt6, 10 in (200 drops) |
2,951–5,370 G | 3,609–6,245 G | 3.0–6.2× |
RW5F61, 5 in (100 drops) |
1,433–1,865 G | 1,964–3,104 G | 1.43× worst case |
7xadt6, 5 in (practice) |
no trigger | no trigger | < 1× on both |
So at 5 in the margin was already nearly gone in the best-documented case, and on 7xadt6 it evidently crossed below 1. The likely reasons, ranked:
1. The 1000 G level left almost no margin at 5 in to begin with
The RW5F61 5-in campaign bottomed out at 1,433 G on CH4 — only 1.43× the level (5-in analysis §1). That analysis explicitly recommended lowering the trigger to ~500 G for 5-in work before the 7xadt6 practice drops happened. With only ~30 % of headroom, any one of the effects below is enough to kill the trigger; several likely stacked.
2. The raw spike collapses much faster than √h
√h scaling from 7xadt6's 10-in peaks predicts ~2.1–3.8 kG (CH4) and ~2.6–4.4 kG (CH5) at 5 in — "safely" above 1000 G. But the raw spike is a short bottoming-out transient that is strongly nonlinear in drop energy: measured 13 → 5 in on RW5F61, CH4's raw peak fell to 0.47× where √h predicted 0.62× (the CFC-180 level only fell to ~0.73×). The trigger listens to exactly the part of the waveform that dies fastest as severity drops, so √h intuition systematically overestimates trigger margin at low heights.
3. 7xadt6 is a fresh, compliant print; RW5F61 was a stiff, exercised one
The 1.43× margin was measured on a failed print with ~280 cumulative drops — a much stiffer structure. A compliant intact tensegrity can absorb a 5-in impact without the sharp bottoming-out that generates the kG-scale spike at the TOP station, keeping CH4 sub-kG entirely. If this is what happened, it's actually useful signal (severity sweeps may discriminate geometry better than a fixed height) — reading 1 in the 200-drop analysis §7.
4. CH4 is a single axis of a demonstrably rotating tri-axis
The trigger fires on one axis, not the resultant, and both key seats rotate in their pockets (CH7 raw went 127 → 199 G at near-constant resultant; CH4's own raw peak drifted +24 % over the 5-in campaign while the resultant rose only ~9 %). Sensors were re-seated for the new specimen with orientation unverified — an unfavorable seat rotation on setup day takes tens of percent off the axis-projected raw peak, which the thin margin couldn't afford.
5. CH5's tape coupling attenuates exactly the frequencies the trigger needs
Tape is a compliant mount that low-passes the kHz content the raw spike is made of, and its state demonstrably moves around: the 200-drop campaign caught a mid-campaign CH5 excursion, and both check runs show the coupling durably stepped down ~6–8 % (T stuck at 1.083 vs healthy 1.025) — and that's at CFC-180; the attenuation of the raw high-frequency spike is larger. A soft/fresh tape layer on practice day plausibly shaved CH5's spike substantially.
6. A setup/load-path difference can't be excluded — and never can be
For CH5 in particular, the arithmetic is demanding: its weakest 10-in peak was 3,609 G, so missing at 5 in requires a collapse to < 28 % — steeper than anything measured from height alone. That points to a contribution from the coupling (reason 5) and/or a genuine rig difference at the 5-in setting. There's precedent for the latter: the clip-height experiment produced 0/8 no-trigger drops with a perfectly healthy sensor chain, purely from load path, and the release fixture at the 5-in setting was already flagged (the +9 % monotonic input hardening). The catch is structural: an untriggered drop records nothing, so no waveform exists to falsify any of this — which is itself the strongest argument for the fix below.
The fix (already in the SOP)
Trigger level, not height, is the severity knob. Pre-impact activity is ≤ 9–35 G in every campaign, so at 5 in a 300–500 G level restores ~3× margin with ≥ 10× clearance above the noise floor (even 100 G would be safe). If 5-in campaigns are wanted for 7xadt6-class fresh prints, drop the level first and run one practice capture to measure the actual raw peaks — that single waveform would tell us which of reasons 2–6 dominated.
Question-only task — no repo changes were made.
· Branch
|
Claude finished @ctrhjk's task in 7m 25s —— View job 5 in vs 10 in comparison done — 60/60 triggered at 500 G; recommend 10 in for the BO campaign ✅
1. The 500 G trigger fix works — the 5-in problem is solved
Interesting detail: this session's 5-in raw peaks (min 1,936 G) would have cleared even the old 1000 G level — unlike the earlier 2. Head-to-head metrics (CFC-180, 30 drops each, mean and CV)
3. Recommendation: standardize BO at 10 in, trigger at 500 GWith 500 G, trigger reliability no longer constrains the choice, so it comes down to:
Keep 5 in as the validated gentle operating point: it has the best T repeatability of the pair (CV 0.39 %), 31 % lower levels, and 1.44× lower Δv — the right choice if BO explores fragile/soft geometries that repeated 10-in hits could damage, and a well-behaved second point for a future two-severity objective (the √h scaling makes severity sweeps predictable). Committed (
|
…) + analysis and BO height recommendation 60 auto-drops posted by @ctrhjk on PR #82 (30 at 5 in, 30 at 10 in, CH5 trigger lowered to 500 G): 60/60 triggered (worst margin 3.9x at 5 in), CH7/CH8 saturation improves at 5 in but is not cured, all CFC-180 metrics hold CV < 1% at both heights, levels scale ~sqrt(h) while raw peaks scale 2.6x. Recommendation: standardize BO at 10 in with the 500 G trigger; keep 5 in as the validated gentle operating point. Co-authored-by: Jinkwan Han <282969777+ctrhjk@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
@claude |
|
Claude finished @ctrhjk's task in 2m 40s —— View job Short answer: 10 in is already the right height; the trigger level is the one number I'd change — to 300 G
Trigger level — yes, I think 300 G is better than 500 GThe trigger level lives between two hard bounds measured across the program:
At 10 in, 500 G is already excellent (worst margin 10.7×, pre-impact clearance 62×) — there's no meaningfully better number for a 10-in-only campaign, and I wouldn't chase one. The reason I'd still move to 300 G as the standing level is the one documented failure: the
I would not go below ~200 G: the floor is set by the worst observed pre-impact activity (35 G), and arming/handling transients between drops aren't characterized — 100 G is probably safe (the 200-drop doc says as much) but buys nothing over 300 G except risk. And since trigger time is pinned by the pre-trigger buffer (first crossing 3.895–3.896 ms with µs-level jitter at every level tested), the level doesn't affect the metrics at all — only capture reliability. One cheap SOP addition beats any fixed number: one practice capture at the start of each session, check the raw CH5 peak, and confirm ≥ 3× margin before starting the batch. Drop height — no better number in the measured evidence; 10 in standsWhat "better" could mean, checked against data at the three measured heights (5, 10, 13 in):
So within what's been measured, 10 in + a 300–500 G trigger is the optimum, and I don't think an untested intermediate height (7–8 in) offers anything: it would inherit 5-in's weaker interrogation without solving BOT, and would need its own wear baseline. The honest caveat: the actual "best height" criterion for BO is which height best separates geometries, and that's only ever been measured at one severity (13 in, hot-glue era). T being nearly height-invariant on one specimen (1.138 vs 1.125) is encouraging but not the same thing. If you want to close that question before locking the BO campaign, the decisive experiment is small: 2 distinct geometries × 2 heights (5 in and 10 in) × ~10 drops each (~40 drops, one session) — if the between-geometry T gap is as large at 10 in as at 5 in, 10 in is confirmed; if the gap grows with severity, that's also worth knowing because it suggests severity sweeps as a future richer objective (the clean √h scaling of the CFC-180 levels makes those well-behaved). Bottom line
Question-only task — no repo changes were made. |
|
@claude in a similar vein, look at the search space parameters in #35 especially in that Bayesian optimization script, and considering the fixed mass and the volume constraint, comparing that with the volume of the print being tested here, which I believe is a downscaled version from the size that we were using a month or two ago. My main point here is that something that is near saturation for the current print parameters may not be viable for all designs within the search space, and it would be unfortunate if we had to more or less restart the campaign with different parameters because our sensors couldn't handle the full range of the kinds of prints that we'll be doing. |
|
Claude finished @sgbaird's task in 10m 44s —— View job Sensor headroom vs. the #35 BO search space — your concern is right, and it's quantifiable: one channel is already censored even for today's small print; the rest clear the whole box at 10 in, with two specific restart-risks to close before the campaign starts
1. Where the print being tested sits inside the #35 search spaceYour recollection checks out in the CAD:
So the durability/saturation baseline was measured on a specimen in the light, soft third of the box: the space contains designs up to ~3.6× its mass, 3× its strut cross-section (9× bending stiffness), 4.4× its bounding volume, and struts down to L/D 5.2 (vs 12.4 tested) — plus, in the other direction, designs lighter than anything tested. Also worth stating plainly: neither BO script actually enforces a mass or volume constraint — PR #30's scaffold only uses mass inside its dummy SEA simulator, and the #35 Sobol generator constrains nothing — so today the box really does span that full 5.6× mass range. If mass/volume are program constraints (per your framing on the #35 thread), they need to be implemented, not assumed. Fix this → 2. Channel-by-channel: can the sensors cover that range? (measured at 10 in, 500 G trigger, from
|
| channel | full scale | today's raw peak (S0 print) | worst case over the box | verdict |
|---|---|---|---|---|
| BOT CH6–8 (bottom vertex, low-range) | 989–1002 G | median 76–105 % FS, clipping on up to 26/30 drops | only worse — stiffer designs transmit more | already censored; cannot cover any of the space |
| CH5 (base-plate input, trigger) | 9,443 G | 64 % FS max | ~unchanged — input is rig-set, not specimen-set (235–248 G CFC-180, CV ≤ 1.7 % across 4 different geometries) | safe at 10 in; not at 13 in (86 % FS already observed there) |
| TOP CH2–4 (top vertex, output) | 13,624–14,993 G | 37 % FS max (CH4) | physical ceiling ≈ rigid transmission of the input spike ≈ 6.1 kG = ~45 % FS; even 2× ringing amplification stays ≤ ~90 % | safe for the whole box, incl. the L/D 5.2 corner |
| trigger reliability | 500 G on CH5 | 3.9× worst margin | design-independent (input-side trigger) | safe — soft designs can't cause no-trigger |
The one place your fear is already reality is BOT: it clips today on the small, soft print (and 5 in doesn't cure it — 94 % FS median), so every BOT waveform in the campaign would be amplitude-censored, worst for exactly the stiff designs BO will want to compare. That decision — re-range/replace the bottom tri-axis (your July 10 note about ~$1–2k higher-range sensors, or the LDV), or formally drop BOT from the objective stack — should be made before trial 1, because it's the only thing on the table that would genuinely force a mid-campaign restart. TOP + CH5 at 10 in, by contrast, have enough headroom that even a perfectly rigid specimen can't clip them.
3. Three interaction traps between the scale change and the search space
- The box is written in 1.5×-era absolute mm. If the program has standardized on S0-size prints (done for auto-support + housing reasons), the box's own center of mass is off — and note you cannot just multiply the bounds by 0.7692: the cable_d floor would drop to 2.3 mm, below the empirically-established 3.0 mm Bambu printability floor that's baked into the current bounds. Any re-scoping has to keep
cable_d ≥ 3.0absolute. Deciding the box now matters for exactly the reason you give — shrinking or shifting bounds after the GP has data is a soft restart. - The sensor housings don't scale (deliberately — they're absolute-mm physical pockets,
t3-prism.scadL244). A fixed instrumented-head mass is a much bigger fraction of a 16 g corner design than an 88 g one, so mass-loading bias in T varies ~5× across the box, systematically correlated with specimen mass — a confound the GP can't separate. Cheapest mitigation: weigh every print and log it per ID (this is the still-unansweredbatch01.csvmetadata ask from May 22, which would also calibrate the mass model above), and consider a mass floor if the light corner isn't interesting. - Rig fit: the heaviest corner is ~80 mm footprint × ~145 mm tall with housings, vs the S0 print's ~58 × 115 mm. The release clip / cap-upward-travel fixtures and the 3×3 plate-packing cell (86.9 mm) were tuned in the S0/1.5× era — worth a dry-fit check before BO proposes a big design.
4. What I'd actually do (cheap insurance vs. restarting)
- Resolve BOT now — re-range, replace, or drop. Only real restart risk.
- Corner-qualification session (~30 drops, one sitting) before trial 1: print the stocky-stiff corner (R25/H60/strut_d 12) and one max-mass-class design, 10 drops each at 10 in / 500 G alongside an S0-class reference. That converts my "rigid-transmission ceiling ≈ 45 % FS" bound from extrapolation into a measurement, and verifies trigger + CH5 margins at the stiff end.
- Stay at 10 in — one more reason on the pile: CH5's 13-in headroom (86 % FS on a soft print) is the kind of margin a stiff search-space design eats.
- Implement the mass/volume constraints in the generator and log as-printed mass per ID — closes both the constraint gap and the mass-loading confound, and finally ties IDs back to parameters (still open since May 22).
Question-only task — no repo changes were made. Mass numbers are solid-infill volume-model estimates; one kitchen scale session on existing prints would calibrate them.
· Branch
|
This test was done with the specimen in #35 (comment) Drops couldn't be gone to 500 times, because at the 256th drop, I realized Lansmont Test Partner 4 showed an overload condition, and all the signals were disconnected. Here are the data measured. Drop height was 10 in. 500drops_1.zip Analyze these data, and report the result in connection with the overload condition. |
|
Claude finished @ctrhjk's task in 11m 44s —— View job Overload diagnosed: CH6 walked over its 1,002 G full scale — first at drop 118, continuously from drop 134 to the stop at 256. Nothing physically disconnected; the specimen shows no structural-failure signature. ✅
1. What tripped the overloadA TP4 overload means a channel's input exceeded its calibrated range, and exactly one channel did that — CH6, one axis of the low-range bottom-vertex tri-axis (FS 1,002 G):
So by the time you saw the overload at drop 256, CH6 had been over its range on essentially every drop for the previous ~120 drops. And its path there was not a slow drift but a transition event: flat at ~475 G (≈47 % FS) for the first ~96 drops → rapid climb over drops ~97–130 → a censored shelf at ~105 % FS for the rest of the run. Suggestively, the ~122 Hz low ringdown mode (the old 200-drop watch item, absent in both check runs) flickered on exactly 3 of 256 drops — Signals 94, 96, and 130 — bracketing that same transition window. The BOT resultant grew only ~+11 % while CH6 alone grew +127 % (and CH7 partially mirrored it), so the reading is bottom-vertex key-seat rotation re-projecting the resultant onto CH6, on top of a genuine ~10 % rise in bottom-vertex transmission — plausibly a settling/stretching event in this specimen's three bubbled diagonal TPU tendons. Worth inspecting/re-seating the bottom sensor and photographing the tendons before the next run. 2. "All signals disconnected" — reassuranceNothing in the data disconnected. All seven channels are alive with normal noise floors and offsets on all 256 captures, including Signal 256 itself (a perfectly normal impact). The disconnect display is the TP4's reaction to the latched overload state, not a sensor/cable failure. All 256 captures are fully usable — except CH6's amplitudes after ~Signal 118, which are range-censored (the ~1,050–1,087 G shelf is the digitizer ceiling, not physics). 3. The failure test itself: the specimen did not fail in 256 drops
Despite the bubbled tendons, transmissibility is flat, the pulse shape is constant, and the ringdown mode is ~549 Hz on 253/256 drops — no structural-failure signature. What did drift is the delivered severity: input and output declined together (Δv −11 %, raw spikes −20 to −29 %) while their ratio stayed put — a rig/severity drift, the same slow decline seen in earlier long campaigns, now over its longest run. Two program notes: the 300 G trigger is validated at scale (256/256 clean, µs jitter, 30× above the worst 9.9 G pre-impact activity — it played no role in the stop), and this fresh print pushed CH5 to 83.6 % FS at 10 in (vs ~62 % for 4. Before re-running the 500-drop test
Committed (
|
…gnosis: CH6 walked over its 1002 G full scale from ~drop 118 (sustained from 134), tripping the TP4 overload; no channel physically disconnected, 300 G trigger 256/256, specimen shows no structural-failure signature (T flat at ~1.087) Co-authored-by: Jinkwan Han <282969777+ctrhjk@users.noreply.github.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
This test is 500 drops test, which means that the drops were conducted 500 times. The specimen used for this test is the same specimen as I used yesterday (see #82 (comment)). Conduct the OLS regression analysis, and assess the need for the bottom tri-axis accelerometer compared to the result in #82 (comment). Video link: https://youtu.be/uqn3qnJPfN8?si=agZOEUQYR_Ive12C Here are the results |
|
Claude finished @ctrhjk's task in 12m 0s —— View job 2nd 500-drop test analyzed: removing the bottom tri-axis cured the stop — 500/500 complete, no channel near full scale; OLS shows the specimen still hasn't failed at ~756 cumulative drops; recommend keeping BOT off for long/BO campaigns at 10 in ✅
1. Run health — the overload diagnosis is confirmed by cure500/500 real drops, zero spurious triggers, ~18 s cadence (18:24–20:41, ~137 min), CH5 crossing 300 G at 3.896 ± 0.000 ms on every record, worst pre-impact activity 10.4 G (29× below the level). And the saturation audit is now boring, which is the point:
Last run the only channel that could trip the TP4 was BOT, and it did (CH6 over FS from drop 118). This run there was nothing left to overload, and the campaign ran to completion. 2. OLS regressions vs drop number
3. Is the bottom tri-axis needed? Not for this program at 10 inThe honest accounting, using run 1's own data: during run 1's CH6 transition (drops ~97–134, the event that tripped the overload), the channels that survive into this run saw essentially nothing — T shifted +0.15 % (Welch p = 0.2), ringdown mode p = 0.17. So BOT is not redundant; it uniquely observed a real bottom-vertex load-path change. But three facts cap its value:
Recommendation: run BO campaigns and long failure tests at 10 in without the BOT station, exactly as configured this run. If bottom-vertex observability is wanted, re-introduce it either as an occasional short health check at 5 in (where it stays in range) or permanently once re-ranged to a multi-kG tri-axis — not as a standing overload liability in every unattended batch. One caveat worth flagging: T stepped 1.086 → 1.127 between the two runs while the TOP station stayed statistically identical (223.4 vs 223.1 G, p = 0.58) — the step is entirely CH5-side, the familiar tape-coupling session dependence. Within-run T is superb; between-session comparability still argues for the rigid keyed CH5 seat. Committed (
|
|
Hmm.. might be the same issue as before. Jinkwan, here's an example of how you can upload directly to the branch instead of attaching files to comments: Screen.Recording.2026-07-17.163724.mp4@copilot have a look at https://github.com/vertical-cloud-lab/tensegrity-optimization/actions/runs/29615568750/job/88000448307 and see if you can find somewhere (probably an official github repo or maybe github community or somewhere else online) that talks about this particular error on pull requests with lots of inline attached files. |
|
@copilot address #82 (comment) |
Your instinct is right — this is the huge attachment-heavy comment thread, not anything wrong with PR #82's files. Here's what's happening and where it's documented. Root causeThe crash is in the action itself, at if (prResult.repository.pullRequest) {
const pullRequest = prResult.repository.pullRequest;
contextData = pullRequest;
changedFiles = pullRequest.files.nodes || []; // 293: pullRequest.files is null hereIt null-guards Why Where this is discussed online
What actually unblocks
|
Done — analyzed the felt-sheet sweep from #82 (comment). All 45 CSVs are committed under Did saturation occur? Yes — on the base-plate single-axis CH5 (FS 9,442.9 G), which is the rig's bottleneck.
20 in/1 felt clips CH5 on 4/5 drops (visible analog flat-topping) and 30 in/2 felt sits at 99 % FS — both unusable. The top tri-axis CH4 never exceeds 56 % FS, so the ceiling is entirely the low-range single-axis CH5. This is exactly @sgbaird's search-space concern: a print that's already at ~100 % FS leaves zero head-room for a stiffer BO design.
OLS (n = 45, R² = 0.87) cleanly de-confounds the two knobs (they were stepped together): each +10 in ⇒ ×1.85 on the CH5 peak, each +1 felt sheet ⇒ ×0.36 (≈64 % attenuation) — so one felt sheet cancels ~24 in of height (both p < 1e-8).
Recommendation — the ideal height/felt combo: Caveat: n = 1 specimen (5 repeats/condition); the 3× factor is an engineering choice — tighten it once the stiffest #35 search-space design's expected peak is known, since that (not this print) sets the true required margin. The real long-term fix for head-room is a higher-range base sensor, not more felt. |
|
@copilot is this going to give us something reasonable in terms of specific energy absorption and any other objective(s) of interest, assuming that we'll also have high speed video (for SEA specifically) |
Short answer: yes for SEA — but only via the high-speed video, not the accelerometers alone — and only once the force channel has saturation head-room and the capture window is extended. Here's the objective-by-objective read on what this rig currently supports. SEA (specific energy absorption)There are two routes, and they need different things:
Three prerequisites the committed data already flags before that hysteresis integral is trustworthy:
Other objectives
Bottom line: with high-speed video, SEA and F_peak are both viable BO objectives from this rig; the gating items are (a) force-channel head-room over the full search space, (b) a longer capture window, and (c) video↔DAQ sync tracking specimen compression. None require restarting — they're rig/DAQ settings. |
|
@sgbaird I'd like to ping Claude about the following, however it doesn't seem to be responding on here. Could you ping copilot about this, or perhaps show me how to create a new PR to work with the drop data on? "Recommend a minimum number of drop tests per specimen to get accurate data. How much variance have we had in our data per specimen being tested so far? Also provide how long each set of tests would take given that it currently takes ~42 seconds/drop at 60 inches with automatic dropping." |
|
@copilot address #82 (comment) Also, @copilot I forget if you're able to create new PRs, but if so, please do so. @me-madsen probably we can resume work on the new PR that gets created, then we'll want to upload directly to the branch instead of as comment files, at least when there are a large number of files involved. |
Issue is operational (coordinating the first crush/drop tests on Jeff Hill's tower) and this repo is the LaTeX MRG proposal with no code or existing test-protocol surface. This PR consolidates the moving parts from the issue thread, adds a literature synthesis, and analyzes the recorded accelerometer data.
Added
docs/drop-test-protocol.md— single source of truth for the drop-test setup, covering:g_max, SEA, full ~10 s ringdown (not just the 200 ms shock), reusability, slow-mo framing from t=0edison-trajectories/drop-test/— Edison Scientific LITERATURE_HIGH synthesis (task653d7d39) on drop-tower troubleshooting for small 3D-printed lattice/tensegrity specimens: ~57 KB report, full JSON dump, submission record, and README. Idempotent driver atscripts/edison/submit_drop_test.py. Surfaces a standards stack (ASTM D5276/D7136/D3332, ISO 6603/1683/5347, MIL-STD-810 method 516, SAE J211) and recommendations (linear sleeve bearings, magnetic/elastic top-plate hold-down, ≥10 s ring-buffer DAQ, SAE J211 CFC filtering, n ≥ 5 + CV, ≥5000 fps DIC; closest analogues Pajunen 2019, Dwyer 2023).First drop-test data analysis of the five TP4 accelerometer exports posted by @me-madsen (
Signal 10–14, 4-channel, 125 kHz, 0.2 s window):data/drop-tests/raw/— committed raw export filesscripts/analysis/drop_test_analysis.py— loader, SAE J211 CFC-1000 / CFC-180 filtering, peak/pulse/PSD metrics, and figure generationdata/drop-tests/figures/— full-window CH1 overlay, per-run impact zoom (raw vs filtered), peak-g bar chart, PSD, and CH4 trigger-artifact plotdocs/drop-test-analysis.md+data/drop-tests/README.md— findings: the "audrey" tensegrity specimen reduces CFC-180 peak acceleration ~74–79 % vs the no-specimen control (~370–463 G vs ~1,792 G), while the PETG run's raw peak is within ~1 % of the control (≈ direct plate-on-plate hit), strong evidence of the bungee-driven lift-off; CH4 carries a fixed ~1.4 kG trigger/release artifact at t≈4.2 ms in every run. Caveats noted: unconfirmed channel map, 200 ms window only, n = 1 for control/PETG, no Δv/SEA quoted yet.Vertex vs. acrylic-plate T3-prism drop-test data and analysis posted by @ctrhjk (PR Add drop-test protocol, Edison synthesis, and first-data analysis #67), under
data/drop-tests/vertex-acrylic/:raw/— eight TP4 exports{n0jdwk, m6cyoq, T3_0103, T3_0000}_Signal{1,2}.csv(Signal1= vertex-mounted,Signal2= acrylic-plate), single drop per configuration at 13 ft, 200 ms / 125 kHzREADME.md— channel map (CH1 removed; CH2–CH4 tri-axis; CH5 single-axis; CH4 = 1000 G trigger) with full-scale/sensitivity per channel, per-specimen file index, and @ctrhjk's observations (clip-height/no-trigger issue, hot-glue z-axis mount limitation,m6cyoqstrut andT3_0103TPU-tendon damage after the acrylic test, and the invalidT3_0000acrylic run where the accelerometer fell off)scripts/analysis/drop_test_vertex_acrylic_analysis.py— locates the impact via the triggered CH4 channel (windowed ±1.5 ms peak search in the first 10 ms, not a global max), baseline-corrects, and reports raw / SAE J211 CFC-1000 / CFC-180 peaks for the single-axis CH5 (primary go-forward sensor) and tri-axis CH4, auto-flagging invalid / no-clean-impact runsdata/drop-tests/vertex-acrylic/figures/— vertex-vs-acrylic CH5 impact windows, CFC-180 peak-g bar chart, and vertex CH5 PSDdocs/drop-test-vertex-acrylic-analysis.md— findings + an explicit SOP / test-method section: vertex mounting is repeatable (4/4 clean, CFC-180 229–284 G, CV ≈ 9 %) while the acrylic configuration is not (3/4 runs registered no clean impact — clips too low so the plate seats on the specimen, plus the fell-offT3_0000); the vertex peaks do not yet discriminate geometry so fresh intact distinct-geometry samples (vertex-only, n ≥ 5) are needed before peak-g is a trustworthy BO objective; replace the hot-glue mount with a z-axis-aligned seat; and the single-axis sensor's raw peaks reach 70–90 % of its 9,442.9 G full scale (near saturation on the m6cyoq-acrylic run). Caveats: n = 1 per (specimen, mount), 200 ms window only, partial-pulse Δv, unconfirmed CH4/CH5 axis correspondence.Clip-height sweep & base-plate accelerometer-check diagnostic posted by @ctrhjk, under
data/drop-tests/clip-height/— drilling into why the acrylic-plate configuration repeatedly fails to trigger:raw/Accelerometer_check_Signal1.csv+README.md— the one triggered base-plate CSV (tri-axis on the bottom plate, 13 in drop) plus a setup README documenting both experiments: the clip-height sweep (extra bungees cured fly-off; tri-axis on the acrylic plate; clips at 0.5/1/1.5/2 in, two drops each; 0/8 drops triggered, video only) and the base-plate accelerometer check, with the shared channel mapscripts/analysis/drop_test_clip_height_analysis.py+data/drop-tests/clip-height/figures/— windowed CH4 impact location, SAE J211 CFC-1000 / CFC-180 peak/pulse/Δv metrics, and figures (base-plate impact window, full-window CH4, PSD)docs/drop-test-clip-height-analysis.md— findings: the base-plate hit triggers cleanly (CH4 raw 3072 G ≈ 3.1× the 1000 G trigger, CFC-180 280 G, Δv ≈ 3.3 m/s; CH4 dominates the off-axis channels ~23–55×), so the acrylic-plate "no trigger" failure (0/8 across the clip sweep) is a load-path problem — the plate seats on / is damped by the bungee-restrained specimen — not the sensor, DAQ, or trigger level.Input-output (transmissibility) drop-test data and analysis posted by @ctrhjk (PR Add drop-test protocol, Edison synthesis, and first-data analysis #67), under
data/drop-tests/input-output/— @ctrhjk's input-output instrumentation design: a single-axis accelerometer on the bottom plate = input (now the triggered channel CH5), a tri-axis accelerometer hot-glued to the top vertex = output (CH2–CH4), bungees removed, four distinct-geometry specimens (practice,n0jdwk,yqpmx1,h8Lbev) each dropped five times at 13 in:raw/— 20 TP4 exports{practice,n0jdwk,yqpmx1,h8Lbev}_Signal{1..5}.csv(Signalindex = drop number) +README.mdwith the channel map (trigger moved to the single-axis input CH5) and @ctrhjk's setup notesscripts/analysis/drop_test_input_output_analysis.py— locates the impact on the triggered CH5 (windowed ±1.5 ms peak), baseline-corrects, and reports raw / SAE J211 CFC-1000 / CFC-180 peaks for the input (CH5) and the tri-axis output resultant, the transmissibilityT = output/input, pulse width and Δv, with per-specimen mean ± 1σ / CV aggregatesdata/drop-tests/input-output/figures/— input-vs-output impact windows (5 drops overlaid), transmissibility bar chart, input repeatability, output PSDdocs/drop-test-input-output-analysis.md— findings: the input-output design works — 20/20 drops triggered cleanly, removing the bungees makes the input nearly constant (235–248 G CFC-180, ≤1.7 % CV), and transmissibility now discriminates geometry (yqpmx1≈ 0.96 is the only attenuator,h8Lbev≈ 1.09,practice/n0jdwk≈ 1.17–1.19), makingT(or output-peak-at-fixed-input) a usable BO objective; a mild within-run drift across the five cyclic drops is flagged as most likely hot-glue-mount-driven. Caveats: n = 1 specimen per geometry (5 repeat drops), 200 ms window, unverified tri-axis orientation, IDs not yet tied back to design parametersedison-trajectories/input-output/— Edison Scientific ANALYSIS (taskfe044079) that independently reproduced the transmissibility values exactly to two decimals, confirmed the within-run drift is statistically real and mount-driven (pooled +0.015/drop, p = 0.0001), endorsedTas a first-pass screening objective (recommending FRF / SRS-band metrics and output-peak-at-fixed-input as it matures), and gave a prioritized SOP (rigid z-aligned keyed sensor seat, keep bungees removed, extend capture past 200 ms, n ≥ 5 distinct prints per geometry with randomized order, anchor in SAE J211 / ISO 5347 / ASTM D3332). Idempotent driverscripts/edison/submit_input_output.py+ fetchscripts/edison/fetch_input_output.py; a cross-check section is folded into the analysis doc.2nd 30-drop check run (
check2) data + same-problem diagnosis, picking up the analysis that the earlier (claude) runs stalled on, underdata/drop-tests/200drops-check2/— 30 further auto-drops (check2_Signal233–262, specimen7xadt6, 10 in, CH5 trigger) posted by @ctrhjk to check whether the three 200-drop-campaign problems still exist:raw/— the 30 committedcheck2_Signal{233..262}.csvTP4 exports +README.md(channel map, setup, continuity with200drops-check)scripts/analysis/drop_test_200drops_check2_analysis.py— re-runs the identical three-problem + ~122 Hz diagnostics (windowed impact peak, SAE J211 CFC filtering, saturation audit, OLS trends) and compares against the first check rundata/drop-tests/200drops-check2/figures/— three-problem panel, T = TOP/CH5 and ~122 Hz band-power plots, plus machine-readable metrics JSONdocs/drop-test-200drops-check2-analysis.md— diagnosis: BOT electrical dropout stays fixed (alive 30/30, quieter noise floor); CH7/CH8 over full scale at 10 in persists (medians ≈100 % FS, still clipping); CH5 tape coupling persists (T durably ~1.083 vs healthy 1.025); the ~122 Hz ringdown mode has not returned (all ~549 Hz)Raw-data completeness audit across the whole PR thread — cross-checked every attachment in all PR Add drop-test protocol, Edison synthesis, and first-data analysis #67 comments against committed data and confirmed all raw CSVs are now committed and organized, one dataset per
data/drop-tests/<name>/raw/folder (vertex-acrylic, clip-height, input-output, key-mounted, key-mounted-wax, burn-in-wax, drift-calibration, drift-calibration2, 30drops-real, 100drops, ch4-trigger, 5in-100drops, 200drops, 200drops-check, and the newly-added 200drops-check2).check2was the only genuinely missing set; a few others were already committed under case-normalized names (same files).