NITANSH THAKERNT / SYSTEMS
Mission Control Engineer
DanSTAR Rocketry

Mission Control

Mission-control and flight-computer software built around explicit state, validated commands, and acknowledged transitions.

All work
DanSTAR command validation and acknowledgement architectureA diagrammatic architectural example: Mission Control validates and sends an ARMED to ASCENT request to the Flight Computer. The requested state remains pending until an acknowledgement returns to Mission Control.ARCHITECTURAL EXAMPLE · ARMED → ASCENTVALIDATEpayload + eligibilitySENDto flight computerAWAIT ACKtransition pendingRETURN ACKback to controlCONFIRMcommit after ACKVALIDATED COMMAND →SOURCE + VALIDATORMISSION CONTROLvalidate payloadCOMMAND RECEIVERFLIGHT COMPUTERreceive + ACK← ACKNOWLEDGEMENT RETURNSCURRENT STATEARMEDREQUESTED STATEASCENTNOT SENTCONFIRMED STATE—
Command path / state verificationArchitecture abstraction

The problem

Mission-control software has to represent the same operational sequence as the flight system while remaining diagnosable when software and physical interfaces disagree.

System architecture

  • A flowchart-aligned mission state machine with phase-specific Continue, Abort, and Reset logic.
  • A binary command path with strict payload and current-state validation.
  • Queued asynchronous handling and ZeroMQ-oriented messaging between mission-control and flight-computer software.
  • A Python flight-computer simulator covering state progression, command handling, UDP discovery, and log emission.

Engineering decisions

  • Treat flight-computer acknowledgement as the boundary for a confirmed transition.
  • Keep invalid commands from silently changing mission-control state.
  • Make simulator scenarios and emitted logs part of the integration workflow rather than an afterthought.

Testing and verification

  • Hardware-free scenario testing against the flight-computer simulator.
  • Validation rules for payload shape and state-specific command eligibility.
  • Logging and debugging workflows for repeatable integration diagnosis.

Limitations

  • The portfolio describes software architecture and verification practices, not flight results.
  • Repository code and internal integration material are not published here.

What I would improve next

  • Extend scenario coverage around failure recovery and delayed acknowledgements.
  • Keep protocol and state-machine documentation synchronized with implementation changes.