Neowin Think Tank: Mars Colony One (and Two ... and Three ... and ... )


Recommended Posts

@BetaguyGZT...you have a tough decision to make...Don't mind me...I think you can tell the frustration of 40 years of low productivity to lack of vision....My first gut instinct is to bust out of the gates and make up for it......make your decision on available data and go with it...we have to start somewhere....as long as we have a plan...let's do it......Being that this is a simulation and we are lacking a lot of data...maybe a plan to start and carry on will do...we can keep to the plan and change variables later but keep main focus......This will be a tough decision for you... but it might as well have a start and we go from there.

With regard to habitat can we not make the initial housings like the old wagon trains in that it is not statical but with onboard reactors and solar panels able to be driven across the area?

 

Tri-ATHLETE-prototype-JPL-20100512-level

http://lunarnetworks.blogspot.co.uk/2010/07/tri-athlete-lunar-vehicle-prototype.html

 

The Tri-ATHLETE vehicle is the second generation of a wheel-on-limb vehicle being developed to support the return of humans to the lunar surface. This paper describes the design, assembly, and test of the Tri-ATHLETE robotic system with a specific emphasis on the limb joint actuators. The design and implementation of the structural components is discussed, and a novel and low cost approach to approximating flight-like cabling is also presented. The paper concludes with a discussion of the

The ATHLETE series evolved into the Space Exploration Vehicle (SEV) which can operate in space as a free-flying "pod" or shuttlecraft or on land as an exploration rover with the addition of a base platform.

https://www.neowin.net/forum/topic/1052987-nasa-sev-space-exploration-vehicle/

  • Like 1

In SpaceX's case I'd bet on Tesla involvement for rovers, especially for batteries and electric drive trains and Solar City for solar arrays. May as well cut out the middlemen and keep it in the 'family.'

We already know their Seattle factory will be doing commsats for Earth and Mars, and that solar electric propulsion (at least Hall thrusters) will be built in-house.

SpaceX's Falcon heavy is a lock. It flies later this year, or whenever the KSC LC-39A and Vandenberg SCL-4E upgrades are completed.

SpaceX's un-named super-heavy launcher, nicknamed the BFR (Big F'ing Rocket), is already in development. Its methane fueled Raptor engine components have been under test at NASA Stennis for over a year, and its a beast. Based on what SpaceX has leaked BFR will make the Saturn V, and SLS, "look small."

How big?

The SLS will use a core stage 8.4 meters across.

Saturn V used a 10 meter wide core.

BFR started out with a stated 10 meter core, but given its current expected performance, and the thirst of Raptor for liquid methane, it would need a 12.5 to 15 meter core or it'd have to be over 450 feet tall.

Most people are betting on BFR having a 15 meter core, or nearly 1.79x as wide as SLS, and about 350 feet tall. This would also simplify ground ops to within existing experience.

  • Like 1

So for our endeavours, can we agree ladies and gents, for the first few ferries of our colony's gear, we use a Falcon Heavy and then switch over to the Spacex BFR?

 

Any other suggestions for rockets, please chime in.

  • Like 2

I don't know of anything as large as BFR in the pipeline, and the MCT (Mars Colonial Transporter) system is stated as being able to land 100 tonnes of cargo on the Martian surface.

SpaceX has saidote info will be announced later this year. I'm suspecting around the BEAM habitat launch on Dragon CRS-8 or shortly after.

How much cargo are we planning to ferry and over how many trips prior to manned launches and I take it we want to make sure its landed and working prior to commit.So over what time scale?

 

Oh and another thought what about an orbiting rescue boat?

How much cargo are we planning to ferry and over how many trips prior to manned launches and I take it we want to make sure its landed and working prior to commit.So over what time scale?

 

Oh and another thought what about an orbiting rescue boat?

 

With 100 tonnes cargo capacity, they can even take the kitchen sink! :p

Good afternoon, Colonists. :D

 

So for our endeavours, can we agree ladies and gents, for the first few ferries of our colony's gear, we use a Falcon Heavy and then switch over to the Spacex BFR?

 

Any other suggestions for rockets, please chime in.

We'll be using SpaceX Falcon Heavy and then BFR when they are available. The MCT is still on the drawing board, so if/when it's available we'll use it. DragonV2+ will be used for landing on Mars, of course it'll be a slightly tweaked version specially designed for Mars, so we'll designate this DragonV2+ as an 'M' Variant. Agreed? :)

 

SLS is likely a no-go due to cost alone, but I won't stop Boeing/Lockheed/anyone else if they wanted to participate ... but having said that, they're going to do stuff OUR way. It's not their show, this time. They'll be a partner just like everyone else.

 

 

With 100 tonnes cargo capacity, they can even take the kitchen sink! :p

They'll have to. Of course, since they're bringing 3D Printers, they can just fabricate some when they get there.  :rofl:

 

 

With regard to habitat can we not make the initial housings like the old wagon trains in that it is not statical but with onboard reactors and solar panels able to be driven across the area?

 

Tri-ATHLETE-prototype-JPL-20100512-level

http://lunarnetworks.blogspot.co.uk/2010/07/tri-athlete-lunar-vehicle-prototype.html

 

The Tri-ATHLETE vehicle is the second generation of a wheel-on-limb vehicle being developed to support the return of humans to the lunar surface. This paper describes the design, assembly, and test of the Tri-ATHLETE robotic system with a specific emphasis on the limb joint actuators. The design and implementation of the structural components is discussed, and a novel and low cost approach to approximating flight-like cabling is also presented. The paper concludes with a discussion of the

Well.....I imagine we need more sites before we can tear data apart.....I think we should narrow it down to 2 sites with a backup just in case for the exploratory....dropping stuff to 2 sites will help to keep costs down....

 

And we need to decide approach on first adventure...do we send mixed mothership with a few V2's...ie: Rc toys and boots....???? :D

Well.....I imagine we need more sites before we can tear data apart.....I think we should narrow it down to 2 sites with a backup just in case for the exploratory....dropping stuff to 2 sites will help to keep costs down....

 

And we need to decide approach on first adventure...do we send mixed mothership with a few V2's...ie: Rc toys and boots....???? :D

Agreed. Narrow it down to two sites, send Rovers from orbit to investigate, boots on the ground when we've got the Gold Site.

 

And I also agree on using two or more DragonV2-M's. Redundancy, backup, contingency. Having that safety margin will do wonders for Colony morale too. They won't feel like they're "stranded".

 

Keep the Mothership in orbit for the return trip to cycle the crews back home if/when needed.

 

Speaking of Cycling Crews, an interesting problem/solution occurs to me. Mars Crews returning from Mars will likely need to be quarantined for a while to get readjusted to Earth Germs.

 

So here's what we'll do to address that. We have these craft Dock at the ISS, or at a new Space Station that can process these crews in (and out), Quarantine them (since they'll likely need some time to get re-adjusted to Earth germs), and then send them home.

 

The very DragonV2-M's that came with them this far will, by then, have been recycled/rehabbed with a fresh set of Earth-Spec parachutes and the SuperDracos will be checked out to make sure they're up to specs and working properly. The flight software will be placed into "Earth Mode", and the crews can then return "all the way home" in the DragonV2's they landed on Mars with.

 

Now we have the DragonV2's back, which can be fully refurbished, upgraded, and made ready for the next Crew Cycle out to Mars -- saving a hell of a lot of time and money. :)

 

Anyone opposed to this procedure?

Seems like they have some big hurdles to deal with. Shielding from radiation, shielding from debris, being able to carry all the food/water etc. I think they will really need to develop more advanced propulsion to make it evonomically feasible. My hopes are with EM drive.

Wont we need two rescue/return boats in orbit though if not all the explorers return and how are we on the medical front in low gravity like on Mars i.e. a simple slip could give us a fracture can it be handled safely?

Wont we need two rescue/return boats in orbit though if not all the explorers return and how are we on the medical front in low gravity like on Mars i.e. a simple slip could give us a fracture can it be handled safely?

That would be the idea. Always one Mothership in orbit. New one arrives, settles in and eventually assumes Command of Orbital Ops, the other one begins the 2-4 month transition to get everyone & everything that is going home onto the ship. There will never be a 24-hour period that there won't be a DragonV2 on the ground.

 

With the stuff that SpaceX has in the works, they want to be able to get a DragonV2 able to go from sitting idle to flight-ready in 90 minutes or less -- and they'll succeed. :yes:

 

As far as medical emergencies, they'll be able to handle something like that on the ground.

I assume we are using 2 SpaceX Dragon V2's........propulsive down and up.....to an orbiting mothership.......we'll have the nurses... :D

Yessir. DragonV2+'s slightly modified to deal with Mars. I'm referring to these as an "-M" variant.

 

- Modified flight software with both Earth and Mars capabilities, and additional procedures/safeguards to ensure we aren't using one mode at the other location.

- Parachutes changed out for landing on Mars

- Parachute coupling/housing changes so that they can be swapped out easily (for landing the crews back on Earth and to deliver the DragonV2-M back home for Rehabbing/Upgrading)

- Changes to the SuperDraco Engines to accommodate medium-duration boost and retro-fire needs (but nothing obscene ...)

- Further changes to the SuperDraco Engines to allow them to be "reloaded" for multiple-use (for landing the crews back on Earth after they've already been used on Mars)

 

Shouldn't be out of the realm of possibility. :yes:

  • Like 1

What if we were to keep mother ship in orbit indefinity....and use a space tug to transit back and forth with people/samples back to earth...then hook up to dockable barges with people and supplies to take to mars.....?????

 

Maybe a few of these barges could be setup with landing propulsion as well as chutes for Mars equipment drops...then turn them into habitats or storage........???

 

Minor annoyance.....one of these ships should be called....... Enterprise.......for tradition.......preferably the mothership...

You man a Mars mothership,could we do a Space Elevator?

 

 

On Earth, with its relatively strong gravity, the required specific strength for the cable material is very high. Current technology is not capable of manufacturing cable materials that are strong and light enough for a space elevator on Earth. However, in 2000, the recently discovered carbon nanotubes were first identified as possibly being able to meet the specific strength requirements for an Earth space elevator.[2] This sparked a surge of interest and development in space elevators focusing on carbon nanotubes and the similar boron nitride nanotubes. In 2014, diamond nanothreads were first synthesized.[4] Since they have strength properties similar to carbon nanotubes, diamond nanothreads were quickly seen as a candidate material as well.[5] Nanotubes and diamond nanothreads both hold promise as materials to make an Earth-based space elevator possible.

The concept is also applicable to other planets and celestial bodies. For locations in the solar system with weaker gravity than Earth's (such as the Moon or Mars), the strength-to-density requirements are not as great for tether materials. Currently available materials (such as Kevlar) are strong and light enough that they could be used as the tether material for elevators there.[6]

 

http://en.wikipedia.org/wiki/Space_elevator

 

a15bbbc17a745d552c5eeb01471cde76.png

What if we were to keep mother ship in orbit indefinity....and use a space tug to transit back and forth with people/samples back to earth...then hook up to dockable barges with people and supplies to take to mars.....?????

 

Maybe a few of these barges could be setup with landing propulsion as well as chutes for Mars equipment drops...then turn them into habitats or storage........???

 

Minor annoyance.....one of these ships should be called....... Enterprise.......for tradition.......preferably the mothership...

 

Usually we will want to cycle the Motherships so as to perform servicing and upgrades on them -- or even swap them for newer and better models as required. The Russians pioneered the art of making stuff last in Space, the ISS has pioneered the art of making it last when it's serviced and upgraded properly. I think that NewSpace can take it a step further without needing to push either boundary.

 

We can get, at minimum, ten years of guaranteed useful service from a Mothership, and likely another five to ten years of probable service from it afterwards before it will need Refitting and Upgrading. We will, of course, reserve the right to recall a Mothership should the need arise and a replacement is available to take command.

 

 

You man a Mars mothership,could we do a Space Elevator?

 

 

http://en.wikipedia.org/wiki/Space_elevator

 

a15bbbc17a745d552c5eeb01471cde76.png

 

Consider this system a "go" for proof-of-concept testing. Anything that has the potential to save the Project money, time, and resources is a winner. Nicely done, arachnoid! Gold star for you .. and you're catching up to DocM and DD in the "good ideas/digging up information" category.  :rofl:

 

Soo ... *looks around the table* ...

 

- Do we have Candidate CoS sites ready for peer review? I know DocM and DD have been chomping at the bit and doing homework. I have some good ones in mind as well. :D

 

- We already know what Launch Hardware we're using; so check, check and check. Falcon-9, Falcon Heavy, and BFR when it's ready. Any equipment needing to be assembled in Earth Orbit should be carried up in "Multi-Payload Configurations" whenever possible to reduce costs.

 

- I'm starting to think we'll need either the Earth Orbiting Station or a Lunar Colony first, to act as both Construction Yard(s) as well as Customs/Medical Quarantine.

 

- Arachnoid & DocM have Habitation and Ground Transportation concerns well in hand.

 

- DD and I are still working out Procedures, but as you all have seen, we're well and capable of sorting out most anything at this point. I encourage everyone to challenge us. PLEASE. Nothing can be left to chance. That's how Science and Engineering demands it. If something looks dodgy, call us out on it. PLEASE. :) Now is the time to get it sorted. 

 

- At this juncture I'm pretty satisfied with how things are coming together. We're two days into the Think Tank, and we haven't run into any showstoppers. :) That's a very encouraging sign.

This topic is now closed to further replies.
  • Posts

    • AMD RX 9070 GRE AI, Blender benchmarks vs 9070 XT, 7800XT, Nvidia RTX 5070, 4070 by Sayan Sen Earlier this week, we shared the first part of our review of AMD's new RX 9070 GRE. It was about the gaming performance of the GPU, and we gave it an 8 out of 10. As a follow-up, similar to how we did with the 9070 XT and non-XT, we are doing a dedicated productivity review for the RX 9070 GRE as well, where we compare it against the 9070 XT, 9070, 7800 XT, as well as Nvidia's 5070 and 4070. This will include AI, rendering, compute, and more benchmarks. AI performance, especially, is a very important metric in today's world, and AMD also promised big improvements thanks to its underlying architectural improvements. We will be pitching it against the data we already have for the RX 9070, and RX 9070 XT, but also the Nvidia 5070 FE, MSI GeForce RTX 4070 VENTUS 2X 12G, and Gigabyte Radeon RX 7800 XT GAMING OC 16G as they are in a similar price class, but also because we do not have a comparable 5060 Ti card lying around here that we can compare it against. Before we get underway, this is a collaboration between Sayan Sen and Steven Parker, who lent me his test bed. Also, there was no editorial input from AMD. First up, the specs of the RX 9070, 9070 XT, and 9070 GRE, which were given to us by AMD: Radeon RX 9070 GRE Radeon RX 9070 Radeon RX 9070 XT Boost Clock: Game Clock: up to 2.79GHz up to 2.20GHz up to 2.52GHz up to 2.07GHz up to 2.97GHz up to 2.40GHz Stream Processors 3,072 (48 CU) 3,584 (56 CU) 4,096 (64 CU) Ray Accelerator 48 56 64 AI Accelerator 96 112 128 ROPs 96 128 Texture Mapping Units 192 224 256 Memory 12 GB GDDR6, 18Gbps Clock, 192-bit Bus 432 GB/s 16 GB GDDR6, 20Gbps Clock, 256-bit Bus Effective Memory Bandwidth: 640 GB/s Infinity Cache 48 MB (3rd Gen) 64 MB (3rd Gen) Card Bus PCI-E 5.0 X16 Output 2x HDMI 2.1b 2x DisplayPort 2.1a Power consumption 220W 304W Recommended PSU 650W 750W Slot width 2x 3x Price (SEP) $549 $599 As you can see from the specs above, it is less than the standard RX 9070 in every way that counts, except for slightly higher Boost and Game clock speed. Design Moving on, the RX 9070 GRE we were given is an XFX Swift triple-fan, dual-slot design with two 8-pin connectors. At 30cm (self-measured), it will fit in most systems easily. There is no RGB either. The AMD Radeon RX 9070 GRE by XFX from all angles. Test system Our test system consists of the following: Lian Li O11 Dynamic Mini V2 Flow (Amazon|Newegg) ASUS Z890 ProArt Creator WiFi (Amazon|Newegg) Intel Core Ultra 7 270K Plus (Amazon|Newegg) Thermal Grizzly KryoSheet - 44x37 (Amazon|Newegg) 2x 16GB G.Skill Trident Z5 RGB (7200 MT/s in XMP) (Amazon|Newegg) Sabrent Rocket4 Plus 2TB SSD (Amazon) Windows 11 25H2 (Build 26200.8246) AMD shared a press driver based on the recently released Adrenaline 26.5.2 that we were required to use. We now move on to our benchmarks. First up, we have Geekbench AI running on ONNX. For some reason, the 9070 GRE does exceptionally well here in both half-precision (FP16) and single-precision (FP32). It manages to beat the RTX 5070 and RX 9070 non-XT, and is only behind the 9070 XT. Since Geekbench runs in short bursts instead of continuously hammering the graphics card, it seems the GRE's faster boost clocks are helping here. Next up, we move to the UL Procyon AI test suite, starting with the image generation benchmark. We chose the Stable Diffusion XL FP16 test since it is the most intense workload available on Procyon. The Nvidia cards do very well here, as even the 4070 out-muscles AMD's best fairy easily. The positive thing about the GRE is that it gets quite close to the 9070 non-XT in this test; this indicates that the VRAM does not play a very big role here, as SD XL relies on float16 (FP16). So this is something to keep in mind again. If you wish to work with float32 AI workloads, graphics cards with larger than 12 GB buffers would likely emerge as victors. Regardless, the gains are still massive on AMD's 9000 series compared to the 7000 series. Following image generation, we move to the text generation benchmark. This is one test where the 9070 GRE struggled, quite a lot. It seems that the 12 GB VRAM and lower memory bandwidth of the new Radeon 9070 GRE are hurting it quite a bit; the split is massive, especially in a test like Llama2, which packs 13 billion parameters. As such, in all the tests, the 9070 GRE is the slowest of the lot. Next, we tried Blender, and here the AMD GPUs were beaten by Nvidia. Rendering is something the Green team has always had a lead over the Red side, and it has not changed so far. On the positive side, though, the 9070 GRE shows significantly better results than the 7800 XT, which means AMD is on the right path. Catching up to Nvidia, though, will require a lot more effort. And we hope HIP and ROCm can keep improving. Wrapping up AI testing, we measured OpenCL throughput in the Geekbench compute benchmark. The RX 9070 GRE alongside the 9070 did not fare well here at all, even falling behind the 7800 XT. Interestingly, even the RTX 5070 could not beat the 4070 on OpenCL, so perhaps this suggests that OpenCL optimization may not have been a priority for either AMD or Nvidia in the modern era. Conclusion We reached the end of our productivity performance review of the 9070 GRE, and we have to say it's a mixed bag. Unlike the 9070 and 9070 XT, the GRE excels in some areas while losing ground fairly easily in others. Similar to how it happened in gaming, any time the card's memory subsystem gets hammered, it tends to fall behind the others. This was the case with text generation, wherein we saw the VRAM sometimes hit its maximum available 12 GB of usage with larger model sizes. So what do we make of the RX 9070 as a productivity hardware? It can certainly be used, but you have to know it has its limitations. For those looking for a GPU that can deal with more, AMD recently unveiled the Radeon AI PRO R9700, which is essentially a 32 GB refresh of the 9070 XT with some additional workstation-based optimizations. On a similar note, the new Ryzen AI Halo platform is something you can consider if you want to set up a local AI processing station. Considering everything, we rate AMD's Radeon RX 9070 GRE a 7.5 out of 10 for its productivity performance. Price is less of a factor for those looking at productivity cases compared to those considering the GPU for gaming, and as such, we felt it did quite decently on many occasions and can be handy if you need a 12 GB GPU and, for some reason, don't want to get Nvidia. Purchase links: RX 9070 / XT / GRE (Amazon US) As an Amazon Associate, we earn from qualifying purchases.
    • Does anyone here know if these updates are integrated into the UUP dump isos?
    • Motrix Next 3.9.4 by Razvan Serea Motrix Next is a modern, open-source cross-platform download manager built as the official next-generation successor to the original Motrix project. It has been completely rewritten using Tauri 2, Vue 3, TypeScript, and Rust, while still relying on the powerful Aria2 download engine for high-speed multi-protocol transfers. The app supports HTTP, HTTPS, FTP, BitTorrent, ED2K and magnet links, offering advanced features like multi-connection acceleration, task scheduling, bandwidth control, and batch download management. With a significantly reduced install size (around 20MB), it focuses on being lightweight, fast, and resource-efficient compared to traditional Electron-based download tools. Designed for Windows, macOS, and Linux, Motrix Next delivers a clean, modern UI inspired by Material Design 3 principles, with smooth animations and a minimal workflow. It improves usability through better download organization, system tray integration, and enhanced torrent handling including selective file downloads and tracker management. Motrix Next features: Multi-protocol downloads — HTTP, FTP, BitTorrent, Magnet, .torrent, ED2K, and Metalink tasks BitTorrent — Selective file download, DHT, peer exchange, encryption controls, metadata caching, GeoIP peer flags, and tracker probing Browser extension integration — Embedded Extension API with independent authentication, download confirmation, smart auto-submit, filename hints, referer/cookie forwarding, and real-time controls (Chrome Web Store · Edge Add-ons) Safe filename handling — Content-Disposition, RFC 2047, non-UTF-8, percent-encoded, and extensionless URL resolution with path traversal sanitization Download organization — Favorite and recent folders, optional file-type categorization, stale-record cleanup, and completed history backed by SQLite Concurrent downloads — Independent controls for active tasks, HTTP connections per server, segments per file, and BT peer limits Speed control — Global and per-task upload/download limits with day-of-week and time-of-day scheduling System integration — Tray operation, optional tray speed display, macOS Dock badge/progress, protocol handlers for magnet://, thunder://, and motrixnext:// Lightweight mode — Destroys the WebView on minimize-to-tray while Rust keeps the engine, task monitor, notifications, history, and extension routing alive Notifications and power options — Native task start/complete/failure notifications, keep-awake during downloads, and optional shutdown after completion Network controls — Scoped proxy support for downloads, app updates, and tracker updates, plus system proxy detection Auto-update channels — Stable, Beta, and Latest Across Channels policies with separate download and install phases Diagnostics — Structured logs, exportable diagnostic ZIPs, database integrity checks, automatic DB rebuild, and Linux GPU rendering fallback Personalization — Light/dark/system theme, 10 color schemes, 26 languages, and first-launch system language detection Motrix Next 3.9.4 changelog: Motrix Next 3.9.4 promotes the 3.9.4 beta cycle to stable. This release refreshes bundled engine binaries, improves task detail readability and copy actions, expands link handling for magnet and ED2K workflows, polishes responsive navigation and text wrapping, updates browser extension documentation, and refines network preference controls. New Features Task Detail copy actions — Added copyable values for task metadata and reusable render functions for long text fields. Magnet and ED2K lifecycle support — Added task lifecycle handling for magnet and ED2K links. History cleanup for deleted tasks — Deleted tasks can now remove matching history records. User-Agent management — Added user-agent management and improved related network preference controls. Browser extension documentation — Added the Firefox Add-ons link for the Motrix Next extension. Improvements Engine binaries — Updated bundled binaries for supported architectures. Task Detail readability — Long task names, URLs, tracker values, and copyable metadata now render more clearly. Deletion messaging — Refined localized task deletion text for clarity and consistency. Text wrapping — Improved URI input wrapping and task name multiline display. Navigation layout — Improved sub-navigation responsiveness. Disk allocation default — Changed the default file allocation method to trunc. Proxy controls — Improved proxy button styling in network preferences. Download: Motrix Next 64-bit | ARM64 | macOS ~20.0 MB (Open Source) Links: Website | macOS / Linux | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • NVIDIA officially supports Ubuntu, as linked above with the GeForce NOW Hands on I did in collaboration with Paul Hill.
    • TO be clear I am not running linux today, however I keep thinking about it. And I want to make sure there are minimal obstacles if I decide to make that switch in the coming months.
  • Recent Achievements

    • Proficient
      Eric Biran went up a rank
      Proficient
    • Dedicated
      Conjor earned a badge
      Dedicated
    • Week One Done
      Windows Guy earned a badge
      Week One Done
    • Dedicated
      Mark Spruce earned a badge
      Dedicated
    • Collaborator
      conkir earned a badge
      Collaborator
  • Popular Contributors

    1. 1
      +primortal
      479
    2. 2
      PsYcHoKiLLa
      250
    3. 3
      Steven P.
      72
    4. 4
      +Edouard
      69
    5. 5
      FloatingFatMan
      67
  • Tell a friend

    Love Neowin? Tell a friend!