Acu add sin el nod by mjrand · Pull Request #1072 · simonsobs/socs

mjrand · 2026-06-09T21:28:41Z

Added the gen_sin_el_nod scan generator function into the ACU drivers.

Description

Added a new generator function for generating sinusoidal elevation nods into the ACU agent. This generator will allow us to generate sine wave el nods that do not move in azimuth. This is basically a replica of type3 scan behavior with no azimuth movement.

Motivation and Context

LAT ISO review requested sinusoidal elevation nods with no azimuth movement.

How Has This Been Tested?

I've simmed the gen_sin_el_nod driver function output with success. The generator function should work as intended.

I have not yet tested the changes to the agent generate_scan function or tested an movement on the LAT. This needs to be tested before PR approval.

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

My code follows the code style of this project.
My change requires a change to the documentation.
I have updated the documentation accordingly.

mhasself · 2026-06-10T09:48:53Z

Thanks Michael. I recommend that you move this to "draft" PR until we finalize design and test it on a real system.

Initial reactions:

Why should this be a new "scan type" for generate_scan rather than a new, stand-alone process / task? The arguments for this functionality are a tiny subset of the full az scan functionality. It's not like someone would decide, one day, to do an el-nod everywhere that they previously were doing a scan!
In modern application, num_batches and batch_size are deprecated. Let's not introduce new usages ... i.e., they can be removed from your driver function (and just hard-code the current default at the top of the function).
Is there a control on step_time relative to the el_freq? Make sure step_time gives you "enough" points. Fourier limit is 4 but I would think we'd want more like 16.
The generator sets group_flag=0, which means a "stop" can cause the track to terminate at ~any point. That might "work" but it would be best to tune group_flag such that stops will always occur at the bottom of the dip (which is also the starting point).
To support the preceding point, it might be helpful to tweak step_time such that it divides the oscillation period evenly. Then just generate 1 cycle at a time and yield it (another reason to drop the "batch_size" notion). Can discuss more elsewhere. But basically set new_step_time = (el_freq*round((el_freq*step_time)**-1))**-1.

mjrand · 2026-06-10T21:18:34Z

Aaaah I didn't even know there was a draft PR feature... that's super helpful! (I am not great at git... lol). Changed.

There's really no reason other than I wanted to reuse the generate_scan architecture and make it really easy to call from with sorunlib. It should be somewhat easy to make its own process/task. I'll write that in. I wasn't super attached to keeping it in generate_scan instead of making its own process.
Yeah the notes on batches makes sense to me. I can rewrite this to always yield out whole number nods. That should also prevent us from stopping the elevation on a non-zero velocity.... which opens up a question of if we need to also write a smooth-stop generator for elevation (I think we probably do), but that's outside the scope of this PR.
I think step_size = 0.1 is probably good enough for all nods that aren't hilariously high frequency. I think there is a check for this in plan_scan... but it should probably just be in this function calculated like you say.
Agreed we should probably yield whole number nods.
Agreed.

I think rewriting the driver to yield whole number of nods and then rewriting the agent process will be good. One of the worries I had with the current implementation into generate_scan was how plan_scan would interact with az_vel=0. I think it would work... but I think if we make a generate_el_nod function or whatever it could just start at the current az instead of having to run-up to az_vel=0. I'll try this implementation and see how it would work.

mjrand · 2026-06-10T23:54:23Z

Alright I reverted generate_scan and made generate_sin_el_nod. I started it as a copy of generate_scan and then tried to prune back as many things weren't used or weren't necessary. This meant pruning plan_scan and some other misc variables like wait_to_start (which I couldn't find used in generate_scan either...). I also fixed up the generate_sin_el_nod drivers function to only yield full el nods and to always divide them into 16 points (which can be changed...). This means step_time is determined in the driver and doesn't need to be callable in the agent.

mhasself

Thanks! More notes ...

mhasself · 2026-06-11T12:03:28Z

                               self._simple_process_stop,
                               blocking=False,
                               startup=False)
+        agent.register_process('generate_sin_el_nod',


Let's just call this "generate_elnod". If we invent alternatives, we'll likely jam them into this function.

Done. Now just called generate_el_nod in the agent. I kept the generate_sin_el_nod in the driver

mhasself · 2026-06-11T12:04:36Z

+    @ocs_agent.param('az', type=float)
+    @ocs_agent.param('el_endpoint1', type=float, default=None)
+    @ocs_agent.param('el_endpoint2', type=float, default=None)


Instead of having these as args, let's just make this function run them at the current position. This makes for less bookkeeping in sorunlib. And then you'd just have "el_depth", which could be negative, as the parameter that determines how far apart the endpoints are.

Done, changed to el_freq and el_depth as callable parameters

mhasself · 2026-06-11T12:12:36Z

+            'el1': el_endpoint1,
+            'el2': el_endpoint2,
+            'el_freq': el_freq,
+            'type': 'sin_el_nod',


The data here need to be exactly the same (same fields with same data types) as the ones in generate_scan. Otherwise the feed will complain (or, at best, data loading of this info will be totally messed up). I think you should indeed use 4 for the sin_el_nod -- and register it in the main list of scan types. Any irrelevant stuff should be set to 0 or nan or something like that.

Copied the format from generate_scan and filled it with the available data.

Do you mean register scan_type 4 in the agent? Like in an enum? or is there another place to register the scan_type?

mhasself · 2026-06-11T12:16:51Z

+        if not self._get_sun_policy('map_valid'):
+            return False, 'Sun Safety Map not computed or stale; run the monitor_sun process.'
+
+        n = max(2, int(np.ceil((el2 - el1) / 1.)))


humor me and throw an "abs" in front of that (el2 - el1) ...

mhasself · 2026-06-11T12:18:05Z

+    MIN_STEP_TIME = 0.05  # in seconds.
+
+    # Get el throw
+    el_throw = abs(el_endpoint2 - el_endpoint1) / 2


I think we want to allow downward nods; so remove the abs().

mhasself · 2026-06-11T12:20:57Z

+        raise ValueError("El Freq is too high! El Freq must be < 1.25Hz to keep "
+                         "step_time > 0.05!")
+
+    step_time = POINTS_PER_NOD * el_freq  # Divide nod into 16 points


Ya I don't think we should force step_time like this. Rather, respect what the user asked for but:

round it, so it evenly divides the nod period.

make sure there are at least 16 points per period.

That's what I described in previous comment. We'll likely need to experiment with this a little to see what step_times work well.

Reworked the step_time in this function. It'll now take the step_time and find the closest step_time that divides the number of points per nod into the closest multiple of four (so that we get clean looking, regular sinewaves).

mhasself · 2026-06-11T12:23:35Z

+                timestamp=t + t0,
+                az=az, el=el, az_vel=0, el_vel=el_vel,
+                az_flag=0, el_flag=1,
+                group_flag=0))


set group_flag=1 except for the final point in each cycle -- that is what will actually force only complete cycles to be uploaded.

mhasself · 2026-06-11T12:38:32Z

+                az_flag=0, el_flag=1,
+                group_flag=0))
+
+            t += step_time


Consider restructuring the loop like this:

# Templates for one cycle template_t = step_time * np.arange(points_per_nod) template_el, template_el_vel = get_el(template_t) # vectors while not done(): point_block = [PointBlock(timestamp=t0 + t, ..., group_flag=1) for (t, el, el_v) in zip(template_t, template_el, template_el_vel)] point_block[0].group_flag = 0 # Ok to stop on the zero vel starting point! yield point_block t0 += 1 / el_freq # And one last zero-vel point. yield [PointBlock(timestamp=t0, ... vels=0, group_flag=0)]

This reduces floating point errors, but also just makes it crystal clear that we're doing one cycle at a time, and they're always identical in el shape.

Reworked the loop to make the cycle more obvious.

mjrand · 2026-07-03T22:22:13Z

I had to change part of the _run_track function to get el nods to work properly. The previous iteration was only and explicitly checking that the azimuth axis was in ProgramTrack mode. This meant that these el nods that only put the el axis into track_axes was failing because the az axis was in in stop mode. Now _run_track should check that every axis in track_axes (which are the axes we expect to be in ProgramTrack mode) are in ProgramTrack mode. This should benefit type2 and 3 scans too which should be checking that the el axis didn't fail but currently don't.

I also added some comments into the abort checks to make it clear what we're checking for abort mode.

mjrand · 2026-07-03T22:26:14Z

I've tested this current commit on satp5 and generated a few nods with varying num_nods and it worked as expected. Here is num_nods=10 el_freq=0.1 , el_depth=-3 starting at el=60.

The free upload positions plot shows that we're uploading full nods at once too:

mjrand requested a review from mhasself June 9, 2026 21:28

mjrand self-assigned this Jun 9, 2026

mjrand added the agent: acu label Jun 9, 2026

mjrand marked this pull request as draft June 10, 2026 21:08

mhasself reviewed Jun 11, 2026

View reviewed changes

mjrand added 4 commits July 1, 2026 01:00

Added gen_sin_el_nod function

9d3c3ed

Added sin_el_nod scan type to generate_scan in ACU agent

9114060

Made generate_sin_el_nod its own agent process

f144552

Updated step_time, generate loop, and various agent bits

6db658d

mjrand force-pushed the ACU_add_sin_el_nod branch from c8dee4c to 6db658d Compare July 1, 2026 01:03

mjrand added 2 commits July 1, 2026 01:26

Removed print from drivers generate function

f2fdc34

Updated _run_track check for ProgramTrack mode to check track_axes

748cf3f

Uh oh!

Conversation

mjrand commented Jun 9, 2026

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

Uh oh!

mhasself commented Jun 10, 2026

Uh oh!

mjrand commented Jun 10, 2026

Uh oh!

mjrand commented Jun 10, 2026

Uh oh!

mhasself left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mjrand commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mjrand commented Jul 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mjrand commented Jul 3, 2026 •

edited

Loading