Closed · Concept Study · ISAM Payload
Robotic Servicing Payload Concept — NASA TechLeap RMPC
This effort is closed. A team was not assembled in time, and no application was submitted. It was a deliberate reach — the first project I took on that could not be done alone — and it is published here, outcome and all.
I set out to assemble a small, multidisciplinary team to develop a concept-stage application for the NASA TechLeap Robotically Manipulated Payload Challenge. I did not get a team together within the challenge timeline, so no application was submitted. The working concept — a compact payload to demonstrate repeatable robotic manipulation: grapple/release, relocation, alignment verification, reinstallation, inspection support, and simple power/data validation — remains published below, along with what the attempt taught me.
The Challenge
NASA TechLeap's Robotically Manipulated Payload Challenge invites applicants to propose payloads that can interact with, be manipulated by, or be reconfigured by a robotic arm in low Earth orbit. The challenge is focused on advancing persistent infrastructure for in-space servicing, assembly, and manufacturing.
All dates, eligibility rules, technical requirements, insurance requirements, and award details should be confirmed against the official challenge materials.
Working Concept: Robotic Servicing Validation Payload
The proposed concept is a compact ORU-style robotic servicing validation payload. The goal is to demonstrate repeatable robotic manipulation tasks that support future modular spacecraft, servicing, inspection, and upgradeable orbital infrastructure.
- Robotic grapple and release
- Payload relocation
- Alignment verification
- Reinstallation or reseating
- Visual fiducial inspection support
- Simple power/data validation
- Repeatable manipulation cycles
- Telemetry or observable success criteria
The design image is only conceptual and will be refined by the team based on official technical constraints, spacecraft interface requirements, mass/power/thermal limits, safety rules, and team expertise.
Why This Matters
Future spacecraft and orbital platforms will need to be serviceable, modular, inspectable, and upgradeable. A small manipulation-focused payload can help demonstrate practical steps toward robotic servicing, assembly, modular payload swapping, and maintainable space infrastructure.
- Supports ISAM development
- Demonstrates modular payload handling
- Creates measurable robotic manipulation success criteria
- Builds experience around flight-payload requirements
- Creates a credible portfolio project even if the application is not selected
The Team This Would Have Needed
Not recruiting — this list is kept as the record of what the payload actually required. It is also the clearest illustration of the point above: none of these are roles I could have filled myself, at any level of effort. The flight-hardware and environmental-test roles are the ones that never filled, and they are the ones that mattered most.
- Mechanical / aerospace engineering
- Electrical / embedded systems
- Robotics / controls / manipulation planning
- CAD / mechanical design
- CNC machining, welding, fabrication, or rapid prototyping
- Space systems / payload integration
- Thermal / power / mass budgeting
- Spaceflight materials, launch vibration, thermal/vacuum, or environmental test experience
- Payload operations / CONOPS / flight-test planning
- Flight hardware / test planning experience
- Faculty, advisor, or industry mentor support
Students, early-career professionals, career switchers, experienced engineers, faculty, industry mentors, and advisors are welcome if they can contribute meaningfully and meet the official challenge eligibility requirements.
About the Organizer
I'm Dan Lee-Odinson, an HCM implementation specialist and returning Space Studies student building a transition path into the space industry. My background is in systems implementation, client-facing technical project work, requirements coordination, workflow design, training, documentation, budget-sensitive implementation planning, and AI-assisted research/development.
For this challenge, I plan to support the team as project lead and proposal/application coordinator: organizing the application package, project plan, budget, documentation, timeline, team coordination, requirements tracking, and submission workflow. I'm seeking technical collaborators and advisors to help define, validate, and mature the payload concept.
What Actually Happened
- June – July 2026 Concept developed, page published, open call for collaborators and advisors
- July 10, 2026 Target date for core team consideration — passed without a viable team
- July 2026 Effort closed. No team assembled; no Phase 1 application submitted.
Core team consideration is targeted for July 10, 2026. Advisor, reviewer, or backup contributor interest may still be reviewed after that date if needed.
Compensation and Prize Disclaimer
This is an unpaid, volunteer team-forming opportunity for a prospective NASA TechLeap Robotically Manipulated Payload Challenge application. Participation does not guarantee selection, prize funding, reimbursement, employment, or future compensation.
If the team is selected for an award, any prize distribution, reimbursement, or project-related compensation will be handled according to a written team agreement and pre-determined distribution strategy established before submission or award acceptance.
Eligibility and Insurance Notice
The official challenge materials include insurance or demonstrated financial responsibility requirements for potential winners, including minimum liability coverage requirements. The team will need to confirm the timing, coverage path, and responsible party before award acceptance or participation beyond the application stage.
Status: Closed — and What It Taught Me
The interest form has closed and this effort is no longer recruiting. I did not get a team together in time to compete for the NASA TechLeap Robotically Manipulated Payload Challenge, and no Phase 1 application was submitted.
The first thing I could not do alone
Every other project in my portfolio — a published Chrome extension, a thermal-bounds model, a 45,000-run agent simulation — is solo work, accelerated by AI. This was the first thing I attempted that could not be done that way. A robotic servicing payload needs mechanical engineers, flight-hardware experience, environmental-test experience, and fabrication. No amount of individual effort or AI leverage substitutes for people who have actually built and qualified hardware.
The lesson was about the network, not the payload
I had built a portfolio and a method, but not yet the professional relationships that let you convene a team against a deadline. Team formation is its own discipline, and it runs on a network you have to build before you need it. I was recruiting strangers from a standing start — the hardest version of that problem — and I did not leave enough runway for it.
Nobody pulls off a moonshot alone. That is not a consolation; it is the finding. Apollo was four hundred thousand people. The whole reason I want to work in this industry is to be part of the teams that support these missions — and this is the project that taught me that building the team is the work, not the overhead around it.
What I am changing
- Build the network before the next deadline, not during it — AIAA section, IEEE, university labs, local makerspaces. Relationships first, project second.
- Start from an existing group rather than assembling strangers around a cold-start concept.
- Secure one credible hardware lead before announcing. The first yes is what makes the second yes possible.
- Back-plan from team formation, not from the technical work.
The concept brief, role breakdown, and requirements notes remain published in the repository. They are a concept study, not a flight design, and they were never reviewed by a qualified engineer.