Skip to content

25-26 cleanup - #1

Open
14Million wants to merge 6 commits into
mainfrom
docs/25-26_cleanup
Open

14Million wants to merge 6 commits into
mainfrom
docs/25-26_cleanup

Conversation

@14Million

Copy link
Copy Markdown
Contributor

Refactored the code and added much needed documentation

@14Million
14Million requested a review from AhmedKhan04 August 31, 2026 00:57
@14Million 14Million self-assigned this Sep 1, 2026
@AhmedKhan04

Copy link
Copy Markdown
Contributor

Hi! Some comments lmk what you think.

TrackingPhase::SWEEP

Can we make this to be really slow? I am kind of against this idea for safety reasons. I don't want a motor with a antenna to be moving around like that during ground station operations. I don't think that getting an initial lock on the rocket is that big of a deal and its not alot of work.

I also do think that this may not be that simple How will you prevent overshoot with something like this? Say its sweeping and gets a packet from the rocket, but since the packet took time to come in, it actually at that point is no longer on the rocket anymore since it kept on sweeping. It from then, no longer has a lock on the rocket and you basically have a endless feed back loop.

I am okay with this if the velocity is SLOW (like at most angular velocity of pi/2 rad in 1 minute) and there's a solution for the overshoot problem (PID could work here). Otherwise I don't think this is necessary. I rather simplify code as most as possible.

TrackingPhase::LOCK

Good use of GPS for y and z, Kalman for x. We don't have orientation tracking just yet in the EKF so y and z will have to rely on the GPS. But we can assume the rocket is straight up for ascent where packets are slow to come in so I am okay with this. We just need to make sure to update this to fully use Kalman once we have orientation built into the EKF. No concerns here!

Transformations

Happy with this. Nothing else. I don't think anything was super changed here. Conversions look fine. I trust you checked deg->radians units.

GPS_TOL

I see the implementation of GPS_TOL. I am just curious on the motivation for this. This is checking if the location of our turret has changed right and then updating location? I do not forsee our turrett moving so I am just curious on what this is for. I'm not sure I am understanding this part. Also GPS_tol of 5e-5 radians of translates to 318.55 m which is huge.

I will make a more official documentation for this. I just wanted to get the (new) code sorted out first before doing so...but lmk if you've already started that. Includes instructions for set up and stuff + math based logic proof.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants