Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

ETS/ETS2: one joint-index resolver; the all-or-none, unique guarantee breaks under concatenation and insert

Abierto
  • ¿Algo no está bien?
#803 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
10/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
robotics

Línea de trabajo

Start with the duplicated joint-index logic in ETS.__init__, ETS2.__init__ and ETS2.jacob, then BaseRobot.__init__ and Gripper.__init__. Reproduce the concatenation case from the issue (ETS([ET.Rz()]) * ETS([ET.Rx()]) giving duplicate jindex values) and check the insert path. Done means one shared resolver that enforces all-or-none, unique and contiguous indices, with the proposed regression tests passing. The design choices (lazy versus eager resolution, read-only ET.jindex) need maintainer agreement first.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

tech-debt

Summary

The rule "an ETS has either all or none of its joint indices set, and they are unique and contiguous" is implemented four times and enforced in only one place, the constructor. Incremental construction and later mutation can break it.

Found while reviewing #792, which fixed one symptom (np.all([...jindex]) treats index 0 as missing, so a permuted or sparse mapping was silently overwritten with 0..n-1).

Where the logic lives today

Place What it does
ETS.__init__ counts joints with a jindex; all-but-last sequential auto-fills the last, mixture raises ValueError, none assigns 0..n-1
ETS2.__init__ the same ~25 lines, copy-pasted
ETS2.jacob re-checks "all set?" and renumbers (the check #792 fixes)
BaseRobot.__init__ re-derives none/all across the links, via _auto_jindex, then assigns in DFS order
Gripper.__init__ the same again with a slightly different filter

The guarantee does not hold under incremental construction

On main:

a, b = ET.Rz(), ET.Rx()
e = ETS([a]) * ETS([b])       # each piece was auto-assigned jindex 0
[j.jindex for j in e.joints()]   # -> [0, 0], n = 2: all set, but not unique
  • Concatenating two auto-indexed ETS gives duplicate indices with no error, because the constructor only checks "all or none", not unique and contiguous.
  • ETS.insert appends to _data with no re-check at all and does not reset _auto_jindex.
  • ET.jindex has a public setter, so indices can be changed after construction, outside the owning ETS (Link.jindex, BaseRobot, Gripper, DHRobot and ETS2.jacob all do).

Proposal

  1. One helper (a function, or a method on the common base BaseETS) that takes the joints and does the whole job: all-or-none check, uniqueness and contiguity, auto-fill, and returns whether the indices were auto-assigned. ETS and ETS2 constructors call it.
  2. Re-run it from every mutator (insert, append, __setitem__, __imul__) or resolve it lazily on first use, since jindices is already a cached property.
  3. Make ET.jindex read-only once the ET belongs to an ETS (the ET is already deep-copied into the ETS, so ownership is clear). Mutation then goes through one sanctioned ETS method that keeps the _auto_jindex flag and the cached jindices consistent. Link.jindex, BaseRobot, Gripper and DHRobot use that method.
  4. BaseRobot and Gripper share a small classifier (none / all / mixed) instead of each re-writing all([... is None ...]), and their DFS assignment becomes one base-class method.
  5. The unreachable renumbering block in ETS2.jacob is deleted.

Regression tests: concatenation of two auto-indexed ETS, insert of a joint, permuted explicit indices surviving jacob, and a mixture still raising.

Fits the ets group of the typing pass (problems 61 to 65).

Related

  • #792 (the symptom fix, independent of this)
Lenguaje dominante
C++
Estrellas
3.6k
Forks
645
Merge medio
1 d 5 h
PR fusionados (30 d)
137

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de petercorke/robotics-toolbox-python

Todos los issues de petercorke/robotics-toolbox-python

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.