You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-on coverage for the FANUC CRX collaborative-robot line. CRX-10iA/L landed in #300 / v1.2.1 and confirmed the solver class (non-Pieper 6R via ikgeo.general_6r, 991 µs median, AE-3 leftvar=1, max cond(m_quad) 1.3e+03). The remaining six SKUs in the family share — by inspection of the official FANUC xacro macros — the same kinematic skeleton with scaled link parameters.
SKUs to add
Each row is one PR per the established arm-add cadence (#284 Z1, #285 PiPER, #289 Rizon 10, #300 CRX-10iA/L). One manifest entry plus a vendored URDF.
CRX-3iA — 3 kg payload, ~540 mm reach
CRX-5iA — 5 kg payload, ~994 mm reach
CRX-10iA — 10 kg payload, ~1249 mm reach (the non-/L base model)
CRX-10iA/LP — 10 kg payload, ~1418 mm reach (long + paint-class variant)
CRX-20iA/L — 20 kg payload, ~1418 mm reach
CRX-30iA — 30 kg payload, ~1888 mm reach (flagship)
Each needs xacro rendering before vendoring into tests/fixtures/. Standard xacro invocation against a top-level wrapper that instantiates the macro at prefix=\"\" is enough; no real reason to import the entire fanuc_crx_description ROS package.
Shared-skeleton hypothesis
All six are expected to route to ikgeo.general_6r with the same dispatch reasoning as CRX-10iA/L. To verify for each SKU before merging:
Dispatcher reasoning string matches "Closes the EAIK coverage gap" (tier-2 RR, not tier-0 Pieper).
AE-3 _cached_best_leftvar lands on _LINEARITY_JOINT = 1 (same as CRX-10iA/L). If a SKU picks a different leftvar, that's a signal the kinematic skeleton diverges meaningfully — investigate before adding.
cond(m_quad) on a representative non-singular pose stays under the 1e+04 gate (CRX-10iA/L max was 1.3e+03).
If all three hold across the six SKUs, the codegen path is fully reused. If not, file a sub-issue and treat that SKU as its own investigation.
Each SKU should produce a fresh "refuses (6R-Unknown Kinematic Class)" row from EAIK and a sub-ms ssik measurement — same shape as the CRX-10iA/L row already in the README EAIK table.
Out of scope
Older FANUC cobots (CR-7iA, CR-35iA) — different product line that predates CRX. ros-industrial does carry them (fanuc_cr7ia_support, fanuc_cr35ia_support). Probably Pieper-class spherical-wrist; would route to tier-0, not the same wedge story. Worth a separate issue if and when they become relevant for coverage.
A combined PR. Per the established cadence, one PR per SKU. Bundling muddies the artifact-snapshot review and makes any per-SKU conditioning surprise harder to bisect.
Follow-on coverage for the FANUC CRX collaborative-robot line. CRX-10iA/L landed in #300 / v1.2.1 and confirmed the solver class (non-Pieper 6R via
ikgeo.general_6r, 991 µs median, AE-3 leftvar=1, max cond(m_quad) 1.3e+03). The remaining six SKUs in the family share — by inspection of the official FANUC xacro macros — the same kinematic skeleton with scaled link parameters.SKUs to add
Each row is one PR per the established arm-add cadence (#284 Z1, #285 PiPER, #289 Rizon 10, #300 CRX-10iA/L). One manifest entry plus a vendored URDF.
URDF sources
The ros-industrial mirror only ships CRX-10iA (used in #300). For the other six, the canonical source is
FANUC-CORPORATION/fanuc_description/fanuc_crx_description/urdf/, published as xacro macros with link-length parameters. Per-SKU files:crx3ia_urdf_macro.xacrocrx5ia_urdf_macro.xacrocrx10ia_urdf_macro.xacrocrx10ia_lp_urdf_macro.xacrocrx20ia_l_urdf_macro.xacrocrx30ia_urdf_macro.xacroEach needs xacro rendering before vendoring into
tests/fixtures/. Standardxacroinvocation against a top-level wrapper that instantiates the macro atprefix=\"\"is enough; no real reason to import the entirefanuc_crx_descriptionROS package.Shared-skeleton hypothesis
All six are expected to route to
ikgeo.general_6rwith the same dispatch reasoning as CRX-10iA/L. To verify for each SKU before merging:_cached_best_leftvarlands on_LINEARITY_JOINT = 1(same as CRX-10iA/L). If a SKU picks a different leftvar, that's a signal the kinematic skeleton diverges meaningfully — investigate before adding.If all three hold across the six SKUs, the codegen path is fully reused. If not, file a sub-issue and treat that SKU as its own investigation.
Per-SKU PR template
Modeled on #300:
tests/fixtures/fanuc_crx<sku>.urdf.uv run ssik add-arm tests/fixtures/fanuc_crx<sku>.urdf --base base_link --ee tool0 --name fanuc_crx<sku>.[arms.fanuc_crx<sku>_ik]MANIFEST entry — copy CRX-10iA/L's block, swap fixture path + display_name +kinematic_classreach annotation +sample_qto an in-limits non-singular pose.uv run python scripts/regen_artifacts.py→ confirm tier-2 + leftvar=1 + cond gate.fk_ceiling_fuzz=1e-4.examples/04_compare_vs_eaik.py→ populate[arms.fanuc_crx<sku>_ik.bench].scripts/regen_docs.py→ AUTOGEN tables (README, prebuilt, quickstart).Bench-table comparison
Each SKU should produce a fresh "refuses (6R-Unknown Kinematic Class)" row from EAIK and a sub-ms ssik measurement — same shape as the CRX-10iA/L row already in the README EAIK table.
Out of scope
fanuc_cr7ia_support,fanuc_cr35ia_support). Probably Pieper-class spherical-wrist; would route to tier-0, not the same wedge story. Worth a separate issue if and when they become relevant for coverage._cached_best_leftvarheuristic if any sibling picks a different leftvar — that's RR algebraic-precision gap on mixed-alpha synthetic geometries (e.g. MC Table I) #82-class work, surface it via a sub-issue with the offending SKU and the cond(m_quad) measurements.Acceptance
ikgeo.general_6rtier-2 with_LINEARITY_JOINT = 1(or a documented investigation if any diverge)from ssik.prebuilt import fanuc_crx<sku>_ikworks for every variant