Add Space Robotics

[AndrejOrsula]

https://github.com/AndrejOrsula/awesome-space-robotics

This list curates resources, hardware platforms, software frameworks, and algorithms specifically tailored for robotic systems in space.

Reviewed PRs:

1. Add Scientific Image Analysis #3831 (review)
2. Add Rust Python #3874 (review)
3. Add AI Evaluation #3923 (review)
4. Add RISC-V #3980 (review)

By submitting this pull request I confirm I've read and complied with the below requirements 🖖

Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

Requirements for your pull request

• Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
• Don't waste my time. Do a good job, adhere to all the guidelines, and be responsive.
• You have to review at least 4 other open pull requests.
  Try to prioritize unreviewed PRs, but you can also add more comments to reviewed PRs. Go through the below list when reviewing. This requirement is meant to help make the Awesome project self-sustaining. Comment here which PRs you reviewed. You're expected to put a good effort into this and to be thorough. Look at previous PR reviews for inspiration. Just commenting “looks good” or simply marking the pull request as approved does not count! You have to actually point out mistakes or improvement suggestions. Comments pointing out lint violation are allowed, but does not count as a review.
• You have read and understood the instructions for creating a list.
• This pull request has a title in the format Add Name of List. It should not contain the word Awesome.
  • ✅ Add Swift
  • ✅ Add Software Architecture
  • ❌ Update readme.md
  • ❌ Add Awesome Swift
  • ❌ Add swift
  • ❌ add Swift
  • ❌ Adding Swift
  • ❌ Added Swift
• Your entry here should include a short description of the project/theme of the list. It should not describe the list itself. The first character should be uppercase and the description should end in a dot. It should be an objective description and not a tagline or marketing blurb. It should not contain the name of the list.
  • ✅ - [iOS](…) - Mobile operating system for Apple phones and tablets.
  • ✅ - [Framer](…) - Prototyping interactive UI designs.
  • ❌ - [iOS](…) - Resources and tools for iOS development.
  • ❌ - [Framer](…)
  • ❌ - [Framer](…) - prototyping interactive UI designs
• Your entry should be added at the bottom of the appropriate category.
• The title of your entry should be title-cased and the URL to your list should end in #readme.
  • Example: - [Software Architecture](https://github.com/simskij/awesome-software-architecture#readme) - The discipline of designing and building software.
• No blockchain-related lists.
• The suggested Awesome list complies with the below requirements.

Requirements for your Awesome list

• Has been around for at least 30 days.
  That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
• Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
• The default branch should be named main, not master.
• Includes a succinct description of the project/theme at the top of the readme. (Example)
  • ✅ Mobile operating system for Apple phones and tablets.
  • ✅ Prototyping interactive UI designs.
  • ❌ Resources and tools for iOS development.
  • ❌ Awesome Framer packages and tools.
• It's the result of hard work and the best I could possibly produce.
  If you have not put in considerable effort into your list, your pull request will be immediately closed.
• The repo name of your list should be in lowercase slug format: awesome-name-of-list.
  • ✅ awesome-swift
  • ✅ awesome-web-typography
  • ❌ awesome-Swift
  • ❌ AwesomeWebTypography
• The heading title of your list should be in title case format: # Awesome Name of List.
  • ✅ # Awesome Swift
  • ✅ # Awesome Web Typography
  • ❌ # awesome-swift
  • ❌ # AwesomeSwift
• Non-generated Markdown file in a GitHub repo.
• The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
• Not a duplicate. Please search for existing submissions.
• Only has awesome items. Awesome lists are curations of the best, not everything.
• Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.
• Includes a project logo/illustration whenever possible.
  • Either centered, fullwidth, or placed at the top-right of the readme. (Example)
  • The image should link to the project website or any relevant website.
  • The image should be high-DPI. Set it to a maximum of half the width of the original image.
  • Don't include both a title saying Awesome X and a logo with Awesome X. You can put the header image in a # (Markdown header) or <h1>.
• Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
• Includes the Awesome badge.
  • Should be placed on the right side of the readme heading.
    • Can be placed centered if the list has a centered graphics header.
  • Should link back to this list.
• Has a Table of Contents section.
  • Should be named Contents, not Table of Contents.
  • Should be the first section in the list.
  • Should only have one level of nested lists, preferably none.
  • Must not feature Contributing or Footnotes sections.
• Has an appropriate license.
  • We strongly recommend the CC0 license, but any Creative Commons license will work.
    • Tip: You can quickly add it to your repo by going to this URL: https://github.com/<user>/<repo>/community/license/new?branch=main&template=cc0-1.0 (replace <user> and <repo> accordingly).
  • A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.
  • Place a file named license or LICENSE in the repo root with the license text.
  • Do not add the license name, text, or a Licence section to the readme. GitHub already shows the license name and link to the full text at the top of the repo.
  • To verify that you've read all the guidelines, please comment on your pull request with just the word unicorn.
• Has contribution guidelines.
  • The file should be named contributing.md. The casing is up to you.
  • It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
  • The section should not appear in the Table of Contents.
• All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
• Has consistent formatting and proper spelling/grammar.
  • The link and description are separated by a dash.
    Example: - [AVA](…) - JavaScript test runner.
  • The description starts with an uppercase character and ends with a period.
  • Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
• Does not use hard-wrapping.
• Does not include a CI (e.g. GitHub Actions) badge.
  You can still use a CI for linting, but the badge has no value in the readme.
• Does not include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Go to the top and read it again.

[AndrejOrsula]

unicorn

[Copilot]

Pull request overview

Adds a new Awesome list entry for “Space Robotics” to the main Awesome directory under the Hardware category.

Changes:

• Added a nested “Space Robotics” entry under the existing “Robotics” item in the Hardware section.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AndrejOrsula]

Please note that awesome-lint fails only due to duplicate (double) links:

$ npx awesome-lint https://github.com/AndrejOrsula/awesome-space-robotics
✖ Linting

  README.md:50:3
  ✖   50:3  Duplicate link: https://jplopensourcerover.com remark-lint:double-link
  ...
  ✖  303:3  Duplicate link: https://jplopensourcerover.com remark-lint:double-link

However, this is purposeful. For instance, https://jplopensourcerover.com is referenced two times, as:

1. Open source hardware platform (line 50)
2. Interactive web demo due to the design of this homepage (line 303)

I believe this makes sense, as people searching for interactive demonstrations would otherwise not come across this website when browsing the awesome list. Please let me know if you think otherwise. Thank you.

[wolffcatskyy]

One issue worth noting:

1. Entry placement: The guidelines state "Your entry should be added at the bottom of the appropriate category." The PR places this as a nested bullet under Robotics rather than at the bottom of the Hardware section. The PR acknowledges this and offers to move it — I'd suggest following the guideline and placing it at the bottom of the Hardware category as a top-level entry, since sindresorhus/awesome doesn't use nested category structure for sub-topics.

2. Description: The entry description says "Resources, hardware platforms, software frameworks, and algorithms tailored for robotic systems in space." — this reads more like a description of the list itself rather than the topic. Per the guidelines, it should describe the project/theme, not the list. Something like "Robotics systems designed to operate in outer space environments." would be more appropriate.

3. Logo check: The list appears to have a logo — looks good.

Overall this is a well-prepared PR with good checklist compliance and substantive reviews of other PRs.

🤖 This review was generated by Claude AI assisting a maintainer.

[be-next]

Really solid list! The depth of the taxonomy is impressive, especially the split between deployed, experimental, and open-source systems. The inclusion of terrestrial analogue sites and laboratory facilities is a nice touch that I haven't seen in other robotics lists. Multi-format output (HTML/PDF/Markdown) is a great addition too.

A few observations:

• Entry placement: as already noted, the entry should go at the bottom of the Hardware category rather than nested under Robotics, per the guidelines.
• Description wording: "Software, hardware, and algorithms for robotic systems in space" describes the list itself rather than the topic. Something like "Robotic systems designed for space environments" would better match the awesome guidelines (the description should describe the topic, not the list).
• Tagline: the "Contributions are welcome!" in the README tagline is redundant since there's already a CONTRIBUTING.md, might be cleaner without it.
• Nesting depth: some sections go 4 levels deep (e.g., Systems > Hardware Platforms > Surface Vehicles > Open Source). This works well for the HTML version, but in a long Markdown README it can make scanning harder. Maybe worth considering flattening a level or two in the most nested areas.

Overall, this is well-researched and clearly maintained.

[luka2chat]

Impressive and thorough list! A few compliance issues to address:

• CONTRIBUTING.md should be renamed to contributing.md (lowercase). The guidelines state: "The file should be named contributing.md."
• The Contents section uses two levels of nested lists (e.g., Systems > Hardware Platforms, Algorithms > Perception). The guidelines say it should only have one level of nested lists, preferably none.
• The README contains <!-- BEGIN GENERATED CONTENT --> comments, indicating content is auto-generated from source files. The guidelines require "Non-generated Markdown file in a GitHub repo."
• The heading uses inline HTML with an image tag. A simpler standard Markdown heading format would be cleaner.

[AndrejOrsula]

Thanks @wolffcatskyy, @be-next, and @luka2chat for the detailed reviews and helpful suggestions! I really appreciate you taking the time to help me improve the list.

I've gone ahead and updated the PR to address the feedback. I moved the Space Robotics entry to the very bottom of the Hardware category as a top-level item, and I updated the description to "Robotic systems designed for space environments" so it properly describes the theme rather than the list itself.

Over at awesome-space-robotics, I've also resolved the formatting and compliance issues you pointed out. I cleaned up the main heading to use standard Markdown, and dropped the redundant contribution text from the tagline. I also took the advice to flatten the taxonomy and removed the deepest levels of nesting, such that the document doesn't go deeper than four levels now.

According to the guidelines (see below), the capitalized CONTRIBUTING.md is allowed, so I kept it as is for now:

The file should be named contributing.md. The casing is up to you.

---

Just a quick heads up that the awesome-lint CI still complains about the duplicate links, but that's intentional as mentioned above: #3981 (comment)

Thanks again for all the guidance! Please let me know if anything else needs to be corrected.

[sindresorhus]

• awesome-lint fails on duplicate links. The linter reports duplicate link errors for URLs that appear in multiple sections (e.g., jplopensourcerover.com at lines 47 and 267). Use a cross-reference note in the secondary location instead of repeating the full entry, so the lint passes cleanly.

• Self-promotion without disclosure. Space Robotics Bench (SRB) is the author's own project (AndrejOrsula/space_robotics_bench). It appears twice in the list (under "Simulation Environments > Space Robotics" and "Robot Learning > Simulation-Based Learning"). Disclose your authorship.

• Many single-entry sub-sections. These #### sub-sections each have only 1 entry:

  • Image Processing (VICAR)
  • Terrain Analysis (ASP)
  • Ground Systems (Yamcs)
  • Scene Generation (PANGU)
  • Simulation Frameworks (Trick)
  • Simulation-Based Learning (SRB)
  • Saturn (Dragonfly)
  • Teleoperation (METERON)
  • User Interfaces (OpenMCT)

  Merge these into their parent sections or combine related ones. Nine single-entry sub-sections suggests over-categorization.

• ## Contributing heading triggers a lint TOC warning. awesome-lint flags ToC missing item for "Contributing" because it's a level-2 heading. But the guidelines say Contributing must NOT be in the TOC. Fix by removing the ## heading and using a plain paragraph or bold text instead.

• Conceptual duplication between Hardware Platforms and Missions sections. Perseverance, Curiosity, Spirit & Opportunity, Sojourner, Ingenuity, MASCOT, and Dragonfly each appear in both "Hardware Platforms" and "Missions & Applications" with different URLs but describing the same system. This inflates the list. Pick one location for each, and cross-reference from the other.

• Pipe (|) separator in Organizations section is non-standard. Entries like [DLR](https://www.dlr.de/en/rm) | Germany - German Aerospace Center use a | pipe for country. The standard format is - [Name](url) - Description. Use the country as part of the description instead.

• Nested sub-entries within list items. Some entries have child items:

  - [Robot Operating System (ROS)](https://www.ros.org) - Description.
    - [Space ROS](https://space.ros.org) - Description.
  

  And NASA has 4 nested sub-organizations. Awesome lists typically use flat entries. Promote these to top-level entries or incorporate them into the parent description.

• Descriptions are unusually long. Many entries have multi-sentence descriptions (2-3 sentences, some 50+ words). For example, the Curiosity entry is 44 words. Awesome list descriptions are typically one short sentence. Trim to the essential defining characteristic.

• Horizontal rules. The --- separators (after the format icons and before Contributing) are non-standard for awesome lists.

• Deep heading nesting. The content uses up to 4 heading levels (## > ### > #### > entries). For example: Systems > Hardware Platforms > Surface Vehicles > entries. This creates scanning difficulties in a long Markdown file. Consider flattening by one level where possible.

[andreahlert]

niche, well organized, the mission/algorithm split feels like it was built by someone in the field

one thing I didnt see flagged yet: the HTML/PDF/MD icon row right below the description. on the mdbook site it makes sense, on github.com it sits where the TOC should follow and competes visually with the Awesome badge. bottom of the readme would be cleaner