수십 년에 걸친 지연과 잘못된 출발 끝에 NASA는 최종적으로 달로의 귀환. 세계는 1972년 이후 처음으로 우주 발사 시스템과 Orion 다목적 승무원 차량의 첫 시범 비행인 Artemis I의 발사를 간절히 기다리고 있습니다.

첫 번째 공식 아르테미스 임무가 자연스럽게 모든 관심을 받고 있는 동안, 우주국은 표면에 새로운 부츠 세트를 두는 것 이상의 일을 할 계획입니다. 그들의 장기 목표는 집결 지점이 될 "Lunar Gateway" 우주 정거장을 포함하는 것입니다. 가장 가까운 천체의 이웃을 지속적으로 탐사하기 위해.

그러나 NASA는 인류 최초의 심우주 정거장을 발사하기 전에 이 정거장이 작동할 고유한 NRHO(근직선 후광)가 컴퓨터 모델링이 예측한 만큼 안정적인지 확인하기를 원합니다. 들어가다 Cilunar 자율 위치 확인 시스템 기술 운영 및 항법 실험, 또는 캡스톤.

발사 전 클린룸의 캡스톤.
" data-medium-file=”https://hackaday.com/wp-content/uploads/2022/09/capstone_cleanroom.jpg?w=400″ data-large-file=”https://hackaday.com/wp -content/uploads/2022/09/capstone_cleanroom.jpg?w=800″ loading=”lazy” class=”size-medium wp-image-553987″ src=”https://hackaday.com/wp-content/uploads /2022/09/capstone_cleanroom.jpg?w=400″ 대체 너비=”400″ 높이=”287″ srcset=”https://hackaday.com/wp-content/uploads/2022/09/capstone_cleanroom.jpg 1203w, https://hackaday.com/wp-content/uploads/2022/09/capstone_cleanroom.jpg?resize=250,179 250w, https://hackaday.com/wp-content/uploads/2022/09/capstone_cleanroom.jpg?크기 조정 =400,287 400w, https://hackaday.com/wp-content/uploads/2022/09/capstone_cleanroom.jpg?resize=800,574 800w” 크기=”(최대 너비: 400px) 100vw, 400px”>

XNUMX월에 Electron 로켓에 실려 발사된 대형 CubeSat은 NRHO에 진입한 최초의 우주선이 되기를 희망합니다. 지구와 달의 중력이 동등하게 영향을 미치는 방식으로 위치를 지정함으로써 궤도를 유지하려면 주기적인 위치 수정만 필요합니다. 이것은 Lunar Gateway의 궤도를 조정하는 유지 관리 부담을 낮출 뿐만 아니라 스테이션의 추진제 요구 사항을 줄여줍니다.

CAPSTONE은 또한 지상 기반 스테이션 대신 LRO(Lunar Reconnaissance Orbiter)를 기준점으로 사용하는 실험적인 항법 시스템을 테스트할 예정입니다. 미래에 우주선이 정기적으로 달 주위를 맴돌고 있다면, 작동하기 위해 지구의 입력에 의존하지 않는 항법 시스템을 구축하는 것이 중요할 것입니다.

따라서 상대적으로 적은 30천만 달러의 비용과 전자레인지 정도의 크기에도 불구하고 캡스톤은 매우 중요한 임무입니다. NASA의 위대한 달의 열망. 불행히도, 지금까지 일이 계획대로 진행되지 않았습니다. 문제는 이륙한 지 며칠 만에 시작되었으며 이 글을 쓰는 현재에도 임무의 결과는 여전히 매우 위험합니다.

험난한 출발을 하다

Rocket Lab의 Electron 로켓은 28월 4일 발사에서 완벽하게 작동했으며, 그 후 부스터의 세 번째 "킥" 단계가 일련의 엔진 연소를 시작하여 점차 궤도를 상승시켰습니다. XNUMX차례나 엔진을 발사한 뒤 킥스테이지는 XNUMX월 XNUMX일 캡스톤을 발매하기 전까지 최종 TLI(trans-lunar injection) 화상을 입었다. 이것은 우주선을 달을 향한 저에너지 탄도 궤적에 올려놓았고, 이는 XNUMX개월의 여정 동안 일련의 작은 코스 수정 기동으로 정제될 것입니다.

임무의 자유 비행 단계에 들어간 후 캡스톤은 태양 전지판을 확장하여 배터리 충전을 시작하고 다음날로 예정된 첫 번째 코스 수정 화상에 대비하여 안정화되었습니다. 하지만 연락을 하고 얼마 지나지 않아 NASA의 심층 우주 네트워크(DSN) 마드리드 지상역, 캡스톤과의 연락이 끊겼습니다.

약 24시간 후에 통신이 재개되었으며 분석 결과 지상 운영자의 잘못된 명령으로 인해 우주선의 무선 장치가 예기치 않은 상태에 놓이게 되었고 결국 온보드 오류 감지 루틴이 트리거된 것으로 나타났습니다. 차량은 자동으로 재설정되고 오류 상태를 해결했으며 의도한 비행 경로를 유지하기 위해 필요한 기동을 자율적으로 수행했습니다.

CAPSTONE이 이 첫 번째 변칙 현상에서 상처 없이 벗어났고 지상 관제사는 문제가 다시 발생하지 않도록 방지할 수 있다고 생각했지만 첫 번째 경로 수정 기동의 창은 이미 오래전에 지났습니다. 이것은 우주선의 업데이트된 위치와 속도를 감안할 때 새로운 기동을 계획해야 한다는 것을 의미했으며 추가 시간이 소요되는 섬세한 과정이었습니다.

7월 1일 CAPSTONE은 수정된 코스 수정 화상(공식적으로 TCM-XNUMX이라고 함)을 성공적으로 수행했으며, 계산된 코스의 0.75% 이내의 궤적에 자신을 배치.

골칫거리

초기 통신 문제가 해결된 후 임무는 문제 없이 계속되었습니다. 12월 XNUMX일에 약간의 코스 수정이 있었고, 더 큰 TCM-2 기동은 25월 XNUMX일에 수행되었습니다. 사고 없이. 26월 1,531,949일, 캡스톤은 탄도 경로가 도달할 지구에서 가장 멀리 떨어진 951,909km(XNUMX마일)의 정점에 도달했습니다.

그러나 8월 3일, 계획된 TCM-XNUMX 기동이 막 끝날 무렵, 우주선의 태도는 일탈하기 시작했습니다. 아직 알려지지 않은 이유로 캡스톤은 반응 바퀴는 진동에 대응할 수 없었습니다., 그리고 차량은 통제할 수 없는 구덩이에 빠졌습니다. 안테나가 더 이상 지구를 가리키지 않게 되면서 통신은 다시 한 번 두절되었습니다.

그날 저녁 임무 관제사는 작전 비상사태를 선포하여 DSN의 추가 기능에 접근할 수 있었습니다. 이를 통해 결국 다음날 캡스톤으로부터 약한 원격 측정 신호를 수신할 수 있었지만 데이터는 암울해 보였습니다. 회전으로 인해 우주선의 태양 전지판은 배터리를 충전하기에 충분한 에너지를 생성하지 못했으며, 이는 우주선이 전력 ​​부족으로 자주 재설정되는 원인이 되었습니다. 설상가상으로 온보드 히터를 가동할 에너지가 없었기 때문에 궁극적으로 텀블을 멈추는 데 필요한 추진기가 이제 단단히 얼어붙었습니다.

하지만 나쁜 소식만 있었던 것은 아닙니다. TCM-3 화상은 캡스톤이 의도한 궤도 궤적에 있을 만큼 충분히 진행된 것으로 확인되었습니다. 따라서 우주선이 기술적으로 제어할 수 없는 동안에도 여전히 달을 향하고 있었습니다.

진화하는 상황

현재, 캡스톤 팀의 마지막 업데이트 15월 XNUMX일에 만들었다. 큰 소식은 우주선이 여전히 회전하고 있지만 태양 전지 패널이 배터리를 충전할 만큼 충분한 빛을 받고 있다는 것입니다. 비록 그들이 감소된 듀티 사이클에서 분명히 작동하고 있지만, 히터를 작동시키기 위한 충분한 에너지가 예산에 있었습니다. 그래도 냉정함을 없애기에 충분하며 추진 시스템이 곧 기능을 평가할 수 있을 만큼 충분히 높은 온도에 도달하기를 희망합니다. 그들이 다시 온라인 상태가 될 수 있다고 가정하면 회전 방향에 대해 추진기를 발사하면 캡스톤을 다시 제어할 수 있습니다.

캡스톤이 달에 도달하기 전에 몇 가지 더 많은 기동이 필요합니다.
" data-medium-file="https://hackaday.com/wp-content/uploads/2022/09/capstone_timeline.png?w=400" data-large-file=”https://hackaday.com/wp -content/uploads/2022/09/capstone_timeline.png?w=800″ loading=”lazy” class=”size-full wp-image-554017″ src=”https://hackaday.com/wp-content/uploads /2022/09/capstone_timeline.png” alt 너비=”800″ 높이=”451″ srcset=”https://hackaday.com/wp-content/uploads/2022/09/capstone_timeline.png 884w, https:// hackaday.com/wp-content/uploads/2022/09/capstone_timeline.png?resize=250,141 250w, https://hackaday.com/wp-content/uploads/2022/09/capstone_timeline.png?resize=400,225 400 https://hackaday.com/wp-content/uploads/2022/09/capstone_timeline.png?resize=800,451 800w” 크기=”(최대 너비: 800px) 100vw, 800px”>

그러나 우리는 아직 거기에 도달하지 못했습니다. 이 업데이트는 임무 컨트롤러가 처음에 캡스톤이 통제 불능 상태가 된 이유와 다시 발생하지 않도록 방지하는 방법을 결정하기 위해 여전히 데이터를 분석하고 있음을 분명히 합니다. 원래의 임무 타임라인은 우주선을 의도한 궤도에 놓기 위해 여러 번의 추가 화상이 계획되었음을 보여줍니다. 처음 그것의 임무의.

운 좋게도 CAPSTONE은 몇 주 동안 다른 과정을 수정할 필요가 없어 현장의 엔지니어가 상황을 평가할 수 있는 시간을 더 많이 확보할 수 있습니다. 그럼에도 불구하고 세 가지 주요 기동 중 두 가지가 차량을 무반응 상태로 만들었다는 사실은 문제가 됩니다. 특히 몇 차례 더 많은 엔진 연소가 예정된 경우에는 더욱 그렇습니다.