22 Commits

Author SHA1 Message Date
61c10df63d
controller: restructure control loop
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.
2024-07-18 21:47:50 -07:00
eb7ad4ef9e
main: hook up calibration stubs
I guess I will be finishing this later.
2024-07-15 17:55:31 -07:00
2194dd4a8c
config: make it possible not to leak
Using the GPA is a bit annoying sometimes. The other option would be to
just use page allocator to allocate the config and bypass the GPA.
2024-07-15 17:55:31 -07:00
de76cce706
controller: make controller info printout more useful
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.
2024-07-15 17:55:31 -07:00
e5d8a716b0
improve a name 2024-07-11 21:55:34 -07:00
f1480bca45
build: link windows-native driver when targeting windows
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.
2024-07-10 18:22:47 -07:00
e4393c2e5a
config: change default control loop interval
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.
2024-07-10 12:43:11 -07:00
ccb507d4d9
cli: provide more useful help text 2024-07-10 12:39:18 -07:00
d5f0727517
labjack: actually initialize digital outputs
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.
2024-07-08 18:22:20 -07:00
dbb076f69b
Config: perform basic validation
This just makes sure the parking posture is within the valid range of
motion of the rotator.
2024-07-07 15:38:26 -07:00
8fb6032a04
main: add very basic command line interface
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.
2024-07-07 15:37:53 -07:00
c8511d8c92
build: embed udev rules in the binary
It is nice if the program can emit its own udev file.
2024-07-07 15:34:03 -07:00
2937de6fcd
controller: apply range checking after applying elevation mask
This should work better by not causing command errors when trying to
move to postures that would be masked out anyway.
2024-07-06 13:31:59 -07:00
b0aac111a2
controller: implement elevation mask
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.
2024-07-06 13:04:55 -07:00
7fbfe1c5f7
rotctl: do range validation
This is at the interface layer though it should arguably be done at the
controller layer. Oh well.
2024-07-06 12:59:48 -07:00
7105775426
labjack: use symbolic gain values
This reads better in the config file.
2024-07-06 12:58:27 -07:00
0e88022a8d
config: change default listen port
This now matches the rotctld default listen port
2024-07-06 12:56:10 -07:00
bd465af30d
rotctl: hook up remaining interface
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.
2024-07-05 00:32:42 -07:00
dbbb5c1748
rotctl: hook up P interface
This appears to work. Now all that remains is doing the rest of the
work.
2024-07-03 17:44:26 -07:00
c8bec6a7c5
start writing control and config functionality
In theory, this will poll the feedback lines, but in practice, it
probably crashes or catches on fire or something.
2024-07-03 16:06:49 -07:00
7275d1c30e
prototype labjack API wrapper
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.
2024-06-29 17:44:52 -07:00
eace0bf8db
init
the readme is a ramble and there's no functionality (yet). couldn't ask
for a better start.
2024-06-28 22:05:14 -07:00