Since gpredict doesn't have a park button or anything, this will just
automatically park the antenna when the gpredict rotator controller
disconnects. This may or may not actually be a good idea. We will see.
This should have been multiple commits, but it isn't. Sue me. This
change has two main goals:
1. Sample feedback at the beginning of the control loop iteration so
that it is always up-to-date when we are computing the actual drive
outputs. This means we're doing twice the amount of communication
with the labjack (previously, setting the output and reading the
feedback was done with a singe command). However, this makes the
loop structure much more standard, and it means that we aren't
constantly operating on feedback that is stale by one loop
interval.
2. Sample feedback into a (configurable size) buffer. This lets us
operate on aggregated feedback rather than on a single instantaneous
data point. Right now, feedback is computed as a moving average,
which acts as a rudimentary low-pass filter, reducing spurious
single-loop actions due to feedback spikes or other noise. However,
the other reason to aggregate some backwards data is that it will
let us do automatic stall detection in a simple way, although that
is not currently done.
This has a lot more relevant information now. Anyway, this has been
tested on real hardware, and it appears to work pretty well. I am
considering changing the control loop so that it isn't always
operating on stale feedback (two LabJack calls per loop when actively
controlling pointing). Also the calibration routines need to be
implemented.
The lib files are of course stubs and not actually static libraries,
which means we have to distribute the DLL as well. Unfortunately.
Incredibly bad operating system. If this doesn't work, I quit.
This is completely experimental, but since the API is the same, it's a
drop-in replacement. The Windows driver is not apparently open source,
so I am vendoring the static libraries provided. In theory, this will
obviate the need to replace the HID driver on Windows and will thus
require no initial setup, but I cannot currently test it beyond making
sure it compiles.
On an unloaded rotator, this fixes the rapid relay toggling without
needing to implement debouncing.
An additional configuration validation should probably be added: the
rotator rotates in azimuth about 6 deg per second. If the control loop
speed is too slow or the controller angle tolerance is small enough,
then the controller will never be able settle (imagine that the loop
interval is 1 second. That means the rotator will move approximately 6
degrees every loop iteration, so it will always overshoot.
I had some testing code that did this and then I got rid of it because
I thought I didn't need it, but it turns out it is actually necessary
because AISample does not do any digital direction setup.
Anyway, this has been tested on (basic) hardware now, and it appears to
even work. It needs two main things to be truly prime-time capable: a
calibration process and output debouncing. When it is approaching the
target, the relays will get toggled very rapidly a few times, which is
not particularly good for them. Operating on a moving average of the
feedback may be a simple way to address this (effectively acts as a
low-pass filter). Slowing down the control loop may also work well and
would be much simpler.
There are three commands: one to write the default config, one to write
the embedded udev rules file, and one to actually run the program.
I might reformat the help text at some point. It's not very nice as-is.
There's not really any analogous concept for azimuth. This is for a
specific piece of hardware, so there's no real point in making it more
generic. This is respected at the 180 degree point as well, for
software that can handle flipped rotation configurations.
This doesn't currently play well with the elevation offset setting,
which should be applied after this clamping operation. Either this
needs to be moved to the API layer or (more appropriately) the input
range validation needs to move in the controller.
This is missing a little bit of input validation, e.g. we don't
currently check that set_position azimuth and elevation are actually
in the range that the controller can possibly move.
The geodetic north offset configuration value is applied in when
computing the current position, but I think there are still some
slightly fiddly edge cases around it and I haven't actually figured
out which direction I want the sign to be.
The various pieces appear to be functional, so next up will be figuring
out what all the problems are with some hardware in the loop.
I will probably spend more time on this than I plan to, though I am not
really writing this to run on Windows. At this point, Windows
compilation works but when the driver attempts to read the HID
descriptor, the response is only 45 bytes instead of the expected 75
(which is what it gets when run on Linux). I was under the impression
that this response was just raw data from the device itself, but it's
clearly handled differently on the different platforms, so I think it
will be somewhat interesting to dig into what is different between the
two and why. It's possible I may actually learn something along the
way, unfortunately.
The only pthread functionality this seems to use is mutexes, which are
(fortunately) theoretically trivial to wrap for windows. This
compiles, though it is not clear if it actually works correctly.
The Labjack API provided by ljacklm is, quite frankly, dog doodoo. I
say this as disrespectfully as possible. A lot of the API calls take
specific (implictly sized) arrays that must be 0-filled just so the
API can loop over them and fill them with a different number.
Everything parameter is either long or a float (and I think the use of
long is a carryover from the insane Win32 ABI where long is a 32 bit
integer rather than 64 bit, which it is on most Posix platforms). The
functions have a tendency to do 15 different things in a single call,
and most of the function parameters are out parameters or even better,
inout parameters. Some functions take arrays where other ones require
the user to manually bitpack an integer.
I've got the source for it right here and could rewrite it, but I don't
hate myself enough to do that. The API surface I need is minimal, so
I've just wrapped the parts I will be using. Ideally I will not need
to touch this again, but it does still need to be tested with actual
hardware, so we're not out of the woods yet.
