Committing configuration with new LaserCAN name seems to clear configuration

[KangarooKoala]

From testing today, we determined the following:

• After setting both the ID and the name of a LaserCAN, trying to commit the configuration causes a GrappleHook disconnect 5-15 or so seconds later. After reconnecting GrappleHook, the LaserCAN still shows the updated ID and name, but after a robot power cycle, the LaserCAN reverts to the default configuration (ID #0, name "LaserCAN").
  • This was first observed with multiple Kraken X60s, other CTRE devices, and other LaserCANs on the same CAN bus loop, but after removing most of the Krakens and all of the other LaserCANs from the bus loop, we still observed the same issue.
• When setting only the ID, committing the configuration succeeds. (No disconnect, and after a robot power cycle, the new ID persists)
  • This succeeded with both the reduced and full CAN bus loops.
• When setting only the name and trying to commit the configuration, the GrappleHook disconnect happens and the LaserCAN reverts to the default configuration. Notably, the ID is also reset to 0, even if a different ID was successfully committed before.
  • This was observed with both the reduced and full CAN bus loops.

GrappleHook and the LaserCANs should all be the current latest versions (GrappleHook v25.0.5 and LaserCAN v2025.1.0), but I can double-check tomorrow. (Though this is also in the middle of an event, so I might forget)

[KangarooKoala]

We were able to configure the names of the exact same sensor before on a testbench where LaserCANs were the only items on the loop, which suggests that the problem is related to having the other devices on the CAN bus loop.

[JaciBrunning]

Thanks for lodging the issue. We got another report of this issue a few days ago - I'm currently in the process of testing a potential fix that makes the configuration saving mechanism more robust.

The GrappleHook disconnect, however, sounds new - or perhaps that detail was left out of the previous report. That would seem to imply that the LaserCAN is crashing and so all Grapple devices drop off the bus, killing GrappleHook. Let me look more into it, I suspect it's something to do with the heap allocator on the LaserCAN (maybe the messages are getting muddled between different devices?)