Output of S command incorrect

Issue #22 new
Daniel Williams
created an issue

The output of the S command is incorrect.

Regardless of the position, the software returns a string which claims the Tal to be 0 and the Taz to be (pi)

Comments (6)

  1. Daniel Williams reporter

    The correct behaviour is exhibited when the telescope is executing a "gh" command, but not when it is being driven in an arbitrary direction, e.g. a "gU" command. In this case the status string provides a position which is unchanged from the last position after a gh command was successfully completed. As a result driving from the home position provides the behaviour described in the initial issue.

  2. Norman Gray repo owner

    This may not really be a bug, since the gU, gD, gE and gW commands are documented to be low-level commands which simply drive the telescope motors in one direction or another, at full speed, without updating the internal position, and notes that they may be removed in future.

    The point of these functions is to provide a way of driving the telescope ‘by eye’, without the interposition of any software control.

    While it would surely be possible to change the effects of these to update the position, I'm somewhat reluctant to do that, partly because the above ‘no software control’ property seems valuable, and partly because having two distinct ways of doing something invites inconsistency and error.

    Would you disagree?

    I'll look at how easy it is to set the reported position to a ‘don’t know’ value.

  3. Daniel Williams reporter

    The only reason this is currently a problem is that being able to nudge the telescope with those commands allows the telescope to be moved slightly off the position it believes itself to be in. We're trying to track down what the calibration offsets are (which look to be on the order of several degrees), and this seems like the most straight-forward way to determine them. However, it would require us to be able to measure the position the telescope believes itself to be at following the nudge in order to calculate the difference.

  4. Norman Gray repo owner

    Refactoring: angle/click handling moved; State simplified?; position tracked during g{U,D,E,W}.

    I'm not completely convinced this is a simplication. The part-motivation was to see if it was reasonable to track position during g{U,D,E,W} (even though that's not a recommended way of moving the telescope, and may yet be removed; see issue #22). In thinking about that, it seemed reasonable to have the relevant updates to State (which manages the estimates of angular position) triggered in qp.ino rather than within Schedule::poke. The problem is that, although there is some simplification -- so I'm not immediatley about to abandon this change -- this State object is now being prodded and poked in multiple places, which may not be an improvement. I suspect more refactoring would be useful.

    A downside of this change is that the simplicity of the 'gU' command, and friends, has to some extent disappeared. I may yet revert to those being commands which discard the current notion of position (requiring a gH afterwards), especially if that allows further simplifications elsewhere.

    → <<cset 26fca3864510>>

  5. Norman Gray repo owner

    OK, then such nudging should work now (but no promises for the future!).

    The default calibration offsets are in config-qp.h – it would be good to work out a protocol for determining those offsets, and putting them in. The c command should allow you to specify them live, though.

  6. Norman Gray repo owner

    Added nu/nd/ne/nw commands to nudge the telescope.

    These were added in order to make it possible to adjust the telescope position without needing the gU/gD/gE/gW commands, and are done in such a way as to make it impossible for the telescope to be driven over the zenith (because that causes an error when the telescope tries to construct the Quaternion corresponding to its current position). It's still possible to create an error by driving the telescope over the zenith, but that is a separate problem.

    Addresses issue #22, but doesn't close it.

    → <<cset f6498cc55475>>

  7. Log in to comment