Sled will not go to top of board same parts are cut different sizes

Troubleshooting
28

Basically, everytime I got that error, I had exceeded the conditions I explained as the “what , why and how” above. After analysing the Firmware architecture, I created a summary of the calculation loop.

Step 0 is the one that estimates x,y position from chain length and yields the error when unable to resolve (x,y) from the maslow parameters and chains length.

More generally, I see three possible causes:

  • parameters are set in the firmware as requested by the user by Groundcontrol, but are wrong.
  • parameters are not set properly in the firmware due to a bug along the path
  • the Forward Kinematics calculation fails in some cases.

To debug this, it is very valuable to

  • know the exact firmware and GroundControl version in use when the bug is observed,
  • observe what was actually set into the firmware
  • observe what was actually set in GroundControl.

To collect the GroundControl settings data, one gets and reads the groundcontrol.ini file.

To collect the Firmware settings data, one sends the $$ command (with the correspondingly configured macro button) to the firmware and look the response printed in the GroundControl shell output. I can easily see the shell output because I launch GroundControl in a shell with the command “python ./main.py”. I don’t know how to get the same with the windows version.

Encoder counts are not output by the $$ command. But the encoder counts are not normally affected by a parameter change like the motor distance.

After a parameter change (and assuming the chosen parameter value is right ), if the sled position cannot be solved or center position is visibly not where it should, then here is what I would do:

  • don’t do any calibration task yet. Keep calibration as is.
  • close GC, turn off the arduino (disconnect usb and turn off motor shield power source.
  • restart the arduino and reconnect with GroundControl to reload and recompute forward kinematics.

Do you still get the “unable to resolve” error?

  • If no, that could point to a bug in the firmware not using the new value properly upon change, but doing fine upon reset.
  • If yes, check again $$ output and GroundControl settings for unexpected values among the parameters. There might be some wrongly set value, pointing to a bug in the communication path used by GC and the firmware to set a parameter.
1 Like