https://aurorarobotics.sssn.us/api.php?action=feedcontributions&feedformat=atom&user=Acmattson3Aurora Robotics - User contributions [en]2026-04-25T22:31:24ZUser contributionsMediaWiki 1.45.3https://aurorarobotics.sssn.us/index.php?title=Main_Page&diff=825Main Page2026-02-14T20:38:13Z<p>Acmattson3: Added location and meeting time.</p>
<hr />
<div>[[File:Original Aurora Robotics Lab Logo.png|alt=The original Aurora Robotics Lab logo, made in Paint.|thumb|The original Aurora Robotics Lab logo, made in Inkscape.]]<br />
<br />
== Welcome to the Aurora Robotics Wiki ==<br />
Welcome to the official wiki for '''Aurora Robotics''' at the University of Alaska Fairbanks! Our team focuses on the research, design, and development of autonomous robotics platforms (like [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]]) for extreme environments, particularly the Moon.<br />
<br />
=== About Us ===<br />
The Aurora Robotics Team is a multidisciplinary group of students and faculty working on various projects aimed at advancing robotics technology for lunar operations. Our team collaborates with NASA and other partners through challenges and grants to explore solutions for challenges in lunar mining, habitat construction, and autonomous navigation.<br />
<br />
We are located in the University of Alaska Fairbanks' engineering building '''(ELIF/JUB) room 118'''. We meet every Thursday (usually even holidays/breaks!) at 1:00pm.<br />
<br />
=== Current Projects ===<br />
<br />
* '''[[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP (Lunar, Autonomous, Modular, Platform)]]''': A highly modular robotic platform designed to serve as the hands of the [[LUMIN]] control system. [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] is being developed to be capable of executing a wide range of tasks on the lunar surface.<br />
* '''[[LUMIN|LUMIN (LUnar Mining and Infrastructure Network)]]''': The overarching control software for all lunar operations. [[LUMIN]] acts as the central command system, using [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robots to create a functional operational network and managing tasks ranging from autonomous construction to resource distribution.<br />
* '''[[LUMINSim]]''': A lunar robotic simulator for [[LUMIN]] built in [https://godotengine.org/releases/4.4/ Godot 4.4] used to develop [[LUMIN]] software and test [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robot designs.<br />
<br />
=== Previous Projects ===<br />
Check out [[Project_Archives|the project archives page]] to see previous projects Aurora Robotics has done.<br />
<br />
=== Our Mission ===<br />
Our mission is to develop largely open-source robotics solutions that address lunar challenges. By building autonomous systems and control networks ([[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] and [[LUMIN]]), we aim to contribute to the advancement of human presence on the Moon and beyond, and even in remote places here on Earth. <br />
<br />
==== Long Term, our vision is: ====<br />
<br />
# Drop off a few [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robots and some equipment in a remote location (on Earth, the Moon, or beyond).<br />
# Autonomously (through [[LUMIN]]) explore and begin developing basic infrastructure (cleared paths, basic equipment/structure setup).<br />
# Begin mining, refining, and preparing resources for expansion.<br />
# Build human-ready structures from the ground up.<br />
<br />
Due to the simplicity and modularity of [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]], our vision includes a point where a couple LAMP robots, with assisting equipment, can develop more LAMP robots, equipment, and infrastructure autonomously, potentially allowing us to remotely colonize entire planets, then their moons, then their star systems and beyond, just by sending a couple robots that way. Then, the LUMIN system can coordinate sending resources back to Earth or inhabited planets (from hard-to-inhabit locations), or humans can move right in (to more habitable locations). <br />
<br />
=== Get Involved ===<br />
We welcome students from all backgrounds to join the Aurora Robotics Team. Regardless of your experience in robotics, programming, mechanical design, if you have an interest in anything you see here, we can find a place for you on our team. Reach out to learn more about how you can get involved in our projects!<br />
<br />
<br />
<br />
See more at [https://auroraroboticslab.com auroraroboticslab.com]</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMIN&diff=824LUMIN2025-09-06T21:28:59Z<p>Acmattson3: Constricted thesis scope</p>
<hr />
<div><h1>LUMIN (LUnar Mining and Infrastructure Network)</h1><br />
<br />
<strong>LUMIN</strong> is a theoretical overarching control software designed to manage and coordinate robotic lunar operations. It acts as the central hub for autonomous and teleoperated systems, coordinating safe and efficient construction, mining, and transport across the lunar surface.<br />
<br />
<h2>Overview</h2><br />
<br />
<p>The LUMIN control system works with various robotic platforms, including the [[L.A.M.P: Lunar, Autonomous, Modular Platform|Lunar, Autonomous, Modular Platform (LAMP)]] and [[Excahauler]]. The goal of LUMIN is flexibility, which is necessary for the incorporation of new tools, modules, and tasks as lunar infrastructure grows, especially in a multi-organizational context.</p><br />
<br />
<p>[[LUMINSim]] is an open-source simulation of the LUMIN system, though many proposed LUMIN features are still in the process of development.</p><br />
<br />
== [[User:Acmattson3|Andrew Mattson's]] Thesis ==<br />
LUMIN, developed in [[LUMINSim]], will be the core of [[User:Acmattson3|Andrew Mattson's]] master's thesis for the Summer 2025, Fall 2025, and Spring 2026 semesters at the [https://www.uaf.edu/uaf/ University of Alaska Fairbanks]. As of July 7th, 2025, Andrew's thesis is titled '''''Multi-Organizational Robot Coordination and Communication via Realistic Lunar Surface Simulation''','' and he will attempt to answer the question: ''Can autonomous robotic systems effectively coordinate tasks, maintain communication, and manage operational safety zones using [https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet] on the lunar surface when operating under constraints such as limited line-of-sight (LOS), signal degradation, and delays, while in a multi-organizational context?'' <br />
<br />
His project aims to:<br />
<br />
* Extend the [[LUMINSim|GodotRobot (LUMINSim) Lunar Mining Simulator]] to simulate realistic communication challenges including LOS, signal degradation, and delayed transmission.<br />
* Evaluate the effectiveness of [https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet] in realistic lunar conditions.<br />
* Implement dynamic safety zones to test [https://www.nasa.gov/artemis-accords/ Artemis Accords]-inspired coordination constraints.<br />
* Perform incremental testing, scaling from basic two-node scenarios to complex multi-robot networks involving satellites, towers, and robots.<br />
<br />
== Core Functions ==<br />
<p>LUMIN's primary functions will include:</p><br />
<ul><br />
<li><strong>Coordination:</strong> Managing operations across the lunar surface, including but not limited to robotic platforms like [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] and [[Excahauler]], to carry out construction, mining, transport, resource distribution, and maintenance tasks safely and efficiently in accordance with the [https://www.nasa.gov/artemis-accords/ Artemis Accords].</li><br />
<li><strong>Data Collection and Analysis:</strong> Gathering information while working on the lunar environment to improve decision-making and research.</li><br />
<li><strong>Communication:</strong> Providing a reliable communication network ([https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet]) for all lunar operations.</li><br />
</ul><br />
<br />
<h2>Future Developments</h2><br />
<br />
<p>As lunar operations expand, LUMIN's feature set will continue to grow, especially as [[User:Acmattson3|Andrew Mattson]] completes his master's thesis.</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=L.A.M.P:_Lunar,_Autonomous,_Modular_Platform&diff=823L.A.M.P: Lunar, Autonomous, Modular Platform2025-08-02T01:22:06Z<p>Acmattson3: Added reference to RobotMoose YouTube video.</p>
<hr />
<div>LAMP is the hands of the [[LUMIN]] control system. It is a highly modular robotic platform designed to enforce safety protocols, develop lunar infrastructure, and generally do what [[LUMIN]] requires. Through coordination with [[LUMIN]], LAMPs in the field will work together to achieve tasks that would be extremely difficult or impossible for a single robot to accomplish.<br />
<br />
For more information and visuals, watch the [https://www.youtube.com/watch?v=GwJjh-E93ZA&ab_channel=RobotMoose RobotMoose YouTube video] about LAMP and [[LAMP v1|Astra]] (A.K.A LAMP v1).<br />
<br />
== Overview ==<br />
LAMP's modularity will allow it to serve a wide range of needs on the Moon. LAMP robots might: <br />
<br />
* Enforce general safety (like patrolling safety zone borders, decommissioning or disabling rogue agents, or developing and maintaining reliable infrastructure)<br />
* Collect data (for use in research, decision-making processes, and policy refinement)<br />
* Distribute resources (by hauling tools, materials, or power across the lunar surface)<br />
* Act as communication relays (before communication infrastructure is in place and during its development, or in especially remote locations)<br />
<br />
LAMP's modularity allows it to complete a large variety of tasks. For example, materials transport may require a flatbed or dump bed, communications infrastructure development may need a specialized tool-head for trenching and a rear payload for spools of wire or tubing.<br />
<br />
=== Previous LAMP candidates: ===<br />
* [[Excahauler]] (created before the LAMP concept)<br />
* [[LAMP v1]] (A.K.A. Astra)<br />
<br />
== Design Philosophy ==<br />
<p>LAMP's design revolves around its versatility for ranges of tasks on the Moon. Specialized tools for LAMP should always be built as attachments that can be easily interchanged to maintain said versatility. Any permanent additions to the main frame should be carefully designed to function across multiple purposes.</p><br />
<br />
To meet the demands of lunar infrastructure, LAMP must maintain simplicity without compromising its abilities in order to: <br />
<br />
# Keep manufacturing costs down.<br />
# Encourage simpler parts, which are ultimately easier to make durable and repair.<br />
# Encourage extension through the system's modularity.__FORCETOC__</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=822LUMINSim Documentation2025-08-02T01:18:53Z<p>Acmattson3: Added reference to RobotMoose YouTube video.</p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work. <br />
** A potential fix is to completely redo BetterHingeJoint3D to work directly with transforms, but this has the side effect of making things ''much'' easier to break the sim if there isn't some sort of implementation of forces.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' (see [[LUMINSim Documentation#Classes|Classes]]) that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays. To find where each of these classes are declares, see [[LUMINSim Documentation#Classes|Classes]]. <br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
For more information and visuals, watch [https://www.youtube.com/watch?v=GwJjh-E93ZA&ab_channel=RobotMoose the RobotMoose YouTube video about Astra].<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Building ==<br />
Currently there is no built-in building system (see [[LUMINSim Documentation#2.1. Define challenge types (e.g., unloading, excavation, structure building)|Future Work, Challenge Framework]]), but [[User:Lawlor|Dr. Lawlor]] has begun work on '''[https://github.com/auroraroboticslab/buildot Buildot]'''. <br />
<br />
Working from Buildot, my ([[User:Acmattson3|Andrew Mattson]]) idea is to have: <br />
<br />
* A separate builder interface (Buildot) in the simulator.<br />
* Users would have a way to select buildings made in Buildot and place them down as a holographic blueprint. <br />
** Once the user confirms where they want to place the building, the holographic disappears and the user is prompted to place components in certain locations or excavate areas. <br />
** For example, the [[NASA X-Hab 2025: Modular Robotic Construction|X-Hab 2025]] arch would have the user place all of the anchors, then go to the truss segments and so on. We could even make it so that, to build the arch, the user must have a robot designated for holding up the structure and, as the build process progresses, it can lift the structure as needed. <br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and on-screen controls for mobile users.<br />
<br />
=== Command Line Interface ===<br />
The user interface includes a command line interface (opened by pressing <code>f1</code> if you are in a local game or are the host) with the following commands:<br />
<br />
* <code>goto X Y Z</code> – Pathfind to the entered coordinates. '''Not working''' until a new autonomy system is implemented.<br />
* <code>respawn</code> – Teleport back to the starting position.<br />
* <code>move X Y Z</code> – Teleport to the given coordinates ''relative'' ''to your current position''.<br />
* <code>grav X</code> – Change the gravity to <code>X</code> m/s<sup>2</sup><br />
* <code>tp X Y Z</code> – Teleport to the given coordinates ''relative to the world origin.''<br />
* <code>freecam</code> – Enter a freecam state.<br />
* <code>simrate X</code> – Change the speed of the simulation to <code>X</code> times normal speed.<br />
* <code>pause</code> – Pause the simulation. Useful for capturing cinematics (freecam functionality still works, for example).<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.tscn</code> and <code>freecam.tscn</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall simulation loop.<br />
<br />
== Future Work ==<br />
[https://github.com/auroraroboticslab/godotrobot/ The repository] is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Below are the current plans for [[LUMINSim]] to turn it into a commercial product. All contributions are welcome!<br />
<br />
The idea of this breakdown is to first write the idea for implementation under the heading, and then update it over time to reflect the real implementation as it is completed. This might also include changing headings as we progress. These things do not necessarily have to be completed in order, as many systems can be created and made to work together over time. This can then be used as a direct reference for creating documentation once pushed.<br />
<br />
=== 1. Terrain Streaming System ===<br />
<br />
==== 1.1. Design chunk-based terrain data model (glTF/GLB) ====<br />
WIP<br />
<br />
==== 1.2. Implement terrain export pipeline (server-side) ====<br />
WIP<br />
<br />
==== 1.3. Develop server API for terrain distribution ====<br />
WIP<br />
<br />
==== 1.4. Integrate client-side terrain streaming and chunk loading in Godot ====<br />
WIP<br />
<br />
==== 1.5. Add terrain caching for offline/local testing ====<br />
WIP<br />
<br />
=== 2. Challenge Framework ===<br />
<br />
==== 2.1. Define challenge types (e.g., unloading, excavation, structure building) ====<br />
This requires we have a building system (see the stub for [[LUMINSim Documentation#Building|Building]]).<br />
<br />
==== 2.2. Implement challenge UI and timers ====<br />
WIP<br />
<br />
==== 2.3. Track and store performance metrics locally ====<br />
WIP<br />
<br />
==== 2.4. Integrate results with leaderboard backend (see 5.3) ====<br />
WIP<br />
<br />
=== 3. Robot Autonomy Interface ===<br />
<br />
==== 3.1. Define LUMINSim scripting API (for movement, sensing, etc.) ====<br />
WIP<br />
<br />
==== 3.2. Implement local scripting sandbox (Python or simplified API) ====<br />
WIP<br />
<br />
==== 3.3. Add ability to deploy user scripts to control robots in challenge mode ====<br />
WIP<br />
<br />
=== 4. Simulated Sensor Suite ===<br />
<br />
==== 4.1. Implement simulated IMU and encoder feedback ====<br />
WIP<br />
<br />
==== 4.2. Implement LIDAR (2D/3D) and depth camera sensors ====<br />
WIP<br />
<br />
==== 4.3. Expose sensor data via scripting API ====<br />
WIP<br />
<br />
==== 4.4. Visualize sensor outputs in debug/test modes ====<br />
WIP<br />
<br />
=== 5. Account & Leaderboard System ===<br />
<br />
==== 5.1. Build account creation and login system (email/password or OAuth) ====<br />
WIP<br />
<br />
==== 5.2. Set up secure backend server with user profiles and authentication ====<br />
WIP<br />
<br />
==== 5.3. Implement leaderboard storage for challenge scores ====<br />
WIP<br />
<br />
==== 5.4. Create frontend UI for viewing and submitting records ====<br />
WIP<br />
<br />
==== 5.5. Implement reward system hooks (for future prize/cosmetic integration) ====<br />
WIP<br />
<br />
=== 6. LunaNet / Artemis Protocol Simulation ===<br />
See [[LUMIN]] for more information.<br />
<br />
==== 6.1. Define safety zone data format and map overlay ====<br />
WIP<br />
<br />
==== 6.2. Define safety zone defaults and rules ====<br />
WIP<br />
<br />
==== 6.3. Notify players of violations with UI feedback or in-sim events ====<br />
WIP<br />
<br />
==== 6.4. Enforce safety zones (LAMP intervention, LunaNet cutoffs) ====<br />
WIP<br />
<br />
==== 6.5. Log compliance for integration with challenge scoring ====<br />
WIP<br />
<br />
=== 7. Steam & Web Demo Packaging ===<br />
<br />
==== 7.1. Configure Godot project export for Steam ====<br />
WIP<br />
<br />
==== 7.2. Create stripped-down web demo with limited map and challenge ====<br />
WIP<br />
<br />
==== 7.3. Prepare demo marketing assets (logo, screenshots, description) ====<br />
WIP<br />
<br />
==== 7.4. Set up Steam store page and submission ====<br />
WIP<br />
<br />
==== 7.5. Deploy web demo on auroraroboticslab.com or similar ====<br />
WIP<br />
<br />
=== 8. Testing & QA ===<br />
<br />
==== 8.1. Write unit tests for API and terrain loading ====<br />
WIP<br />
<br />
==== 8.2. Conduct user testing of challenge flows and scripting ====<br />
WIP<br />
<br />
==== 8.3. Optimize performance for low-end systems (especially web demo) ====<br />
WIP<br />
<br />
==== 8.4. Fix usability issues and polish UI for MVP release ====<br />
WIP</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LAMP_v1&diff=821LAMP v12025-08-02T01:18:45Z<p>Acmattson3: Added reference to RobotMoose YouTube video.</p>
<hr />
<div><h1>LAMP v1 (Astra)</h1><br />
[[File:Astra Digging.png|alt=Astra in LUMINSim, digging on a hill.|thumb|Astra in LUMINSim, digging on a hill.]]<br />
<p><strong>LAMP v1, also known as Astra</strong>, is the first proposed candidate to become [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP (Lunar, Autonomous, Modular, Platform)]]. Designed by [[User:Frozenstiff|Elliott Madsen]], Astra was developed in [https://www.autodesk.com/products/fusion-360/overview Fusion360] and tested in <strong>[[LUMINSim]]</strong> to assess its mining, mobility, and transport capabilities on the lunar surface. This testing revealed core flaws requiring near-complete redesign, which (as of July 3rd, 2025) has yet to be completed.</p><p>For more information and visuals, watch the [https://www.youtube.com/watch?v=GwJjh-E93ZA&ab_channel=RobotMoose RobotMoose YouTube video about Astra] that covers both Astra and [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]].</p><br />
<br />
<h2>Design Overview</h2><br />
<br />
=== Modular Tool Coupler ===<br />
<p>Astra features a single arm equipped with a modular tool coupler, allowing it to utilize any tool designed for it. Unlike <strong>[[Excahauler]]</strong>, Astra does not have a pre-attached bucket, as it's design prioritizes modularity. Astra's tool coupler is located on the end of a two-joint arm and has tilt functionality, providing versatility in operating a range of tools.</p><br />
<br />
=== Modular Bed ===<br />
On Astra's back is a modular bed coupler. This coupler allows it to carry a large variety of beds, including but not limited to:<br />
<br />
* A hopper-style bed (seen in the photo above; for transporting loose material).<br />
* A flatbed (for general transport of solid objects).<br />
* A tool bed (for carrying multiple tool types).<br />
* A communications relay (possibly with an antenna to be lifted by the arm's tool coupler).<br />
<br />
=== Frame ===<br />
Astra's frame was designed to be highly modular while also allowing high mobility across lunar terrain, with emphasis on ease of travel and transport.<h2>Design Flaws and Testing</h2><br />
<br />
<p>During its development and testing in <strong>[[LUMINSim]]</strong>, several design flaws in Astra were identified:</p><br />
<br />
<ul><br />
<li>The arm's hinge point on the frame was positioned too far forward, causing the robot to easily tip over, especially during heavy lifting.</li><br />
<li>The original built-in hopper design was deemed inefficient. This was replaced with the aforementioned modular bed interface, but was not enough to save the overall design due to the previous issue.</li><li>The wheelbase generally struggles in lunar agility.</li><br />
</ul>These insights have guided plans for design improvements in the next [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate.<h2>Related</h2><br />
<br />
<p>For more information or to contribute to the development of the [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] project, visit the team's [https://github.com/AuroraRoboticsLab GitHub page].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=820LUMINSim Documentation2025-07-10T20:39:25Z<p>Acmattson3: Added potential fix for BetterHingeJoint3D issue.</p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work. <br />
** A potential fix is to completely redo BetterHingeJoint3D to work directly with transforms, but this has the side effect of making things ''much'' easier to break the sim if there isn't some sort of implementation of forces.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' (see [[LUMINSim Documentation#Classes|Classes]]) that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays. To find where each of these classes are declares, see [[LUMINSim Documentation#Classes|Classes]]. <br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Building ==<br />
Currently there is no built-in building system (see [[LUMINSim Documentation#2.1. Define challenge types (e.g., unloading, excavation, structure building)|Future Work, Challenge Framework]]), but [[User:Lawlor|Dr. Lawlor]] has begun work on '''[https://github.com/auroraroboticslab/buildot Buildot]'''. <br />
<br />
Working from Buildot, my ([[User:Acmattson3|Andrew Mattson]]) idea is to have: <br />
<br />
* A separate builder interface (Buildot) in the simulator.<br />
* Users would have a way to select buildings made in Buildot and place them down as a holographic blueprint. <br />
** Once the user confirms where they want to place the building, the holographic disappears and the user is prompted to place components in certain locations or excavate areas. <br />
** For example, the [[NASA X-Hab 2025: Modular Robotic Construction|X-Hab 2025]] arch would have the user place all of the anchors, then go to the truss segments and so on. We could even make it so that, to build the arch, the user must have a robot designated for holding up the structure and, as the build process progresses, it can lift the structure as needed. <br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and on-screen controls for mobile users.<br />
<br />
=== Command Line Interface ===<br />
The user interface includes a command line interface (opened by pressing <code>f1</code> if you are in a local game or are the host) with the following commands:<br />
<br />
* <code>goto X Y Z</code> – Pathfind to the entered coordinates. '''Not working''' until a new autonomy system is implemented.<br />
* <code>respawn</code> – Teleport back to the starting position.<br />
* <code>move X Y Z</code> – Teleport to the given coordinates ''relative'' ''to your current position''.<br />
* <code>grav X</code> – Change the gravity to <code>X</code> m/s<sup>2</sup><br />
* <code>tp X Y Z</code> – Teleport to the given coordinates ''relative to the world origin.''<br />
* <code>freecam</code> – Enter a freecam state.<br />
* <code>simrate X</code> – Change the speed of the simulation to <code>X</code> times normal speed.<br />
* <code>pause</code> – Pause the simulation. Useful for capturing cinematics (freecam functionality still works, for example).<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.tscn</code> and <code>freecam.tscn</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall simulation loop.<br />
<br />
== Future Work ==<br />
[https://github.com/auroraroboticslab/godotrobot/ The repository] is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Below are the current plans for [[LUMINSim]] to turn it into a commercial product. All contributions are welcome!<br />
<br />
The idea of this breakdown is to first write the idea for implementation under the heading, and then update it over time to reflect the real implementation as it is completed. This might also include changing headings as we progress. These things do not necessarily have to be completed in order, as many systems can be created and made to work together over time. This can then be used as a direct reference for creating documentation once pushed.<br />
<br />
=== 1. Terrain Streaming System ===<br />
<br />
==== 1.1. Design chunk-based terrain data model (glTF/GLB) ====<br />
WIP<br />
<br />
==== 1.2. Implement terrain export pipeline (server-side) ====<br />
WIP<br />
<br />
==== 1.3. Develop server API for terrain distribution ====<br />
WIP<br />
<br />
==== 1.4. Integrate client-side terrain streaming and chunk loading in Godot ====<br />
WIP<br />
<br />
==== 1.5. Add terrain caching for offline/local testing ====<br />
WIP<br />
<br />
=== 2. Challenge Framework ===<br />
<br />
==== 2.1. Define challenge types (e.g., unloading, excavation, structure building) ====<br />
This requires we have a building system (see the stub for [[LUMINSim Documentation#Building|Building]]).<br />
<br />
==== 2.2. Implement challenge UI and timers ====<br />
WIP<br />
<br />
==== 2.3. Track and store performance metrics locally ====<br />
WIP<br />
<br />
==== 2.4. Integrate results with leaderboard backend (see 5.3) ====<br />
WIP<br />
<br />
=== 3. Robot Autonomy Interface ===<br />
<br />
==== 3.1. Define LUMINSim scripting API (for movement, sensing, etc.) ====<br />
WIP<br />
<br />
==== 3.2. Implement local scripting sandbox (Python or simplified API) ====<br />
WIP<br />
<br />
==== 3.3. Add ability to deploy user scripts to control robots in challenge mode ====<br />
WIP<br />
<br />
=== 4. Simulated Sensor Suite ===<br />
<br />
==== 4.1. Implement simulated IMU and encoder feedback ====<br />
WIP<br />
<br />
==== 4.2. Implement LIDAR (2D/3D) and depth camera sensors ====<br />
WIP<br />
<br />
==== 4.3. Expose sensor data via scripting API ====<br />
WIP<br />
<br />
==== 4.4. Visualize sensor outputs in debug/test modes ====<br />
WIP<br />
<br />
=== 5. Account & Leaderboard System ===<br />
<br />
==== 5.1. Build account creation and login system (email/password or OAuth) ====<br />
WIP<br />
<br />
==== 5.2. Set up secure backend server with user profiles and authentication ====<br />
WIP<br />
<br />
==== 5.3. Implement leaderboard storage for challenge scores ====<br />
WIP<br />
<br />
==== 5.4. Create frontend UI for viewing and submitting records ====<br />
WIP<br />
<br />
==== 5.5. Implement reward system hooks (for future prize/cosmetic integration) ====<br />
WIP<br />
<br />
=== 6. LunaNet / Artemis Protocol Simulation ===<br />
See [[LUMIN]] for more information.<br />
<br />
==== 6.1. Define safety zone data format and map overlay ====<br />
WIP<br />
<br />
==== 6.2. Define safety zone defaults and rules ====<br />
WIP<br />
<br />
==== 6.3. Notify players of violations with UI feedback or in-sim events ====<br />
WIP<br />
<br />
==== 6.4. Enforce safety zones (LAMP intervention, LunaNet cutoffs) ====<br />
WIP<br />
<br />
==== 6.5. Log compliance for integration with challenge scoring ====<br />
WIP<br />
<br />
=== 7. Steam & Web Demo Packaging ===<br />
<br />
==== 7.1. Configure Godot project export for Steam ====<br />
WIP<br />
<br />
==== 7.2. Create stripped-down web demo with limited map and challenge ====<br />
WIP<br />
<br />
==== 7.3. Prepare demo marketing assets (logo, screenshots, description) ====<br />
WIP<br />
<br />
==== 7.4. Set up Steam store page and submission ====<br />
WIP<br />
<br />
==== 7.5. Deploy web demo on auroraroboticslab.com or similar ====<br />
WIP<br />
<br />
=== 8. Testing & QA ===<br />
<br />
==== 8.1. Write unit tests for API and terrain loading ====<br />
WIP<br />
<br />
==== 8.2. Conduct user testing of challenge flows and scripting ====<br />
WIP<br />
<br />
==== 8.3. Optimize performance for low-end systems (especially web demo) ====<br />
WIP<br />
<br />
==== 8.4. Fix usability issues and polish UI for MVP release ====<br />
WIP</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=819LUMINSim Documentation2025-07-09T22:10:32Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' (see [[LUMINSim Documentation#Classes|Classes]]) that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays. To find where each of these classes are declares, see [[LUMINSim Documentation#Classes|Classes]]. <br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Building ==<br />
Currently there is no built-in building system (see [[LUMINSim Documentation#2.1. Define challenge types (e.g., unloading, excavation, structure building)|Future Work, Challenge Framework]]), but [[User:Lawlor|Dr. Lawlor]] has begun work on '''[https://github.com/auroraroboticslab/buildot Buildot]'''. <br />
<br />
Working from Buildot, my ([[User:Acmattson3|Andrew Mattson]]) idea is to have: <br />
<br />
* A separate builder interface (Buildot) in the simulator.<br />
* Users would have a way to select buildings made in Buildot and place them down as a holographic blueprint. <br />
** Once the user confirms where they want to place the building, the holographic disappears and the user is prompted to place components in certain locations or excavate areas. <br />
** For example, the [[NASA X-Hab 2025: Modular Robotic Construction|X-Hab 2025]] arch would have the user place all of the anchors, then go to the truss segments and so on. We could even make it so that, to build the arch, the user must have a robot designated for holding up the structure and, as the build process progresses, it can lift the structure as needed. <br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and on-screen controls for mobile users.<br />
<br />
=== Command Line Interface ===<br />
The user interface includes a command line interface (opened by pressing <code>f1</code> if you are in a local game or are the host) with the following commands:<br />
<br />
* <code>goto X Y Z</code> – Pathfind to the entered coordinates. '''Not working''' until a new autonomy system is implemented.<br />
* <code>respawn</code> – Teleport back to the starting position.<br />
* <code>move X Y Z</code> – Teleport to the given coordinates ''relative'' ''to your current position''.<br />
* <code>grav X</code> – Change the gravity to <code>X</code> m/s<sup>2</sup><br />
* <code>tp X Y Z</code> – Teleport to the given coordinates ''relative to the world origin.''<br />
* <code>freecam</code> – Enter a freecam state.<br />
* <code>simrate X</code> – Change the speed of the simulation to <code>X</code> times normal speed.<br />
* <code>pause</code> – Pause the simulation. Useful for capturing cinematics (freecam functionality still works, for example).<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.tscn</code> and <code>freecam.tscn</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall simulation loop.<br />
<br />
== Future Work ==<br />
[https://github.com/auroraroboticslab/godotrobot/ The repository] is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Below are the current plans for [[LUMINSim]] to turn it into a commercial product. All contributions are welcome!<br />
<br />
The idea of this breakdown is to first write the idea for implementation under the heading, and then update it over time to reflect the real implementation as it is completed. This might also include changing headings as we progress. These things do not necessarily have to be completed in order, as many systems can be created and made to work together over time. This can then be used as a direct reference for creating documentation once pushed.<br />
<br />
=== 1. Terrain Streaming System ===<br />
<br />
==== 1.1. Design chunk-based terrain data model (glTF/GLB) ====<br />
WIP<br />
<br />
==== 1.2. Implement terrain export pipeline (server-side) ====<br />
WIP<br />
<br />
==== 1.3. Develop server API for terrain distribution ====<br />
WIP<br />
<br />
==== 1.4. Integrate client-side terrain streaming and chunk loading in Godot ====<br />
WIP<br />
<br />
==== 1.5. Add terrain caching for offline/local testing ====<br />
WIP<br />
<br />
=== 2. Challenge Framework ===<br />
<br />
==== 2.1. Define challenge types (e.g., unloading, excavation, structure building) ====<br />
This requires we have a building system (see the stub for [[LUMINSim Documentation#Building|Building]]).<br />
<br />
==== 2.2. Implement challenge UI and timers ====<br />
WIP<br />
<br />
==== 2.3. Track and store performance metrics locally ====<br />
WIP<br />
<br />
==== 2.4. Integrate results with leaderboard backend (see 5.3) ====<br />
WIP<br />
<br />
=== 3. Robot Autonomy Interface ===<br />
<br />
==== 3.1. Define LUMINSim scripting API (for movement, sensing, etc.) ====<br />
WIP<br />
<br />
==== 3.2. Implement local scripting sandbox (Python or simplified API) ====<br />
WIP<br />
<br />
==== 3.3. Add ability to deploy user scripts to control robots in challenge mode ====<br />
WIP<br />
<br />
=== 4. Simulated Sensor Suite ===<br />
<br />
==== 4.1. Implement simulated IMU and encoder feedback ====<br />
WIP<br />
<br />
==== 4.2. Implement LIDAR (2D/3D) and depth camera sensors ====<br />
WIP<br />
<br />
==== 4.3. Expose sensor data via scripting API ====<br />
WIP<br />
<br />
==== 4.4. Visualize sensor outputs in debug/test modes ====<br />
WIP<br />
<br />
=== 5. Account & Leaderboard System ===<br />
<br />
==== 5.1. Build account creation and login system (email/password or OAuth) ====<br />
WIP<br />
<br />
==== 5.2. Set up secure backend server with user profiles and authentication ====<br />
WIP<br />
<br />
==== 5.3. Implement leaderboard storage for challenge scores ====<br />
WIP<br />
<br />
==== 5.4. Create frontend UI for viewing and submitting records ====<br />
WIP<br />
<br />
==== 5.5. Implement reward system hooks (for future prize/cosmetic integration) ====<br />
WIP<br />
<br />
=== 6. LunaNet / Artemis Protocol Simulation ===<br />
See [[LUMIN]] for more information.<br />
<br />
==== 6.1. Define safety zone data format and map overlay ====<br />
WIP<br />
<br />
==== 6.2. Define safety zone defaults and rules ====<br />
WIP<br />
<br />
==== 6.3. Notify players of violations with UI feedback or in-sim events ====<br />
WIP<br />
<br />
==== 6.4. Enforce safety zones (LAMP intervention, LunaNet cutoffs) ====<br />
WIP<br />
<br />
==== 6.5. Log compliance for integration with challenge scoring ====<br />
WIP<br />
<br />
=== 7. Steam & Web Demo Packaging ===<br />
<br />
==== 7.1. Configure Godot project export for Steam ====<br />
WIP<br />
<br />
==== 7.2. Create stripped-down web demo with limited map and challenge ====<br />
WIP<br />
<br />
==== 7.3. Prepare demo marketing assets (logo, screenshots, description) ====<br />
WIP<br />
<br />
==== 7.4. Set up Steam store page and submission ====<br />
WIP<br />
<br />
==== 7.5. Deploy web demo on auroraroboticslab.com or similar ====<br />
WIP<br />
<br />
=== 8. Testing & QA ===<br />
<br />
==== 8.1. Write unit tests for API and terrain loading ====<br />
WIP<br />
<br />
==== 8.2. Conduct user testing of challenge flows and scripting ====<br />
WIP<br />
<br />
==== 8.3. Optimize performance for low-end systems (especially web demo) ====<br />
WIP<br />
<br />
==== 8.4. Fix usability issues and polish UI for MVP release ====<br />
WIP</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=818LUMINSim2025-07-09T21:47:52Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings and how to get started with development.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It currently serves as a tool for testing and refining robots and their operations in a simulated lunar environment. We aim to make LUMINSim a commercially available product (see [[LUMINSim#Current Status and Development|Current Status and Development]]) to assist us in research and testing.<br />
<br />
<p>LUMINSim allows us to test new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates. [[Astra]] was the first [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate, but LUMINSim helped us identify fundamental flaws in its design.</p><br />
<br />
== Vision ==<br />
Our vision is to '''release LUMINSim on Steam as a commercial-ready, full-featured lunar robotics simulator.'''<br />
<br />
* '''Terrain Streaming System:''' A chunk-style terrain download architecture (glTF/GLB) so clients fetch precomputed lunar terrain from a server (rather than generating them locally).<br />
* '''In-Sim Challenges:''' Challenge modes like fastest unloading, excavation, or structure assembly; enable players to script robot behaviors via accessible client APIs. Useful for testing [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and getting useful feedback and data.<br />
* '''Realistic Sensors & Automation API:''' Realistic sensors (LIDAR, depth cams, IMUs, encoders, etc.) and a control API for user-coded autopilots (over local MQTT/websocket?). The ability to send commands over local connections allows users to utilize '''any programming language''' with networking capabilities to talk directly to the simulator.<br />
* '''Leaderboard & Accounts:''' An account system and integrated leaderboard with reward mechanisms (gift cards, in-game cosmetics/land) for the previously mentioned challenges, as well as regular gameplay (i.e., building up your own moon base on your allocated zone), to support competitive play that boosts our research.<br />
* '''Protocol Compliance:''' Realistically enforced LunaNet/Artemis Accords-style safety zones (see [[LUMIN]]) in gameplay to simulate real-world compliance. Allow risk-and-reward scenarios where players can challenge others’ zones, with consequences like protocol bans, network restrictions, and in-sim enforcement via [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robots, while also testing my ([[User:Acmattson3|Andrew Mattson]]'s) thesis work.<br />
* '''Ownership & Economy:''' Create an in-game currency and a system for earning/purchasing lunar land, managing modular base construction (see [https://github.com/auroraroboticslab/buildot/ Buildot]), and calling down/sending up landers (with semi-realistic, or at least proportional wait times?) to get more equipment or send up materials for in-game money.<br />
<br />
For more in-depth information about the future of LUMINSim, see the [[LUMINSim Documentation#Future Work|LUMINSim documentation's future work section]].<h2>Features</h2><br />
<br />
<ul><br />
<li>Playable characters:<br />
<ul><br />
<li>The [[L.A.M.P: Lunar, Autonomous, Modular Platform|<strong>LAMP&nbsp;v1</strong> (Astra)]] rover</li><br />
<li><strong>[[Excahauler]]</strong> (in progress; no fork/dump yet)</li><br />
<li>Procedurally animated <strong>astronaut</strong> character</li><br />
</ul><br />
</li><br />
<li><strong>Deformable lunar terrain</strong> based on NASA height‑map data, with excavation and dirtball re‑merging.</li><br />
<li><strong>Modular tool attachments</strong> (bucket, forks, saw blade) connected via a ToolCoupler.</li><br />
<li><strong>Power system</strong> featuring rechargeable batteries, charging stations, and solar panels.</li><br />
<li><strong>Multiplayer networking</strong> with host/join menus and synchronized objects.</li><br />
<li>User interface with rebindable controls, on‑screen joystick support, and FPS display.</li><br />
<li>Utility scenes such as a brick maker, tool spawner, and dirt spawner.</li><br />
<li>First‑person, third‑person, and spectator free‑camera modes.</li><br />
</ul><h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage. Ongoing development is aimed at developing LUMINSim into a commercial product available on Steam and on the web. The current idea is to have players join to develop their own lunar zones and compete in challenges that assist us in our research. LUMINSim will also continue to serve as a testbed for validating new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and other lunar technologies, especially as users test each candidate's limits.</p><br />
<br />
<p>For more information on the status of LUMINSim's development, see the [[LUMINSim Documentation|LUMINSim Documentation page]].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=817LUMINSim Documentation2025-07-09T21:26:55Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' (see [[LUMINSim Documentation#Classes|Classes]]) that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays. To find where each of these classes are declares, see [[LUMINSim Documentation#Classes|Classes]]. <br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and on-screen controls for mobile users.<br />
<br />
=== Command Line Interface ===<br />
The user interface includes a command line interface (opened by pressing <code>f1</code> if you are in a local game or are the host) with the following commands:<br />
<br />
* <code>goto X Y Z</code> – Pathfind to the entered coordinates. '''Not working''' until a new autonomy system is implemented.<br />
* <code>respawn</code> – Teleport back to the starting position.<br />
* <code>move X Y Z</code> – Teleport to the given coordinates ''relative'' ''to your current position''.<br />
* <code>grav X</code> – Change the gravity to <code>X</code> m/s<sup>2</sup><br />
* <code>tp X Y Z</code> – Teleport to the given coordinates ''relative to the world origin.''<br />
* <code>freecam</code> – Enter a freecam state.<br />
* <code>simrate X</code> – Change the speed of the simulation to <code>X</code> times normal speed.<br />
* <code>pause</code> – Pause the simulation. Useful for capturing cinematics (freecam functionality still works, for example).<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.tscn</code> and <code>freecam.tscn</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall simulation loop.<br />
<br />
== Future Work ==<br />
[https://github.com/auroraroboticslab/godotrobot/ The repository] is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Below are the current plans for [[LUMINSim]] to turn it into a commercial product. All contributions are welcome!<br />
<br />
The idea of this breakdown is to first write the idea for implementation under the heading, and then update it over time to reflect the real implementation as it is completed. This might also include changing headings as we progress. These things do not necessarily have to be completed in order, as many systems can be created and made to work together over time. This can then be used as a direct reference for creating documentation once pushed.<br />
<br />
=== 1. Terrain Streaming System ===<br />
<br />
==== 1.1. Design chunk-based terrain data model (glTF/GLB) ====<br />
WIP<br />
<br />
==== 1.2. Implement terrain export pipeline (server-side) ====<br />
WIP<br />
<br />
==== 1.3. Develop server API for terrain distribution ====<br />
WIP<br />
<br />
==== 1.4. Integrate client-side terrain streaming and chunk loading in Godot ====<br />
WIP<br />
<br />
==== 1.5. Add terrain caching for offline/local testing ====<br />
WIP<br />
<br />
=== 2. Challenge Framework ===<br />
<br />
==== 2.1. Define challenge types (e.g., unloading, excavation, structure building) ====<br />
WIP<br />
<br />
==== 2.2. Implement challenge UI and timers ====<br />
WIP<br />
<br />
==== 2.3. Track and store performance metrics locally ====<br />
WIP<br />
<br />
==== 2.4. Integrate results with leaderboard backend (see 5.3) ====<br />
WIP<br />
<br />
=== 3. Robot Autonomy Interface ===<br />
<br />
==== 3.1. Define LUMINSim scripting API (for movement, sensing, etc.) ====<br />
WIP<br />
<br />
==== 3.2. Implement local scripting sandbox (Python or simplified API) ====<br />
WIP<br />
<br />
==== 3.3. Add ability to deploy user scripts to control robots in challenge mode ====<br />
WIP<br />
<br />
=== 4. Simulated Sensor Suite ===<br />
<br />
==== 4.1. Implement simulated IMU and encoder feedback ====<br />
WIP<br />
<br />
==== 4.2. Implement LIDAR (2D/3D) and depth camera sensors ====<br />
WIP<br />
<br />
==== 4.3. Expose sensor data via scripting API ====<br />
WIP<br />
<br />
==== 4.4. Visualize sensor outputs in debug/test modes ====<br />
WIP<br />
<br />
=== 5. Account & Leaderboard System ===<br />
<br />
==== 5.1. Build account creation and login system (email/password or OAuth) ====<br />
WIP<br />
<br />
==== 5.2. Set up secure backend server with user profiles and authentication ====<br />
WIP<br />
<br />
==== 5.3. Implement leaderboard storage for challenge scores ====<br />
WIP<br />
<br />
==== 5.4. Create frontend UI for viewing and submitting records ====<br />
WIP<br />
<br />
==== 5.5. Implement reward system hooks (for future prize/cosmetic integration) ====<br />
WIP<br />
<br />
=== 6. LunaNet / Artemis Protocol Simulation ===<br />
See [[LUMIN]] for more information.<br />
<br />
==== 6.1. Define safety zone data format and map overlay ====<br />
WIP<br />
<br />
==== 6.2. Define safety zone defaults and rules ====<br />
WIP<br />
<br />
==== 6.3. Notify players of violations with UI feedback or in-sim events ====<br />
WIP<br />
<br />
==== 6.4. Enforce safety zones (LAMP intervention, LunaNet cutoffs) ====<br />
WIP<br />
<br />
==== 6.5. Log compliance for integration with challenge scoring ====<br />
WIP<br />
<br />
=== 7. Steam & Web Demo Packaging ===<br />
<br />
==== 7.1. Configure Godot project export for Steam ====<br />
WIP<br />
<br />
==== 7.2. Create stripped-down web demo with limited map and challenge ====<br />
WIP<br />
<br />
==== 7.3. Prepare demo marketing assets (logo, screenshots, description) ====<br />
WIP<br />
<br />
==== 7.4. Set up Steam store page and submission ====<br />
WIP<br />
<br />
==== 7.5. Deploy web demo on auroraroboticslab.com or similar ====<br />
WIP<br />
<br />
=== 8. Testing & QA ===<br />
<br />
==== 8.1. Write unit tests for API and terrain loading ====<br />
WIP<br />
<br />
==== 8.2. Conduct user testing of challenge flows and scripting ====<br />
WIP<br />
<br />
==== 8.3. Optimize performance for low-end systems (especially web demo) ====<br />
WIP<br />
<br />
==== 8.4. Fix usability issues and polish UI for MVP release ====<br />
WIP</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=816LUMINSim Documentation2025-07-09T21:13:38Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' (see [[LUMINSim Documentation#Classes|Classes]]) that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays. To find where each of these classes are declares, see [[LUMINSim Documentation#Classes|Classes]]. <br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and on-screen controls for mobile users.<br />
<br />
=== Command Line Interface ===<br />
The user interface includes a command line interface (opened by pressing <code>f1</code> if you are in a local game or are the host) with the following commands:<br />
<br />
* <code>goto X Y Z</code> – Pathfind to the entered coordinates. '''Not working''' until a new autonomy system is implemented.<br />
* <code>respawn</code> – Teleport back to the starting position.<br />
* <code>move X Y Z</code> – Teleport to the given coordinates ''relative'' ''to your current position''.<br />
* <code>grav X</code> – Change the gravity to <code>X</code> m/s<sup>2</sup><br />
* <code>tp X Y Z</code> – Teleport to the given coordinates ''relative to the world origin.''<br />
* <code>freecam</code> – Enter a freecam state.<br />
* <code>simrate X</code> – Change the speed of the simulation to <code>X</code> times normal speed.<br />
* <code>pause</code> – Pause the simulation. Useful for capturing cinematics (freecam functionality still works, for example).<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.tscn</code> and <code>freecam.tscn</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall simulation loop.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome!</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=815LUMINSim Documentation2025-07-08T03:07:58Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within a ''single'' <code>.tscn</code> file and a few associated <code>.gd</code> files. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LAMP_v1&diff=814LAMP v12025-07-08T02:56:59Z<p>Acmattson3: </p>
<hr />
<div><h1>LAMP v1 (Astra)</h1><br />
[[File:Astra Digging.png|alt=Astra in LUMINSim, digging on a hill.|thumb|Astra in LUMINSim, digging on a hill.]]<br />
<p><strong>LAMP v1, also known as Astra</strong>, is the first proposed candidate to become [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP (Lunar, Autonomous, Modular, Platform)]]. Designed by [[User:Frozenstiff|Elliott Madsen]], Astra was developed in [https://www.autodesk.com/products/fusion-360/overview Fusion360] and tested in <strong>[[LUMINSim]]</strong> to assess its mining, mobility, and transport capabilities on the lunar surface. This testing revealed core flaws requiring near-complete redesign, which (as of July 3rd, 2025) has yet to be completed.</p><br />
<br />
<h2>Design Overview</h2><br />
<br />
=== Modular Tool Coupler ===<br />
<p>Astra features a single arm equipped with a modular tool coupler, allowing it to utilize any tool designed for it. Unlike <strong>[[Excahauler]]</strong>, Astra does not have a pre-attached bucket, as it's design prioritizes modularity. Astra's tool coupler is located on the end of a two-joint arm and has tilt functionality, providing versatility in operating a range of tools.</p><br />
<br />
=== Modular Bed ===<br />
On Astra's back is a modular bed coupler. This coupler allows it to carry a large variety of beds, including but not limited to:<br />
<br />
* A hopper-style bed (seen in the photo above; for transporting loose material).<br />
* A flatbed (for general transport of solid objects).<br />
* A tool bed (for carrying multiple tool types).<br />
* A communications relay (possibly with an antenna to be lifted by the arm's tool coupler).<br />
<br />
=== Frame ===<br />
Astra's frame was designed to be highly modular while also allowing high mobility across lunar terrain, with emphasis on ease of travel and transport.<h2>Design Flaws and Testing</h2><br />
<br />
<p>During its development and testing in <strong>[[LUMINSim]]</strong>, several design flaws in Astra were identified:</p><br />
<br />
<ul><br />
<li>The arm's hinge point on the frame was positioned too far forward, causing the robot to easily tip over, especially during heavy lifting.</li><br />
<li>The original built-in hopper design was deemed inefficient. This was replaced with the aforementioned modular bed interface, but was not enough to save the overall design due to the previous issue.</li><li>The wheelbase generally struggles in lunar agility.</li><br />
</ul>These insights have guided plans for design improvements in the next [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate.<h2>Related</h2><br />
<br />
<p>For more information or to contribute to the development of the LAMP project, visit the team's [https://github.com/AuroraRoboticsLab GitHub page].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=813LUMINSim Documentation2025-07-08T02:56:36Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within that <code>.tscn</code> file and the associated <code>.gd</code> file. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
Movable, physics-enabled props used primarily for construction.<br />
<br />
* Madsen Cinder Block – a simple RigidBody3D brick spawned by [[LUMINSim Documentation#Static Objects|brick_maker.gd]]. Designed by [[User:Frozenstiff|Elliott Madsen]].<br />
<br />
* Truss Modules – sets of 1m and 3m segments with collision shapes for stacking into arches, garages or other structures. These are modeled after [[NASA X-Hab 2025: Modular Robotic Construction#The L-Truss System|the L-Truss design seen in our 2025 X-Hab project]].<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=812LUMINSim Documentation2025-07-08T02:53:22Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and will be replaced in the future with a more developer-friendly system.<br />
<br />
=== Terrain Nodes ===<br />
The terrain nodes let you represent static or dynamic terrain. They can be nested in other Node3Ds or offset around, but '''should not be scaled.'''<br />
<br />
==== Static Terrain ====<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes. It stores a 256x256 heightmap, normally loaded from an EXR float height image scaled to -10000 meters (black) to +10000 meters (white).<br />
<br />
* `fill_from_image(dem:Image, pixel_spacing:float)` takes an image and pixel spacing in meters to create the height map.<br />
* `add_mesh(shader:Shader,casts_shadows:bool)` creates a mesh for rendering, using the specified shader.<br />
* `add_static_collider()` creates a StaticBody3D with a CollisionShape3D of our heightmap, so physics interacts with the terrain.<br />
<br />
==== Dynamic Terrain ====<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap. It stores a dynamic mineable 256x256 heightmap and inherits from <code>TerrainStatic256</code>.<br />
<br />
* <code>excavate_point(world:Vector3, dirtball_offset:Vector3, spawn_vel:Vector3)</code> to excavate terrain into dirtballs. Any locations needing dirtablls will emit the signal `spawn_dirtball` with a spawn position and velocity as Vector3.<br />
* <code>try_merge(dirtball:Node3D)</code> to merge dirtballs back down onto the terrain.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within that <code>.tscn</code> file and the associated <code>.gd</code> file. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=811LUMINSim Documentation2025-07-08T02:44:20Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts (ordered alphabetically, ignoring case conventions) register custom nodes with the keyword <code>class_name</code>:<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints that better simulate joints driven by hydraulics or linear actuators.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging. See [[LUMINSim Documentation#Power System|Power System]].<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector system useful in many contexts, including tool couplers and charge stations.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints. See [[LUMINSim Documentation#Tools and Attachments|Tools and Attachments]].<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and may be replaced in the future with a more developer-friendly system.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes.<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade (see [[LUMINSim Documentation#Excavation Tools|Excavation Tools]] under [[LUMINSim Documentation#Robot Systems|Robot Systems]]). <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut. We hope to implement VR for the astronaut in the future.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' (see [[LUMINSim Documentation#Classes|Classes]]) for various tasks. The files for these attachments are currently in [[LUMINSim Documentation#Astra Robot|Astra]]'s directory, but this is subject to change.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within that <code>.tscn</code> file and the associated <code>.gd</code> file. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints (See [[LUMINSim Documentation#Major Issues|Major Issues]]).<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations and solar panels (see [[LUMINSim Documentation#Power System|Power System]]), tool spawners, and other generally useful environment pieces. These scenes generally work independently of other scenes, and include:<br />
<br />
*<code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning assigned attachments when they are taken.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing, currently toggle-able by pressing <code>X</code>.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=810LUMINSim Documentation2025-07-08T02:28:24Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:<br />
* Power<br />
* Tools and tool swapping<br />
* Terrain<br />
* Multiplayer<br />
* Each user-controlled scene (robots and astronaut)<br />
* The UI (multiplayer menu, settings menu, keybind menu)<br />
* Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Known Issues ==<br />
The following are known issues that continuously plague the simulator.<br />
<br />
=== Major Issues ===<br />
Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.<br />
<br />
* With no consistency or known cause, some BetterHingeJoint3D (see [[LUMINSim Documentation#Classes|Classes]]) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.<br />
<br />
=== Minor Issues ===<br />
Minor issues are just annoying. Generally they have workarounds or can simply be ignored. <br />
<br />
* The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts register custom nodes with the keyword <code>class_name</code>:<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints.<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector used by tool couplers and charge stations.<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots. See [[LUMINSim Documentation#Autonomy System|Autonomy System]].<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging.<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints.<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools.<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs.<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>, which is declared via GDExtensions. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
These classes are referenced throughout the systems described below.<br />
<br />
== Autonomy System ==<br />
The current autonomous driving logic is implemented by the <code>AutonomyComponent</code> script. Every robot scene instantiates this node under its root <code>VehicleBody3D</code>.<br />
<br />
Currently, this is how it works:<br />
<br />
* A child <code>NavigationAgent3D</code> computes a path when <code>pathfind_to(target_pos)</code> is called.<br />
<br />
* During <code>_physics_process()</code> the component steers the robot toward the next path point using the <code>get_drive()</code> and <code>get_steer()</code> helpers.<br />
<br />
* The helpers are polled by <code>astra_3d.gd</code> so the component effectively overrides manual controls when active.<br />
<br />
* If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the <code>have_arrived</code> flag is set.<br />
<br />
=== Proposed External API ===<br />
To enable players to program autonomy from outside the engine, a new <code>AutonomyServer</code> node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.<br />
<br />
This approach decouples vehicle logic from the engine so users can iterate on autonomy in '''any language''' without recompiling the project. The <code>AutonomyServer</code> would relay commands to the relevant nodes (mirroring the current <code>get_drive()</code> and <code>get_steer()</code> methods) while still supporting multiplayer authority checks via <code>GameManager</code>.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and may be replaced in the future with a more developer-friendly system.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes.<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade. <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== [[Astra]] Robot ===<br />
The main scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> and their associated <code>.tscn</code> files for the robot's arm and hopper.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' for various tasks.<br />
<br />
=== [[Excahauler]] Robot ===<br />
The main scene is <code>excahauler_3d.tscn</code>. Unlike [[LUMINSim Documentation#Astra Robot|Astra's implementation]], all functionalities are within that <code>.tscn</code> file and the associated <code>.gd</code> file. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints.<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third-person.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Independent Scenes ==<br />
Several standalone scenes provide gameplay utilities:<br />
* <code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning attachments.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=809LUMINSim Documentation2025-07-08T01:59:38Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add:<br />
* A list of the non-default classes/nodes this project declares.<br />
* In-depth descriptions of the inner workings of each major system, including:<br />
** Power<br />
** Tools and tool swapping<br />
** Terrain<br />
** Multiplayer<br />
** Each user-controlled scene (robots and astronaut)<br />
** The UI (multiplayer menu, settings menu, keybind menu)<br />
** Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up.<br />
<br />
== Repository Structure ==<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Astra Robot|Astra]] robot.<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See [[LUMINSim Documentation#Classes|Classes]].<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky).<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[LUMINSim Documentation#Excahauler Robot|Excahauler]] robot.<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the static (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Classes ==<br />
The following scripts register custom nodes with `class_name`:<br />
* <code>ToolCouplerComponent.gd</code> → '''ToolCoupler''' – manages attaching tools to a robot via physics joints.<br />
* <code>connector_component.gd</code> → '''Connector''' – area detector used by tool couplers and charge stations.<br />
* <code>autonomy_component.gd</code> → '''AutonomyComponent''' – simple navigation helper for NPC robots.<br />
* <code>charge_component.gd</code> → '''ChargeComponent''' – tracks battery state and handles charging/discharging.<br />
* <code>better_hinge_joint_3d.gd</code> → '''BetterHingeJoint3D''' – wrapper over <code>Generic6DOFJoint3D</code> for motorized joints.<br />
* <code>tool_attachment.gd</code> → '''ToolAttachment''' – base class for all detachable tools.<br />
* <code>forks.gd</code> → '''Forks''' – tool attachment for moving objects.<br />
* <code>bucket_attachment.gd</code> → '''Bucket''' – digs into terrain to collect dirtballs.<br />
* <code>saw_blade_attachment.gd</code> → '''SawBlade''' – spinning blade for cutting objects.<br />
* <code>dem_loader.gd</code> → '''DemLoader''' – loads fixed DEM heightmaps and extends <code>TerrainStatic256</code>.<br />
These classes are referenced throughout the systems described below.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions currently provide the terrain implementation and may be replaced in the future with a more developer-friendly system.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps and generates render and collision meshes.<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> extends <code>TerrainStatic256</code> to simulate excavation, landslides, and merging dirtballs back into the heightmap.<br />
<br />
=== Terrain Tools ===<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Power System ==<br />
Movable vehicles include a '''ChargeComponent''' that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.<br />
<br />
== Tools and Attachments ==<br />
All interchangeable implements derive from '''ToolAttachment'''. Robot arms have '''ToolCoupler''' nodes that detect nearby '''Connector''' areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade. <code>tool_spawner.gd</code> respawns tools removed from its bays.<br />
<br />
== Robot Systems ==<br />
=== Astra Robot ===<br />
The main rover scene is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving, energy usage, and tool attachment. It works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> for the arm and hopper.<br />
<br />
=== Arm and Hopper ===<br />
Separate nodes controlled by <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> implement joint movement.<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally animated astronaut.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend '''ToolAttachment''' for various tasks.<br />
<br />
=== Excahauler Robot ===<br />
Work in progress.<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools.<br />
<br />
== Networking and Multiplayer ==<br />
<code>game_manager.gd</code> manages synchronized player/object data and signals for network updates. <code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
The <code>ui.gd</code>, <code>joystick.gd</code>, and <code>keybinds_menu.gd</code> scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third-person.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Independent Scenes ==<br />
Several standalone scenes provide gameplay utilities:<br />
* <code>brick_maker.gd</code> – creates bricks when filled with loose dirt.<br />
* <code>tool_spawner.gd</code> – keeps bays stocked by respawning attachments.<br />
* <code>dirt_spawner.gd</code> – continuously emits dirtballs for terrain testing.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous helpers include <code>fps_counter.gd</code> for performance output and <code>freecam.tscn</code> which can be spawned via the command console for debugging or spectator play.<br />
<br />
== Future Work ==<br />
The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=NASA_X-Hab_2025:_Modular_Robotic_Construction&diff=808NASA X-Hab 2025: Modular Robotic Construction2025-07-07T22:13:34Z<p>Acmattson3: </p>
<hr />
<div>''This is a stub. You can help by expanding it.''<br />
<br />
<h2>Overview</h2><br />
[[File:Nasa xhab.jpg|thumb|NASA X-Hab Logo]]<br />
<br />
<p>In 2024, [https://spacegrant.org/wp-content/uploads/2024/03/M2M-X-Hab-Challenge-Solicitation-2025.pdf NASA's M2M X-Hab Academic Innovation Challenge for 2025] was released, for which [[Main Page|the Aurora Robotics Lab]] at the University of Alaska Fairbanks was accepted and funded through NASA’s 2024–2025 Moon to Mars X-Hab Academic Innovation Challenge. Our goal was to explore modular robotic construction techniques for lunar infrastructure, especially focusing on micrometeoroid-resistant arch structures made from modular steel trusses and covered in lunar regolith, with a clear path to fully autonomous robotic construction.</p><br />
<br />
<p>The project culminated in the development of the [[Excahauler|Excahauler robotic platform]] with a custom-built arm and end-effector, capable of aligning and assembling scaled modular truss components. Despite limitations in time and resources, the team demonstrated capabilities including truss manipulation, partial structural testing, and scale backfilling with regolith simulant (snow).</p><br />
<br />
<p>This wiki page is a very abridged version of our [https://docs.google.com/document/d/1N_494oalexJXKeGfjDocUZKAdBZPZ5RYqvyGjyIhMkg/edit?tab=t.0 full final report] which should soon be added to [https://ntrs.nasa.gov/ NASA's NTRS database].</p><br />
<br />
<h2>Project Vision and Mission</h2><br />
<ul><br />
<li><strong>Long-Term Vision:</strong> Transform the solar system using robotic construction with local materials.</li><br />
<li><strong>Short-Term Vision:</strong> Develop robotic infrastructure construction technologies for the Artemis Base Camp.</li><br />
<li><strong>Mission:</strong> Design and demonstrate robotic tools and modular structures capable of assembling scalable micrometeoroid-resistant lunar shelters.</li><br />
</ul><br />
<br />
<h2>The L-Truss System</h2><br />
[[File:L-Truss.jpg|alt=The final full-steel L-Truss design.|thumb|The final full-steel L-Truss design.]]<br />
<p>The primary structural innovation was the development of the <strong>L-Truss</strong>: A modular trapezoidal truss segment. These trusses connect via push-fit endplates and spring-loaded capture pins to form straight or curved assemblies, including arches and retaining walls. The final full-steel design used plasma-cut end plates with a 3D printed door latch-style connection. However, full robotic connection could not be demonstrated with this design, so we made some last minute changes. The final prototype design included:</p><br />
<ul><br />
<li>Hybrid steel construction with 3D printed carbon-fiber polycarbonate alignment funnels.</li><br />
<li>Spring-loaded pin latching mechanisms for tool-free robotic assembly.</li><br />
<li>Optional upright members for regolith support and buckling resistance.</li><br />
<li>Final tested form: 1.5m long, ~3kg, with a base angle of 22.5°.</li><br />
</ul><br />
<p>A scale 3D printable version is publicly available: [https://www.printables.com/model/1305834-trapezoidal-l-truss-clip-together-construction-mod L-Truss Model]</p><br />
<br />
<h2>Structure Requirements</h2><br />
<ul><br />
<li>Accommodate 2.6m x 2.6m vehicles within the constructed arch structure. (I.0)</li><br />
<li>Truss segments must remain under 2.0 meters for transport and robotic handling. (I.1.1)</li><br />
<li>Regolith shielding: Support ≥0.2m regolith equivalent for radiation/thermal protection. (O.0)</li><br />
<li>Minimum compressive load capacity of 300 kgf with ≥2.0 safety factor. (I.1.2, I.2.1)</li><br />
<li>Robot-compatible assembly path: all actions must have potential for automation. (E.0, E.2)</li><br />
</ul><br />
<br />
<h2>Concept of Operations</h2><br />
[[File:Arch Assembly Graphic.png|alt=A graphical representation of the truss section assembly process. |thumb|A graphical representation of the truss section assembly process. This is to be done in parallel with other truss sections (i.e., ones behind the one visible) to create a full truss structure.]]<br />
<h3>Lunar Deployment Plan</h3><br />
<ol><br />
<li><strong>Site Preparation:</strong> The Excahauler prepares a foundation using excavation tools.</li><br />
<li><strong>Truss Deployment:</strong> Trusses are unloaded from a logistics lander and staged for assembly.</li><br />
<li><strong>Structural Assembly:</strong> Robots assemble the arch structure according to the graphic on the right.</li><br />
<li><strong>Backfilling:</strong> Lunar regolith is put over the structure via ballistic throwing or traditional scooping.</li><br />
<li><strong>Use Phase:</strong> Covered arches serve as shielding for sensitive lunar equipment or crew.</li><br />
</ol><br />
<br />
<h3>Ground Demonstration Activities</h3><br />
<ul><br />
<li>1:10 scale arch model tested with regolith simulant (basalt dust).</li><br />
<li>Full-scale hybrid trusses fabricated and manipulated via teleoperation.</li><br />
<li>Robotic assembly verified using [[Excahauler]] and custom-built 2500:1 reducer gearbox arm.</li><br />
</ul><br />
<br />
<h2>Project Phases</h2><br />
<ol><br />
<li><strong>System Definition Review (SDR):</strong> October 4, 2024</li><br />
<li><strong>Preliminary Design Review (PDR):</strong> November 15, 2024</li><br />
<li><strong>Critical Design Review (CDR):</strong> January 24, 2025</li><br />
<li><strong>Progress Checkpoint Review (PCR):</strong> April 18, 2025</li><br />
<li><strong>Final Report:</strong> May 23, 2025</li><br />
</ol><br />
<br />
<h2>Robot System: [[Excahauler]]</h2><br />
<ul><br />
<li>Originally designed for the [[Project Archives|2022 NASA Break the Ice Challenge]].</li><br />
<li>Outfitted with a custom modular manipulator arm with 3D printed stepped planetary gearboxes.</li><br />
<li>Used in successful teleoperated tests to transport and align L-Truss segments.</li><br />
</ul><br />
<br />
<h2>Software and Simulation</h2><br />
[[File:X-Hab LUNATIC Software Stack.png|alt=The modified LUNATIC software stack for the X-Hab 2025 project; adds support for the truss manipulator arm.|thumb|The modified LUNATIC software stack for the X-Hab 2025 project; adds support for the truss manipulator arm.]]<br />
<p>The team developed and tested robotic workflows using the following tools:</p><br />
<ul><br />
<li><strong>[[LUMINSim|Godot-based simulator:]]</strong> Visualized structure assembly and layout.</li><br />
<li><strong>[https://github.com/auroraRoboticsLab/MiningRobot?tab=readme-ov-file#lunatic Custom autonomy stack (LUNATIC):]</strong> Handles teleoperation, control, and vision.</li><br />
<li><strong>[https://docs.ros.org/en/humble/index.html ROS2] / [https://moveit.picknik.ai/main/index.html MoveIt]:</strong> Inverse kinematics modeled, full integration for automation incomplete.</li><br />
</ul><br />
<br />
<h2>Testing and Validation</h2><br />
<ul><br />
<li>FEM analysis showed safety factor >2.6 under 500N compressive loads.</li><br />
<li>Hybrid trusses withstood >500N axial loads; failure occurred at 230N in bending.</li><br />
<li>1/10 scale arch supported >12kg in Earth gravity, equivalent to 36+ tonnes in Mars gravity at full scale.</li><br />
</ul><br />
<br />
<h2>Educational Integration</h2><br />
<p>Project integrated into UAF's CS 493 (Fall) and CS 454 (Spring), providing hands-on systems engineering experience to undergraduates and graduate students in mechanical and computer science disciplines.</p><br />
<br />
<h2>Outreach Activities</h2><br />
<ul><br />
<li><strong>UAF Party in the Park:</strong> Public engagement event with live robot demos.</li><br />
<li><strong>FTC Robotics Tours:</strong> Guided tour for K–12 robotics students.</li><br />
<li><strong>UAF Engineering Open House:</strong> Structural demo and recruiting opportunity.</li><br />
</ul><br />
<br />
<h2>Lessons Learned</h2>We were not able to complete our promised deliverables to full satisfaction due to time constraints and lack of defined leadership structure. We learned important lessons about:<ul><br />
<li><strong>Structure:</strong> Even small teams benefit from defined leadership and task ownership.</li><br />
<li><strong>Planning:</strong> Conservative scoping ensures project deliverables can be met.</li><br />
<li><strong>Fabrication:</strong> Early design-for-manufacturing saves time and enables iteration.</li><br />
</ul><br />
<br />
<h2>Future Work</h2><br />
<ul><br />
<li>Complete full-scale robotic arch assembly.</li><br />
<li>Fully integrate MoveIt into robotic control stack for autonomous alignment.</li><br />
<li>Refine end-effector precision and truss fabrication for large-scale repeatability.</li><br />
</ul><br />
<br />
<h2>Additional Information</h2><br />
<br />
* Project Lead: [[User:Acmattson3|Andrew Mattson]], UAF CS BS/MS student<br />
* Faculty Advisor: [[User:Lawlor|Dr. Orion Lawlor]] (oslawlor@alaska.edu)<br />
* Team Members:<br />
** [[User:Frozenstiff|Elliott Madsen]] (ME BS)<br />
** Delano Horner (ME BS)<br />
** Daniel Schliesing (ME BS)<br />
** Kory Lamme (ME BS)</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=File:X-Hab_LUNATIC_Software_Stack.png&diff=807File:X-Hab LUNATIC Software Stack.png2025-07-07T22:12:56Z<p>Acmattson3: </p>
<hr />
<div>The modified LUNATIC software stack for the 2025 X-Hab project.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUNATIC&diff=806LUNATIC2025-07-07T22:09:04Z<p>Acmattson3: Added software stack diagram.</p>
<hr />
<div>== LUNATIC Software Stack ==<br />
Visit the [https://github.com/auroraRoboticsLab/MiningRobot MiningRobot GitHub repository] for more detailed information.<br />
[[File:Autonomy stack full.png|alt=The full LUNATIC autonomy stack diagram.|thumb|The full LUNATIC autonomy stack diagram.]]<br />
The '''"Logically UNcoupled Architecture Technology for Intra-robot Communication" or LUNATIC''' (pronounced lun-AT-ic, like automatic) is our robot control system, built as a loosely coupled set of microservices. LUNATIC is currently the software responsible for controlling the [[Excahauler]] robot.<br />
The <code>autonomy/</code> directory (in the project [https://github.com/auroraRoboticsLab/MiningRobot Github repository]) contains our robot control stack, written in '''C++''' for Linux and running happily on x86 and ARM based robots including the Raspberry Pi or NVIDIA Jetson. See [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/README.txt the README in that directory] for build directions.<br />
<br />
Using microservices means you can compile, run, and test a single service independently, unlike our previous single monolithic executable the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/backend/main.cpp backend].<br />
<br />
Due to the nature of a robotics control stack, being able to efficiently exchange quickly changing data between modules is crucial. We do this using the new MMAP-based shared file data exchange system, the details of which can be found in the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/include/aurora/data_exchange.h data_exchange.h] header.<br />
<br />
The data being exchanged is listed in the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/include/aurora/lunatic.h lunatic.h] header for the microservices, and [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/nanoslot/include/nanoslot/nanoslot_exchange.h nanoslot_exchange.h] for the Arduino data.<br />
<br />
== Control Software Stack ==<br />
A basic manual control setup has autonomy/frontend running on the "pilot" machine, and sending commands to the autonomy/backend running onboard the robot. These commands are sent via UDP broadcast, so they should work anywhere on the same subnet. The backend talks to the Arduinos directly via USB--each Arduino has a "nanoslot ID" that lets nanoboot connect the appropriate slot program to communicate with it. To control the robot, all you need is a backend and the slot programs: put the backend into "backend driver" state, and use WASD to drive the robot.<br />
For autonomous robot operations, we rely on a huge variety of microservices, such as the localizer (where is the robot?), path planner (how do we get to the target?), andretti (how do we drive along the path?), vision (what obstacles can we see?), and several other debug tools.<br />
<br />
This architecture has been incrementally built up since 2013 by a variety of UAF students for the [[Project Archives|NASA Robotic Mining Contest]]. Unless otherwise noted, everything here is public domain.<br />
<br />
== Get Involved ==<br />
For details on how build and run this software, see [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/README.txt autonomy/README]. Send a pull request or [[User:Lawlor|contact me (Dr. Orion Lawlor)]] if you have comments or suggestions!</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=File:Autonomy_stack_full.png&diff=805File:Autonomy stack full.png2025-07-07T22:07:11Z<p>Acmattson3: </p>
<hr />
<div>The full LUNATIC autonomy stack diagram</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Excahauler&diff=804Excahauler2025-07-07T22:02:22Z<p>Acmattson3: </p>
<hr />
<div><h1>Excahauler Mining Robot</h1><br />
[[File:Team-with-excahauler.jpg|alt=The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.|thumb|The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.]]<br />
<p>The <strong>Excahauler</strong> is an autonomous mining robot built for [[Project Archives|NASA's Break the Ice Challenge]] using a combination of welded steel and 3D printed parts. Designed to handle excavation and mining tasks in challenging environments, featuring robust construction and adaptable components. [https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor Here is a YouTube video] of Excahauler in action mining a block of concrete.</p><br />
<br />
<h2>Components</h2><br />
<br />
<h3>Frame</h3><br />
[[File:Excahauler sideview.png|alt=A sideview of the Excahauler robot.|thumb|A sideview of the Excahauler robot.]]<br />
<p>The base of the robot consists of a welded steel frame made from 1-inch (25mm) steel box tubing. The front wheels attach directly to the frame for stability, while the middle and rear wheels are mounted on a rocker system to adapt to uneven terrain. The electronics box, front fork, and arm boom are also bolted directly onto the frame.</p><br />
<br />
<h3>Robot Arm</h3><br />
<p>The robot arm has two main links:</p><br />
<ul><br />
<li><strong>Boom:</strong> Connects to the frame, providing front-to-back motion. It is aligned with an inertial measurement unit mounted on an angled bar.</li><br />
<li><strong>Stick:</strong> The stick, following excavator naming conventions, has an Intel RealSense D455 depth camera mounted on top and a small electronics box for motor controllers.</li><br />
</ul><br />
<br />
<h3>Tool Coupler</h3><br />
<p>The tool coupler allows for quick tool changes using a two-pin system similar to an excavator's quick-change setup. It includes a locking mechanism to secure tools in place, allowing the robot to switch between different excavation tools efficiently.</p><br />
<br />
<h3>Excavation Tools</h3><br />
<p>The robot can use various excavation tools, with the primary tool being a rock grinder. This tool spins a drum to mill material directly into the front scoop. The large ammo can on the robot houses the batteries, motor controller, and space for cooling oil.</p><br />
<br />
<h3>Front Scoop</h3><br />
<p>The front scoop has a volume of 50 liters, allowing it to carry a payload of approximately 50 kg of broken-up material. It features a fork linear actuator for raising and lowering relative to the frame and a dump actuator for tilting the scoop to unload material.</p><br />
<br />
<h2>Software</h2><br />
[[File:Excahauler Frame.jpg|alt=Excahauler's bare frame, with a colored axis label at the center. |thumb|Excahauler's bare frame, with a colored axis label at the center. Red is X, yellow is Y, and blue is Z.]]<br />
<p>Excahauler uses the [[LUNATIC]] software stack, as seen on [https://github.com/auroraRoboticsLab/MiningRobot its GitHub repository].</p><br />
<p>The robot follows a right-handed coordinate system:</p><br />
<ul><br />
<li>+Y is forward</li><br />
<li>+X is to the robot's right</li><br />
<li>+Z is up</li><br />
</ul><br />
<p>Some components use rotated coordinate systems to align with the mounted sensors.</p><br />
<br />
<h2>Development</h2><br />
<p>The Excahauler is an ongoing project aimed at advancing autonomous mining technologies. The robot's design and functionality continue to be refined based on testing and research. Its design is a major influence toward [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate designs.</p><br />
<br />
<h2>Further Information</h2><br />
<p>For more details on the robot's design and development, visit the project's [https://github.com/auroraroboticslab/excahauler GitHub page].</p><br />
<br />
<p>For questions or suggestions, please contact lawlor@alaska.edu.</p><br />
<br />
<p><em>Note: Unless specified otherwise, the source code files are released to the public domain.</em></p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUNATIC&diff=803LUNATIC2025-07-07T22:01:39Z<p>Acmattson3: Created page with "== LUNATIC Software Stack == Visit the [https://github.com/auroraRoboticsLab/MiningRobot MiningRobot GitHub repository] for more detailed information. The '''"Logically UNcoupled Architecture Technology for Intra-robot Communication" or LUNATIC''' (pronounced lun-AT-ic, like automatic) is our robot control system, built as a loosely coupled set of microservices. LUNATIC is currently the software responsible for controlling the Excahauler robot. The <code>autonomy/</..."</p>
<hr />
<div>== LUNATIC Software Stack ==<br />
Visit the [https://github.com/auroraRoboticsLab/MiningRobot MiningRobot GitHub repository] for more detailed information.<br />
<br />
The '''"Logically UNcoupled Architecture Technology for Intra-robot Communication" or LUNATIC''' (pronounced lun-AT-ic, like automatic) is our robot control system, built as a loosely coupled set of microservices. LUNATIC is currently the software responsible for controlling the [[Excahauler]] robot.<br />
The <code>autonomy/</code> directory (in the project [https://github.com/auroraRoboticsLab/MiningRobot Github repository]) contains our robot control stack, written in '''C++''' for Linux and running happily on x86 and ARM based robots including the Raspberry Pi or NVIDIA Jetson. See [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/README.txt the README in that directory] for build directions.<br />
<br />
Using microservices means you can compile, run, and test a single service independently, unlike our previous single monolithic executable the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/backend/main.cpp backend].<br />
<br />
Due to the nature of a robotics control stack, being able to efficiently exchange quickly changing data between modules is crucial. We do this using the new MMAP-based shared file data exchange system, the details of which can be found in the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/include/aurora/data_exchange.h data_exchange.h] header.<br />
<br />
The data being exchanged is listed in the [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/include/aurora/lunatic.h lunatic.h] header for the microservices, and [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/nanoslot/include/nanoslot/nanoslot_exchange.h nanoslot_exchange.h] for the Arduino data.<br />
<br />
== Control Software Stack ==<br />
A basic manual control setup has autonomy/frontend running on the "pilot" machine, and sending commands to the autonomy/backend running onboard the robot. These commands are sent via UDP broadcast, so they should work anywhere on the same subnet. The backend talks to the Arduinos directly via USB--each Arduino has a "nanoslot ID" that lets nanoboot connect the appropriate slot program to communicate with it. To control the robot, all you need is a backend and the slot programs: put the backend into "backend driver" state, and use WASD to drive the robot.<br />
For autonomous robot operations, we rely on a huge variety of microservices, such as the localizer (where is the robot?), path planner (how do we get to the target?), andretti (how do we drive along the path?), vision (what obstacles can we see?), and several other debug tools.<br />
<br />
This architecture has been incrementally built up since 2013 by a variety of UAF students for the [[Project Archives|NASA Robotic Mining Contest]]. Unless otherwise noted, everything here is public domain.<br />
<br />
== Get Involved ==<br />
For details on how build and run this software, see [https://github.com/AuroraRoboticsLab/MiningRobot/blob/master/autonomy/README.txt autonomy/README]. Send a pull request or [[User:Lawlor|contact me (Dr. Orion Lawlor)]] if you have comments or suggestions!</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=802LUMINSim2025-07-07T21:50:06Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings and how to get started with development.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It currently serves as a tool for testing and refining robots and their operations in a simulated lunar environment. We aim to make LUMINSim a commercially available product (see [[LUMINSim#Current Status and Development|Current Status and Development]]) to assist us in research and testing.<br />
<br />
<p>LUMINSim allows us to test new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates. [[Astra]] was the first [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate, but LUMINSim helped us identify fundamental flaws in its design.</p><br />
<br />
<h2>Features</h2><br />
<br />
<ul><br />
<li>Playable characters:<br />
<ul><br />
<li>The [[L.A.M.P: Lunar, Autonomous, Modular Platform|<strong>LAMP&nbsp;v1</strong> (Astra)]] rover</li><br />
<li><strong>[[Excahauler]]</strong> (in progress; no fork/dump yet)</li><br />
<li>Procedurally animated <strong>astronaut</strong> character</li><br />
</ul><br />
</li><br />
<li><strong>Deformable lunar terrain</strong> based on NASA height‑map data, with excavation and dirtball re‑merging.</li><br />
<li><strong>Modular tool attachments</strong> (bucket, forks, saw blade) connected via a ToolCoupler.</li><br />
<li><strong>Power system</strong> featuring rechargeable batteries, charging stations, and solar panels.</li><br />
<li><strong>Multiplayer networking</strong> with host/join menus and synchronized objects.</li><br />
<li>User interface with rebindable controls, on‑screen joystick support, and FPS display.</li><br />
<li>Utility scenes such as a brick maker, tool spawner, and dirt spawner.</li><br />
<li>First‑person, third‑person, and spectator free‑camera modes.</li><br />
</ul><h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage. Ongoing development is aimed at developing LUMINSim into a commercial product available on Steam and on the web. The current idea is to have players join to develop their own lunar zones and compete in challenges that assist us in our research. LUMINSim will also continue to serve as a testbed for validating new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and other lunar technologies, especially as users test each candidate's limits.</p><br />
<br />
<p>For more information on the status of LUMINSim's development, see the [[LUMINSim Documentation|LUMINSim Documentation page]].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=801LUMINSim2025-07-07T21:44:47Z<p>Acmattson3: Updated features list.</p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings and how to get started with development.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It currently serves as a tool for testing and refining robots and their operations in a simulated lunar environment. We aim to make LUMINSim a commercially available product (see [[LUMINSim#Current Status and Development|Current Status and Development]]) to assist us in research and testing.<br />
<br />
<p>LUMINSim allows us to test new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates. [[Astra]] was the first [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate, but LUMINSim helped us identify fundamental flaws in its design.</p><br />
<br />
<h2>Features</h2><br />
<br />
<ul><br />
<li>Playable characters:<br />
<ul><br />
<li>The [[L.A.M.P: Lunar, Autonomous, Modular Platform|<strong>LAMP&nbsp;v1</strong> (Astra)]] rover</li><br />
<li>Early <strong>[[Excahauler]]</strong> prototype</li><br />
<li>Procedurally animated <strong>astronaut</strong> character</li><br />
</ul><br />
</li><br />
<li><strong>Deformable lunar terrain</strong> based on NASA height‑map data, with excavation and dirtball re‑merging.</li><br />
<li><strong>Modular tool attachments</strong> (bucket, forks, saw blade) connected via a ToolCoupler.</li><br />
<li><strong>Power system</strong> featuring rechargeable batteries, charging stations, and solar panels.</li><br />
<li><strong>Multiplayer networking</strong> with host/join menus and synchronized objects.</li><br />
<li>User interface with rebindable controls, on‑screen joystick support, and FPS display.</li><br />
<li>Utility scenes such as a brick maker, tool spawner, and dirt spawner.</li><br />
<li>First‑person, third‑person, and spectator free‑camera modes.</li><br />
</ul><h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage. Ongoing development is aimed at developing LUMINSim into a commercial product available on Steam and on the web. The current idea is to have players join to develop their own lunar zones and compete in challenges that assist us in our research. LUMINSim will also continue to serve as a testbed for validating new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and other lunar technologies, especially as users test each candidate's limits.</p><br />
<br />
<p>For more information on the status of LUMINSim's development, see the [[LUMINSim Documentation|LUMINSim Documentation page]].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=800LUMINSim2025-07-07T21:43:54Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings and how to get started with development.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It currently serves as a tool for testing and refining robots and their operations in a simulated lunar environment. We aim to make LUMINSim a commercially available product (see [[LUMINSim#Current Status and Development|Current Status and Development]]) to assist us in research and testing.<br />
<br />
<p>LUMINSim allows us to test new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates. [[Astra]] was the first [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate, but LUMINSim helped us identify fundamental flaws in its design.</p><br />
<br />
<h2>Features</h2><br />
<br />
<ul><br />
<li>Playable characters:<br />
<ul><br />
<li>The <strong>LAMP&nbsp;v1</strong> (Astra) rover</li><br />
<li>Early <strong>Excahauler</strong> prototype</li><br />
<li>Procedurally animated <strong>astronaut</strong> character</li><br />
</ul><br />
</li><br />
<li><strong>Deformable lunar terrain</strong> based on NASA height‑map data, with excavation and dirtball re‑merging.</li><br />
<li><strong>Modular tool attachments</strong> (bucket, forks, saw blade) connected via a ToolCoupler.</li><br />
<li><strong>Power system</strong> featuring rechargeable batteries, charging stations, and solar panels.</li><br />
<li><strong>Multiplayer networking</strong> with host/join menus and synchronized objects.</li><br />
<li>User interface with rebindable controls, on‑screen joystick support, and FPS display.</li><br />
<li>Utility scenes such as a brick maker, tool spawner, and dirt spawner.</li><br />
<li>First‑person, third‑person, and spectator free‑camera modes.</li><br />
</ul><br />
<br />
The simulator currently features the [[LAMP v1|Astra]] and [[Excahauler]] robots and an astronaut character, deformable terrain, modular robotic tool attachments (including a bucket, forks, and a sawblade), a power system, and equipment like a cinderblock maker, tool attachment spawner, and robot charging station.<h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage. Ongoing development is aimed at developing LUMINSim into a commercial product available on Steam and on the web. The current idea is to have players join to develop their own lunar zones and compete in challenges that assist us in our research. LUMINSim will also continue to serve as a testbed for validating new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and other lunar technologies, especially as users test each candidate's limits.</p><br />
<br />
<p>For more information on the status of LUMINSim's development, see the [[LUMINSim Documentation|LUMINSim Documentation page]].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=799LUMINSim2025-07-05T22:16:32Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings and how to get started with development.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It currently serves as a tool for testing and refining robots and their operations in a simulated lunar environment. We aim to make LUMINSim a commercially available product (see [[LUMINSim#Current Status and Development|Current Status and Development]]) to assist us in research and testing.<br />
<br />
<p>LUMINSim allows us to test new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates. [[Astra]] was the first [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate, but LUMINSim helped us identify fundamental flaws in its design.</p><br />
<br />
<h2>Features</h2><br />
<br />
The simulator currently features the [[LAMP v1|Astra]] and [[Excahauler]] robots and an astronaut character, deformable terrain, modular robotic tool attachments (including a bucket, forks, and a sawblade), a power system, and equipment like a cinderblock maker, tool attachment spawner, and robot charging station.<h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage. Ongoing development is aimed at developing LUMINSim into a commercial product available on Steam and on the web. The current idea is to have players join to develop their own lunar zones and compete in challenges that assist us in our research. LUMINSim will also continue to serve as a testbed for validating new [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidates and other lunar technologies, especially as users test each candidate's limits.</p><br />
<br />
<p>For more information on the status of LUMINSim's development, see the [[LUMINSim Documentation|LUMINSim Documentation page]].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=798LUMINSim Documentation2025-07-05T22:09:57Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add:<br />
<br />
* A list of the non-default classes/nodes this project declares.<br />
* In-depth descriptions of the inner workings of each major system, including:<br />
** Power<br />
** Tools and tool swapping<br />
** Terrain<br />
** Multiplayer<br />
** Each user-controlled scene (robots and astronaut)<br />
** The UI (multiplayer menu, settings menu, keybind menu)<br />
** Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there to get the project set up. <br />
<br />
== Repository Structure ==<br />
<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LAMP v1|Astra]] robot. See [[LUMINSim Documentation#Astra Robot|Astra Robot]].<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See Components.<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky). <br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the ''dynamic'' (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the ''static'' (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions are likely to be replaced with a more developer-friendly system, likely one that downloads terrain from a separate server that handles all terrain logic.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps, creates render and collision geometry.<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> simulates excavation, landslides, and merging dirtballs back into the heightmap.<br />
<br />
== Terrain Tools ==<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Robot Systems ==<br />
<br />
=== Astra Robot ===<br />
The primary scene file is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving and energy usage, as well as tool attachment. Works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> for arm/hopper actuation. See [[LUMINSim Documentation#Arm and Hopper|Arm and Hopper]].<br />
<br />
=== Arm and Hopper ===<br />
Separate nodes controlled by <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> for the arm and hopper implement joint movement. <br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally (i.e., code-driven) animated astronaut player avatar.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend the node class <code>ToolAttachment</code> for various tasks.<br />
<br />
=== Excahauler Robot ===<br />
WIP.<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools.<br />
<br />
== Networking and Multiplayer ==<br />
<code>GameManager.gd</code> manages synchronized player/object data and signals for network updates.<br />
<br />
<code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
WIP.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third‑person.<br />
<br />
The user interface (<code>ui.gd</code>, <code>joystick.gd</code>, <code>keybinds_menu.gd</code>) provides HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous scripts such as <code>fps_counter.gd</code> and <code>multiplayer_menu.gd</code> assist with debugging and multiplayer session management.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=797LUMINSim2025-07-05T00:03:31Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p><strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It serves as a tool for testing and refining robots and their operations in a simulated lunar environment, directly supporting the overarching <strong>[[LUMIN]]</strong> control system. The simulation focuses on the challenges of mining, construction, and other infrastructure tasks essential for future lunar exploration.</p><br />
<p>'''Developers:''' Visit [[LUMINSim Documentation]] for more detailed information about LUMINSim's inner workings.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<p>LUMINSim aims to be a detailed simulation environment for lunar mining operations. As part of the broader [[LUMIN]] system, it allows the team to model various robotic designs, navigation algorithms, and task execution methods under realistic lunar conditions. The simulator currently features the <strong>[[LAMP v1|Astra]]</strong> robot, the first prototype designed for lunar construction and mining.</p><br />
<br />
<p>The insights gained from LUMINSim's testing of Astra led to the development of a new, more versatile robot called <strong>[[LAMP]] (Lunar, Autonomous, Modular, Platform)</strong>. Astra’s limitations and inadequacies identified in LUMINSim directly informed the modular design philosophy of LAMP, highlighting the simulator's crucial role in advancing lunar robotic platforms.</p><br />
<br />
<h2>Features</h2><br />
<br />
<p>Key features of LUMINSim include:</p><br />
<ul><br />
<li><strong>Terrain Simulation:</strong> Realistic lunar terrain with adjustable parameters. The terrain colliders match the mesh, providing an accurate physical environment for robotic interactions. Terrain texture and lighting are enhanced for greater visual fidelity and accuracy.</li><br />
<li><strong>Autonomous Robot Control:</strong> Users can control mining robots, including the Astra prototype, in both autonomous and manual modes. Features include an in-game console for issuing commands, camera controls, and freecam mode for navigation and inspection.</li><br />
<li><strong>Robot Design Testing:</strong> One of LUMINSim's primary purposes is to test and validate new robotic designs. Astra, the current robot in the simulator, serves as a learning tool that guided the development of LAMP by exposing design flaws and providing insight into necessary features for lunar operations.</li><br />
<li><strong>Multi-Platform Support:</strong> Supports multiple platforms, including desktop and Android, providing a versatile simulation environment for different users and use cases.</li><br />
<li><strong>Immersive Astronaut Simulation:</strong> Allows users to control an astronaut avatar within the simulation.</li><br />
<li><strong>Modular Design:</strong> The modular approach supports the addition of new features, robots, terrains, and missions, aligning with LAMP's design philosophy and the adaptive nature of the LUMIN control system.</li><br />
<li><strong>Console Commands and UI Controls:</strong> Includes various user commands and UI elements, such as speed readouts and simulation rate adjustments to enhance the simulation experience.</li><br />
</ul><br />
<br />
<h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage, with ongoing development aimed at refining robot behavior, terrain interactions, and autonomous capabilities. The latest updates focus on improving terrain generation, enhancing the control of the Astra robot, and introducing new elements such as mountable lights, speed controls, and navigation systems.</p><br />
<br />
<p>Although Astra is the only robot currently in the simulator, its design serves as a foundation for the ongoing development of LAMP. LUMINSim continues to be an essential testbed for validating new designs and technologies before their implementation in actual lunar operations.</p><br />
<br />
<h2>Related Projects</h2><br />
<br />
<ul><br />
<li>[[LAMP]] (Lunar, Autonomous, Modular, Platform) - The next-generation robot designed based on the lessons learned from testing Astra in LUMINSim.</li><br />
<li>[[LUMIN]] (Lunar Mining and Infrastructure Network) - The overarching control software that manages various lunar operations, using LUMINSim as its primary simulation environment for testing and development.</li><br />
</ul><br />
<br />
<h2>How to Get Involved</h2><br />
<br />
<p>The Aurora Robotics Team welcomes collaboration with students and researchers interested in lunar robotics, simulation, and autonomous systems. For more details on LUMINSim or to contribute to its development, please visit our [https://github.com/auroraroboticslab/godotrobot/ GitHub repository].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=796LUMINSim Documentation2025-07-04T23:53:02Z<p>Acmattson3: </p>
<hr />
<div>= LUMINSim Documentation =<br />
This is an ongoing page as I ([[User:Acmattson3|Andrew Mattson]]) document [[LUMINSim]]'s current systems. This page is a ''major'' work in progress; feel free to add to it!<br />
<br />
Going forward, I hope to add:<br />
<br />
* A list of the non-default classes/nodes this project declares.<br />
* In-depth descriptions of the inner workings of each major system, including:<br />
** Power<br />
** Tools and tool swapping<br />
** Terrain<br />
** Multiplayer<br />
** Each user-controlled scene (robots and astronaut)<br />
** The UI (multiplayer menu, settings menu, keybind menu)<br />
** Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there.<br />
<br />
== Repository Structure ==<br />
<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>project.godot</code>''' – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LAMP v1|Astra]] robot. See [[LUMINSim Documentation#Astra Robot|Astra Robot]].<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See Components.<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky). <br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different lunar landers. Landers are currently just static models.<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the ''dynamic'' (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the ''static'' (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI as well as other useful scripts. See [[LUMINSim Documentation#User Interface|User Interface]] and [[LUMINSim Documentation#Additional Utilities|Additional Utilities]].<br />
In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions are likely to be replaced with a more developer-friendly system, likely one that downloads terrain from a separate server that handles all terrain logic.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps, creates render and collision geometry.<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> simulates excavation, landslides, and merging dirtballs back into the heightmap.<br />
<br />
== Terrain Tools ==<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain.<br />
<br />
== Robot Systems ==<br />
<br />
=== Astra Robot ===<br />
The primary scene file is <code>astra_3d.tscn</code>. <code>astra_3d.gd</code> handles driving and energy usage, as well as tool attachment. Works with <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> for arm/hopper actuation. See [[LUMINSim Documentation#Arm and Hopper|Arm and Hopper]].<br />
<br />
=== Arm and Hopper ===<br />
Separate nodes controlled by <code>astra_arm_3d.gd</code> and <code>astra_hopper_3d.gd</code> for the arm and hopper implement joint movement. <br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a procedurally (i.e., code-driven) animated astronaut player avatar.<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend the node class <code>ToolAttachment</code> for various tasks.<br />
<br />
=== Excahauler Robot ===<br />
WIP.<br />
<br />
== Objects ==<br />
WIP.<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools.<br />
<br />
== Networking and Multiplayer ==<br />
<code>GameManager.gd</code> manages synchronized player/object data and signals for network updates.<br />
<br />
<code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects.<br />
<br />
== User Interface ==<br />
WIP.<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third‑person.<br />
<br />
The user interface (<code>ui.gd</code>, <code>joystick.gd</code>, <code>keybinds_menu.gd</code>) provides HUD elements, customizable input bindings, and optional on-screen controls for mobile users.<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop.<br />
<br />
== Additional Utilities ==<br />
Miscellaneous scripts such as <code>fps_counter.gd</code> and <code>multiplayer_menu.gd</code> assist with debugging and multiplayer session management.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=795LUMINSim Documentation2025-07-04T23:34:00Z<p>Acmattson3: </p>
<hr />
<div>== LUMINSim Documentation ==<br />
This is an ongoing page as I document [[LUMINSim]]'s current systems. Feel free to add to it!<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there.<br />
<br />
== Repository Structure ==<br />
<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems.<br />
** '''<code>export_presets.cfg</code>''' – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.<br />
** '''<code>game_manager.gd</code>''' – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See [[LUMINSim Documentation#Networking and Multiplayer|Networking and Multiplayer]].<br />
** '''<code>demo/astra</code>''' – Files pertaining to the drivable [[LAMP v1|Astra]] robot. See [[LUMINSim Documentation#Astra Robot|Astra Robot]].<br />
** '''<code>demo/astronaut</code>''' – Files pertaining to the in-game, procedurally-animated astronaut character. See [[LUMINSim Documentation#Astronaut Character|Astronaut Character]].<br />
** '''<code>demo/bin</code>''' – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/components</code>''' – Contains components or component-like scenes and related files. See Components.<br />
** '''<code>demo/environment</code>''' – Files for the skybox (i.e., the stars in the sky). <br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/graphics</code>''' – Contains many images for icons and textures, especially for the user interface. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
** '''<code>demo/landers</code>''' – Contains directories for different (currently, static models of) lunar landers.<br />
** '''<code>demo/excahauler</code>''' – Files pertaining to the drivable [[Excahauler]] robot. See [[LUMINSim Documentation#Excahauler Robot|Excahauler Robot]].<br />
** '''<code>demo/levels</code>''' – Contains the main playable (i.e., non-UI) scenes and related files. See [[LUMINSim Documentation#Levels|Levels]].<br />
** '''<code>demo/objects</code>''' – Contains non-static (i.e., movable RigidBody3D) objects. See [[LUMINSim Documentation#Objects|Objects]].<br />
** '''<code>demo/static_objects</code>''' – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See [[LUMINSim Documentation#Static Objects|Static Objects]].<br />
** '''<code>demo/terrain</code>''' – Scenes and files pertaining to the ''dynamic'' (i.e., mineable) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/terrain_fixed</code>''' – Scenes and files pertaining to the ''static'' (i.e., unchanging) terrain. See [[LUMINSim Documentation#Terrain System (C++)|Terrain System (C++)]].<br />
** '''<code>demo/util</code>''' – Scenes and files pertaining to UI. See [[LUMINSim Documentation#User Interface|User Interface]].<br />
<br />
== Terrain System (C++) ==<br />
C++ based GDExtensions are likely to be replaced with a more developer-friendly system, likely one that downloads terrain from a separate server that handles all terrain logic.<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps, creates render and collision geometry<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> simulates excavation, landslides, and merging dirtballs back into the heightmap<br />
<br />
== Terrain Tools ==<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain<br />
<br />
== Robot Systems ==<br />
<br />
=== Astra Robot ===<br />
<code>astra_3d.gd</code> handles driving, energy usage, and tool attachments for the primary rover<br />
<br />
=== Arm and Hopper ===<br />
Separate nodes for the arm and hopper implement joint movement and excavation logic<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a player avatar<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend <code>ToolAttachment</code> for various tasks<br />
<br />
=== Excahauler Robot ===<br />
WIP<br />
<br />
== Objects ==<br />
WIP<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools<br />
<br />
== Networking and Multiplayer ==<br />
<code>GameManager.gd</code> manages synchronized player/object data and signals for network updates<br />
<br />
<code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects<br />
<br />
== User Interface ==<br />
WIP<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third‑person<br />
<br />
The user interface (<code>ui.gd</code>, <code>joystick.gd</code>, <code>keybinds_menu.gd</code>) provides HUD elements, customizable input bindings, and optional on-screen controls for mobile users<br />
<br />
== Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop<br />
<br />
== Additional Utilities ==<br />
Miscellaneous scripts such as <code>fps_counter.gd</code> and <code>multiplayer_menu.gd</code> assist with debugging and session management<br />
<br />
== Building the Extension ==<br />
The <code>SConstruct</code> file compiles all <code>.cpp</code> sources into a shared library used by the Godot projec</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=794LUMINSim Documentation2025-07-04T23:05:46Z<p>Acmattson3: AI template (to be updated)</p>
<hr />
<div>== LUMINSim Documentation ==<br />
This is an ongoing page as I document [[LUMINSim]]'s current systems. Feel free to add to it!<br />
<br />
== Getting Started ==<br />
To learn how to get started with development yourself, [https://github.com/AuroraRoboticsLab/GodotRobot/blob/main/README.md visit the repository's README] and follow the steps there.<br />
<br />
== Repository Structure ==<br />
<br />
* '''<code>src/</code>''' – C++ GDExtension code for terrain and registration<br />
<br />
* '''<code>demo/</code>''' – Godot project containing levels, assets, and GDScript systems<br />
<br />
== Terrain System (C++) ==<br />
<br />
=== Static Terrain ===<br />
<code>TerrainStatic256</code> loads heightmaps, creates render and collision geometry<br />
<br />
=== Dynamic Terrain ===<br />
<code>TerrainSim</code> simulates excavation, landslides, and merging dirtballs back into the heightmap<br />
<br />
== Terrain Tools ==<br />
Scripts such as <code>dirt_spawner.gd</code> and <code>dirtball.gd</code> spawn and merge mobile particles with the dynamic terrain<br />
<br />
== Robot Systems ==<br />
<br />
=== Astra Rover ===<br />
<code>astra_3d.gd</code> handles driving, energy usage, and tool attachments for the primary rover<br />
<br />
=== Arm and Hopper ===<br />
Separate nodes for the arm and hopper implement joint movement and excavation logic<br />
<br />
=== Astronaut Character ===<br />
<code>astronaut_character_3d.gd</code> provides walking and camera control for a player avatar<br />
<br />
=== Excavation Tools ===<br />
Attachments such as the bucket, forks, and saw blade extend <code>ToolAttachment</code> for various tasks<br />
<br />
== Static Objects ==<br />
Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools<br />
<br />
== Networking and Multiplayer ==<br />
<code>GameManager.gd</code> manages synchronized player/object data and signals for network updates<br />
<br />
<code>multiplayer_menu.gd</code> lets players host or join games, start sessions, and handle disconnects<br />
<br />
== Cameras and Controls ==<br />
<code>movable_camera_3d.gd</code> and <code>freecam.gd</code> implement user-controlled cameras, both first- and third‑person<br />
<br />
The user interface (<code>ui.gd</code>, <code>joystick.gd</code>, <code>keybinds_menu.gd</code>) provides HUD elements, customizable input bindings, and optional on-screen controls for mobile users<br />
<br />
== Example Levels ==<br />
Scenes in <code>demo/levels/</code> (e.g., <code>main3D.tscn</code> with script <code>main3D.gd</code>) instantiate players, objects, and the terrain simulator, driving the overall game loop<br />
<br />
== Additional Utilities ==<br />
Miscellaneous scripts such as <code>fps_counter.gd</code> and <code>multiplayer_menu.gd</code> assist with debugging and session management<br />
<br />
== Building the Extension ==<br />
The <code>SConstruct</code> file compiles all <code>.cpp</code> sources into a shared library used by the Godot projec</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=793LUMINSim Documentation2025-07-04T22:43:19Z<p>Acmattson3: </p>
<hr />
<div>== LUMINSim Documentation ==<br />
This is an ongoing page as I document [[LUMINSim]]'s current systems.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim_Documentation&diff=792LUMINSim Documentation2025-07-04T22:42:01Z<p>Acmattson3: Created page with "== LUMINSim Documentation == This is an ongoing page as I document LUMINSim's current systems."</p>
<hr />
<div>== LUMINSim Documentation ==<br />
This is an ongoing page as I document LUMINSim's current systems.</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Excahauler&diff=791Excahauler2025-07-04T21:39:30Z<p>Acmattson3: </p>
<hr />
<div><h1>Excahauler Mining Robot</h1><br />
[[File:Team-with-excahauler.jpg|alt=The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.|thumb|The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.]]<br />
<p>The <strong>Excahauler</strong> is an autonomous mining robot built for [[Project Archives|NASA's Break the Ice Challenge]] using a combination of welded steel and 3D printed parts. Designed to handle excavation and mining tasks in challenging environments, featuring robust construction and adaptable components. [https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor Here is a YouTube video] of Excahauler in action mining a block of concrete.</p><br />
<br />
<h2>Robot Components</h2><br />
<br />
<h3>Frame</h3><br />
[[File:Excahauler sideview.png|alt=A sideview of the Excahauler robot.|thumb|A sideview of the Excahauler robot.]]<br />
<p>The base of the robot consists of a welded steel frame made from 1-inch (25mm) steel box tubing. The front wheels attach directly to the frame for stability, while the middle and rear wheels are mounted on a rocker system to adapt to uneven terrain. The electronics box, front fork, and arm boom are also bolted directly onto the frame.</p><br />
<br />
<h3>Robot Arm</h3><br />
<p>The robot arm has two main links:</p><br />
<ul><br />
<li><strong>Boom:</strong> Connects to the frame, providing front-to-back motion. It is aligned with an inertial measurement unit mounted on an angled bar.</li><br />
<li><strong>Stick:</strong> The stick, following excavator naming conventions, has an Intel RealSense D455 depth camera mounted on top and a small electronics box for motor controllers.</li><br />
</ul><br />
<br />
<h3>Tool Coupler</h3><br />
<p>The tool coupler allows for quick tool changes using a two-pin system similar to an excavator's quick-change setup. It includes a locking mechanism to secure tools in place, allowing the robot to switch between different excavation tools efficiently.</p><br />
<br />
<h3>Excavation Tools</h3><br />
<p>The robot can use various excavation tools, with the primary tool being a rock grinder. This tool spins a drum to mill material directly into the front scoop. The large ammo can on the robot houses the batteries, motor controller, and space for cooling oil.</p><br />
<br />
<h3>Front Scoop</h3><br />
<p>The front scoop has a volume of 50 liters, allowing it to carry a payload of approximately 50 kg of broken-up material. It features a fork linear actuator for raising and lowering relative to the frame and a dump actuator for tilting the scoop to unload material.</p><br />
<br />
<h2>Coordinate System</h2><br />
[[File:Excahauler Frame.jpg|alt=Excahauler's bare frame, with a colored axis label at the center. |thumb|Excahauler's bare frame, with a colored axis label at the center. Red is X, yellow is Y, and blue is Z.]]<br />
<p>The robot follows a right-handed coordinate system:</p><br />
<ul><br />
<li>+Y is forward</li><br />
<li>+X is to the robot's right</li><br />
<li>+Z is up</li><br />
</ul><br />
<p>Some components use rotated coordinate systems to align with the mounted sensors.</p><br />
<br />
<h2>Development</h2><br />
<p>The Excahauler is an ongoing project aimed at advancing autonomous mining technologies. The robot's design and functionality continue to be refined based on testing and research. Its design is a major influence toward [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate designs.</p><br />
<br />
<h2>Further Information</h2><br />
<p>For more details on the robot's design and development, visit the project's [https://github.com/auroraroboticslab/excahauler GitHub page].</p><br />
<br />
<p>For questions or suggestions, please contact lawlor@alaska.edu.</p><br />
<br />
<p><em>Note: Unless specified otherwise, the source code files are released to the public domain.</em></p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=NASA_X-Hab_2025:_Modular_Robotic_Construction&diff=790NASA X-Hab 2025: Modular Robotic Construction2025-07-04T21:37:40Z<p>Acmattson3: </p>
<hr />
<div>''This is a stub. You can help by expanding it.''<br />
<br />
<h2>Overview</h2><br />
[[File:Nasa xhab.jpg|thumb|NASA X-Hab Logo]]<br />
<br />
<p>In 2024, [https://spacegrant.org/wp-content/uploads/2024/03/M2M-X-Hab-Challenge-Solicitation-2025.pdf NASA's M2M X-Hab Academic Innovation Challenge for 2025] was released, for which [[Main Page|the Aurora Robotics Lab]] at the University of Alaska Fairbanks was accepted and funded through NASA’s 2024–2025 Moon to Mars X-Hab Academic Innovation Challenge. Our goal was to explore modular robotic construction techniques for lunar infrastructure, especially focusing on micrometeoroid-resistant arch structures made from modular steel trusses and covered in lunar regolith, with a clear path to fully autonomous robotic construction.</p><br />
<br />
<p>The project culminated in the development of the [[Excahauler|Excahauler robotic platform]] with a custom-built arm and end-effector, capable of aligning and assembling scaled modular truss components. Despite limitations in time and resources, the team demonstrated capabilities including truss manipulation, partial structural testing, and scale backfilling with regolith simulant (snow).</p><br />
<br />
<p>This wiki page is a very abridged version of our [https://docs.google.com/document/d/1N_494oalexJXKeGfjDocUZKAdBZPZ5RYqvyGjyIhMkg/edit?tab=t.0 full final report] which should soon be added to [https://ntrs.nasa.gov/ NASA's NTRS database].</p><br />
<br />
<h2>Project Vision and Mission</h2><br />
<ul><br />
<li><strong>Long-Term Vision:</strong> Transform the solar system using robotic construction with local materials.</li><br />
<li><strong>Short-Term Vision:</strong> Develop robotic infrastructure construction technologies for the Artemis Base Camp.</li><br />
<li><strong>Mission:</strong> Design and demonstrate robotic tools and modular structures capable of assembling scalable micrometeoroid-resistant lunar shelters.</li><br />
</ul><br />
<br />
<h2>The L-Truss System</h2><br />
[[File:L-Truss.jpg|alt=The final full-steel L-Truss design.|thumb|The final full-steel L-Truss design.]]<br />
<p>The primary structural innovation was the development of the <strong>L-Truss</strong>: A modular trapezoidal truss segment. These trusses connect via push-fit endplates and spring-loaded capture pins to form straight or curved assemblies, including arches and retaining walls. The final full-steel design used plasma-cut end plates with a 3D printed door latch-style connection. However, full robotic connection could not be demonstrated with this design, so we made some last minute changes. The final prototype design included:</p><br />
<ul><br />
<li>Hybrid steel construction with 3D printed carbon-fiber polycarbonate alignment funnels.</li><br />
<li>Spring-loaded pin latching mechanisms for tool-free robotic assembly.</li><br />
<li>Optional upright members for regolith support and buckling resistance.</li><br />
<li>Final tested form: 1.5m long, ~3kg, with a base angle of 22.5°.</li><br />
</ul><br />
<p>A scale 3D printable version is publicly available: [https://www.printables.com/model/1305834-trapezoidal-l-truss-clip-together-construction-mod L-Truss Model]</p><br />
<br />
<h2>Structure Requirements</h2><br />
<ul><br />
<li>Accommodate 2.6m x 2.6m vehicles within the constructed arch structure. (I.0)</li><br />
<li>Truss segments must remain under 2.0 meters for transport and robotic handling. (I.1.1)</li><br />
<li>Regolith shielding: Support ≥0.2m regolith equivalent for radiation/thermal protection. (O.0)</li><br />
<li>Minimum compressive load capacity of 300 kgf with ≥2.0 safety factor. (I.1.2, I.2.1)</li><br />
<li>Robot-compatible assembly path: all actions must have potential for automation. (E.0, E.2)</li><br />
</ul><br />
<br />
<h2>Concept of Operations</h2><br />
[[File:Arch Assembly Graphic.png|alt=A graphical representation of the truss section assembly process. |thumb|A graphical representation of the truss section assembly process. This is to be done in parallel with other truss sections (i.e., ones behind the one visible) to create a full truss structure.]]<br />
<h3>Lunar Deployment Plan</h3><br />
<ol><br />
<li><strong>Site Preparation:</strong> The Excahauler prepares a foundation using excavation tools.</li><br />
<li><strong>Truss Deployment:</strong> Trusses are unloaded from a logistics lander and staged for assembly.</li><br />
<li><strong>Structural Assembly:</strong> Robots assemble the arch structure according to the graphic on the right.</li><br />
<li><strong>Backfilling:</strong> Lunar regolith is put over the structure via ballistic throwing or traditional scooping.</li><br />
<li><strong>Use Phase:</strong> Covered arches serve as shielding for sensitive lunar equipment or crew.</li><br />
</ol><br />
<br />
<h3>Ground Demonstration Activities</h3><br />
<ul><br />
<li>1:10 scale arch model tested with regolith simulant (basalt dust).</li><br />
<li>Full-scale hybrid trusses fabricated and manipulated via teleoperation.</li><br />
<li>Robotic assembly verified using [[Excahauler]] and custom-built 2500:1 reducer gearbox arm.</li><br />
</ul><br />
<br />
<h2>Project Phases</h2><br />
<ol><br />
<li><strong>System Definition Review (SDR):</strong> October 4, 2024</li><br />
<li><strong>Preliminary Design Review (PDR):</strong> November 15, 2024</li><br />
<li><strong>Critical Design Review (CDR):</strong> January 24, 2025</li><br />
<li><strong>Progress Checkpoint Review (PCR):</strong> April 18, 2025</li><br />
<li><strong>Final Report:</strong> May 23, 2025</li><br />
</ol><br />
<br />
<h2>Robot System: [[Excahauler]]</h2><br />
<ul><br />
<li>Originally designed for the [[Project Archives|2022 NASA Break the Ice Challenge]].</li><br />
<li>Outfitted with a custom modular manipulator arm with 3D printed stepped planetary gearboxes.</li><br />
<li>Used in successful teleoperated tests to transport and align L-Truss segments.</li><br />
</ul><br />
<br />
<h2>Software and Simulation</h2><br />
<p>The team developed and tested robotic workflows using the following tools:</p><br />
<ul><br />
<li><strong>[[LUMINSim|Godot-based simulator:]]</strong> Visualized structure assembly and layout.</li><br />
<li><strong>[https://github.com/auroraRoboticsLab/MiningRobot?tab=readme-ov-file#lunatic Custom autonomy stack (LUNATIC):]</strong> Handles teleoperation, control, and vision.</li><br />
<li><strong>[https://docs.ros.org/en/humble/index.html ROS2] / [https://moveit.picknik.ai/main/index.html MoveIt]:</strong> Inverse kinematics modeled, full integration for automation incomplete.</li><br />
</ul><br />
<br />
<h2>Testing and Validation</h2><br />
<ul><br />
<li>FEM analysis showed safety factor >2.6 under 500N compressive loads.</li><br />
<li>Hybrid trusses withstood >500N axial loads; failure occurred at 230N in bending.</li><br />
<li>1/10 scale arch supported >12kg in Earth gravity, equivalent to 36+ tonnes in Mars gravity at full scale.</li><br />
</ul><br />
<br />
<h2>Educational Integration</h2><br />
<p>Project integrated into UAF's CS 493 (Fall) and CS 454 (Spring), providing hands-on systems engineering experience to undergraduates and graduate students in mechanical and computer science disciplines.</p><br />
<br />
<h2>Outreach Activities</h2><br />
<ul><br />
<li><strong>UAF Party in the Park:</strong> Public engagement event with live robot demos.</li><br />
<li><strong>FTC Robotics Tours:</strong> Guided tour for K–12 robotics students.</li><br />
<li><strong>UAF Engineering Open House:</strong> Structural demo and recruiting opportunity.</li><br />
</ul><br />
<br />
<h2>Lessons Learned</h2>We were not able to complete our promised deliverables to full satisfaction due to time constraints and lack of defined leadership structure. We learned important lessons about:<ul><br />
<li><strong>Structure:</strong> Even small teams benefit from defined leadership and task ownership.</li><br />
<li><strong>Planning:</strong> Conservative scoping ensures project deliverables can be met.</li><br />
<li><strong>Fabrication:</strong> Early design-for-manufacturing saves time and enables iteration.</li><br />
</ul><br />
<br />
<h2>Future Work</h2><br />
<ul><br />
<li>Complete full-scale robotic arch assembly.</li><br />
<li>Fully integrate MoveIt into robotic control stack for autonomous alignment.</li><br />
<li>Refine end-effector precision and truss fabrication for large-scale repeatability.</li><br />
</ul><br />
<br />
<h2>Additional Information</h2><br />
<br />
* Project Lead: [[User:Acmattson3|Andrew Mattson]], UAF CS BS/MS student<br />
* Faculty Advisor: [[User:Lawlor|Dr. Orion Lawlor]] (oslawlor@alaska.edu)<br />
* Team Members:<br />
** [[User:Frozenstiff|Elliott Madsen]] (ME BS)<br />
** Delano Horner (ME BS)<br />
** Daniel Schliesing (ME BS)<br />
** Kory Lamme (ME BS)</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=User:Lawlor&diff=789User:Lawlor2025-07-04T21:36:28Z<p>Acmattson3: </p>
<hr />
<div><h1>NOTICE</h1><br />
<p><strong>This page is largely generated by ChatGPT.</strong> Some information found here may be inaccurate until revised by Dr. Lawlor himself. </p><br />
<br />
<h1>Dr. Orion Sky Lawlor</h1><br />
<br />
<h2>Profile</h2><br />
<p>I am an Associate Professor of Computer Science at the [https://www.uaf.edu/uaf/ University of Alaska Fairbanks (UAF)]. My work focuses on robotics, computer graphics, and parallel computing. I use graphics hardware to accelerate simulations of physical phenomena, which has applications in high-performance computing, robotics, and industrial motion control.</p><p>[https://www.cs.uaf.edu/~olawlor/ See my main website here].</p><br />
<br />
<h2>Contact Information</h2><br />
<ul><br />
<li><strong>Email:</strong> lawlor@alaska.edu</li><br />
<li><strong>Office Phone:</strong> +1 907 474-7678</li><br />
<li><strong>Office:</strong> Duckering 535 or on Zoom: [https://alaska.zoom.us/j/9074747678 Join my Zoom Office Hours] (1-2 pm MWF)</li><br />
</ul><br />
<br />
<h2>Research Interests</h2><br />
<ul><br />
<li>Robotics and autonomous systems</li><br />
<li>Computer graphics and rendering</li><br />
<li>Parallel computing</li><br />
<li>3D printing</li><br />
</ul><br />
<br />
<h2>Academic Background</h2><br />
<p>I earned my Ph.D. in Computer Science from the University of Illinois at Urbana-Champaign, where my research focused on computer graphics and parallel computing. I also hold an M.S. in Computer Science from UIUC and a B.S. in Computer Science from the University of Alaska Fairbanks.</p><br />
<br />
<h2>Teaching</h2><br />
<p>I teach a variety of computer science courses at UAF, including robotics, operating systems, computer graphics, and simulations. I am also involved in special topics courses related to robotics and NASA's systems engineering practices.</p><br />
<br />
<h2>Projects</h2><br />
<p>I lead the Aurora Robotics Lab at UAF, where we focus on autonomous robotic excavation and construction projects. Currently, I am working on developing autonomous mining robots for lunar base construction as part of the [[NASA X-Hab 2025: Modular Robotic Construction|X-Hab Challenge]] in collaboration with NASA. I also contribute to the <strong>[[LUMINSim]]</strong> simulator and the <strong>[[LAMP]]</strong> project for autonomous lunar infrastructure development.</p><br />
<br />
<h2>Additional Information</h2><br />
<p>For more details, please visit my [https://lawlor.cs.uaf.edu/~olawlor/ UAF Homepage].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Excahauler&diff=788Excahauler2025-07-04T21:31:45Z<p>Acmattson3: </p>
<hr />
<div><h1>Excahauler Mining Robot</h1><br />
[[File:Team-with-excahauler.jpg|alt=The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.|thumb|The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.]]<br />
<p>The <strong>Excahauler</strong> is an autonomous mining robot built for [[Project Archives|NASA's Break the Ice Challenge]] using a combination of welded steel and 3D printed parts. Designed to handle excavation and mining tasks in challenging environments, featuring robust construction and adaptable components. [https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor Here is a YouTube video] of Excahauler in action mining a block of concrete.</p><br />
<br />
<h2>Robot Components</h2><br />
<br />
<h3>Frame</h3><br />
[[File:Excahauler sideview.png|alt=A sideview of the Excahauler robot.|thumb|A sideview of the Excahauler robot.]]<br />
<p>The base of the robot consists of a welded steel frame made from 1-inch (25mm) steel box tubing. The front wheels attach directly to the frame for stability, while the middle and rear wheels are mounted on a rocker system to adapt to uneven terrain. The electronics box, front fork, and arm boom are also bolted directly onto the frame.</p><br />
<br />
<h3>Robot Arm</h3><br />
<p>The robot arm has two main links:</p><br />
<ul><br />
<li><strong>Boom:</strong> Connects to the frame, providing front-to-back motion. It is aligned with an inertial measurement unit mounted on an angled bar.</li><br />
<li><strong>Stick:</strong> The stick, following excavator naming conventions, has an Intel RealSense D455 depth camera mounted on top and a small electronics box for motor controllers.</li><br />
</ul><br />
<br />
<h3>Tool Coupler</h3><br />
<p>The tool coupler allows for quick tool changes using a two-pin system similar to an excavator's quick-change setup. It includes a locking mechanism to secure tools in place, allowing the robot to switch between different excavation tools efficiently.</p><br />
<br />
<h3>Excavation Tools</h3><br />
<p>The robot can use various excavation tools, with the primary tool being a rock grinder. This tool spins a drum to mill material directly into the front scoop. The large ammo can on the robot houses the batteries, motor controller, and space for cooling oil.</p><br />
<br />
<h3>Front Scoop</h3><br />
<p>The front scoop has a volume of 50 liters, allowing it to carry a payload of approximately 50 kg of broken-up material. It features a fork linear actuator for raising and lowering relative to the frame and a dump actuator for tilting the scoop to unload material.</p><br />
<br />
<h2>Coordinate System</h2><br />
<p>The robot follows a right-handed coordinate system:</p><br />
<ul><br />
<li>+Y is forward</li><br />
<li>+X is to the robot's right</li><br />
<li>+Z is up</li><br />
</ul><br />
<p>Some components use rotated coordinate systems to align with the mounted sensors.</p><br />
<br />
<h2>Development</h2><br />
<p>The Excahauler is an ongoing project aimed at advancing autonomous mining technologies. The robot's design and functionality continue to be refined based on testing and research. Its design is a major influence toward [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate designs.</p><br />
<br />
<h2>Further Information</h2><br />
<p>For more details on the robot's design and development, visit the project's [https://github.com/auroraroboticslab/excahauler GitHub page].</p><br />
<br />
<p>For questions or suggestions, please contact lawlor@alaska.edu.</p><br />
<br />
<p><em>Note: Unless specified otherwise, the source code files are released to the public domain.</em></p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Excahauler&diff=787Excahauler2025-07-04T21:31:09Z<p>Acmattson3: </p>
<hr />
<div><h1>Excahauler Mining Robot</h1><br />
[[File:Team-with-excahauler.jpg|alt=The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.|thumb|The Aurora Robotics Team alongside the Excahauler robot at UAF's 2024 Party in the Park.]]<br />
<p>The <strong>Excahauler</strong> is an autonomous mining robot built for [[Project Archives|NASA's Break the Ice Challenge]] using a combination of welded steel and 3D printed parts. Designed to handle excavation and mining tasks in challenging environments, featuring robust construction and adaptable components. [https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor Here is a YouTube video] of Excahauler in action mining a block of concrete.</p><br />
<br />
<h2>Robot Components</h2><br />
<br />
<h3>Frame</h3><br />
[[File:Excahauler sideview.png|alt=A sideview of the Excahauler robot.|thumb|A sideview of the Excahauler robot.]]<br />
<p>The base of the robot consists of a welded steel frame made from 1-inch (25mm) steel box tubing. The front wheels attach directly to the frame for stability, while the middle and rear wheels are mounted on a rocker system to adapt to uneven terrain. The electronics box, front fork, and arm boom are also bolted directly onto the frame.</p><br />
<br />
<h3>Robot Arm</h3><br />
<p>The robot arm has two main links:</p><br />
<ul><br />
<li><strong>Boom:</strong> Connects to the frame, providing front-to-back motion. It is aligned with an inertial measurement unit mounted on an angled bar.</li><br />
<li><strong>Stick:</strong> The stick, following excavator naming conventions, has an Intel RealSense D455 depth camera mounted on top and a small electronics box for motor controllers.</li><br />
</ul><br />
<br />
<h3>Tool Coupler</h3><br />
<p>The tool coupler allows for quick tool changes using a two-pin system similar to an excavator's quick-change setup. It includes a locking mechanism to secure tools in place, allowing the robot to switch between different excavation tools efficiently.</p><br />
<br />
<h3>Excavation Tools</h3><br />
<p>The robot can use various excavation tools, with the primary tool being a rock grinder. This tool spins a drum to mill material directly into the front scoop. The large ammo can on the robot houses the batteries, motor controller, and space for cooling oil.</p><br />
<br />
<h3>Front Scoop</h3><br />
<p>The front scoop has a volume of 50 liters, allowing it to carry a payload of approximately 50 kg of broken-up material. It features a fork linear actuator for raising and lowering relative to the frame and a dump actuator for tilting the scoop to unload material.</p><br />
<br />
<h2>Coordinate System</h2><br />
<p>The robot follows a right-handed coordinate system:</p><br />
<ul><br />
<li>+Y is forward</li><br />
<li>+X is to the robot's right</li><br />
<li>+Z is up</li><br />
</ul><br />
<p>Some components use rotated coordinate systems to align with the mounted sensors.</p><br />
<br />
<h2>Development</h2><br />
<p>The Excahauler is an ongoing project aimed at advancing autonomous mining technologies. The robot's design and functionality continue to be refined based on testing and research.</p><br />
<br />
<h2>Further Information</h2><br />
<p>For more details on the robot's design and development, visit the project's [https://github.com/auroraroboticslab/excahauler GitHub page].</p><br />
<br />
<p>For questions or suggestions, please contact lawlor@alaska.edu.</p><br />
<br />
<p><em>Note: Unless specified otherwise, the source code files are released to the public domain.</em></p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Project_Archives&diff=786Project Archives2025-07-04T21:31:03Z<p>Acmattson3: </p>
<hr />
<div><h1>Project Archives</h1><br />
<br />
== 2024-2025: [[NASA X-Hab 2025: Modular Robotic Construction]] ==<br />
A modular robotic construction project for NASA's [https://www.nasa.gov/exploration-habitat-x-hab-challenge/ eXploration Habitat (X-Hab) Academic Innovation Challenge] where we worked with NASA experts to design a hangar-like structure built from modular "L-Truss" segments. We successfully load tested a scale version and completed to-scale partial robotic assembly.<h2>2021-2023: [https://breaktheicechallenge.com/ NASA Break The Ice Lunar Permafrost Mining Challenge], Phases 1 and 2</h2><br />
<br />
=== Phase 1 ===<br />
<p>Designed a robot to mine lunar permafrost from permanently shadowed craters and haul water to a habitat. Won a $25,000 prize for the Phase 1 proposal, funding subsequent development. [https://www.uaf.edu/news/uaf-team-wins-25000-dollar-prize-in-nasa-challenge.php UAF Team Wins Prize]</p><br />
<br />
=== Phase 2 ===<br />
Developed a 60 kg mining robot ([[Excahauler]]) capable of excavating and transporting over 250 kg of lunar permafrost simulant. This robot was tested during a 15-day durability demonstration ([https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor footage of our test]). Currently focusing on automating the prototype for robust lunar mining operations.<h2>2019: Caterpillar Robotic Mining Competition</h2><br />
<p>Constructed a robot to excavate "icy regolith" beneath 30 cm of packed dust. Awarded the "Lightest Robot" despite using a steel frame, thanks to careful finite element analysis. Gained experience with TIG welding for both the frame and mining buckets. [https://auroraroboticslab.com/ More details]</p><br />
<br />
<h2>2016: NASA Robotic Mining Competition</h2><br />
<p>Developed a new approach for lightweight, 3D-printed tracks used to excavate fluffy basalt dust lunar regolith simulant. The polypropylene straps were lightweight, impact-resistant, and durable. [https://ntrs.nasa.gov/api/citations/20170003829/downloads/20170003829.pdf NASA Robotic Mining Competition]</p><br />
<br />
<h2>2014: NASA Robotic Mining Competition</h2><br />
<p>Designed a robot for excavating a thin layer of lunar regolith simulant. Won the "Judges' Innovation Award" for an unfolding wheel design and a computer vision-based localization approach. Invited to the PISCES robotics competition in Hawaii. [https://spacegrant.org/ NASA Space Grant]</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LAYLA_Robot_Charger&diff=785LAYLA Robot Charger2025-07-04T21:27:19Z<p>Acmattson3: </p>
<hr />
<div>''Early-stage robotic charging system developed by the Aurora Robotics Lab (UAF).''<br />
<br />
<h2>Overview</h2><br />
[[File:Layla.png|alt=Image of a LAYLA charger box.|thumb|Image of a LAYLA charger box. Built from an ammo can and housing a PC power supply repurposed for robot recharging.]]<br />
<p>The <strong>LAYLA Charger</strong> was a university-developed proof‑of‑concept autonomous charging system for mobile robots. Designed between 2014–2020, its goal was to enable unattended docking and charging via a magnetic, self-aligning interface in field environments.</p><br />
<br />
<h2>Technical Concept</h2><br />
<ul><br />
<li><strong>Docking Interface:</strong> Magnetic, nickel-covered “drive‑up” connectors that guided robots into position for charging without human assistance.</li><br />
<li><strong>Dust Tolerance:</strong> Designed to operate in outdoor and dusty conditions, including lunar and Martian dust simulant.</li><br />
<li><strong>Autonomous Alignment:</strong> Initially passive alignment with optional sensor integration for improved reliability.</li><br />
<li><strong>Cycle Durability:</strong> Engineering goal of supporting multiple docking cycles with stable power connection.</li><br />
</ul><br />
<br />
<h2>Development History</h2><br />
<ul><br />
<li>Initiated within [[Main Page|Aurora Robotics Lab]] under [https://www.cs.uaf.edu/~olawlor/ Dr. Orion Lawlor].</li><br />
<li>Prototyped for road-testing with field robots (e.g. [[Project Archives|Break the Ice]] and [[NASA X-Hab 2026: Autonomous Rover Charging for Planetary Surfaces|X-Hab]] platforms).</li><br />
<li>Used in multi-year internal tests (2014–2020), warranting inclusion in subsequent [[NASA X-Hab 2026: Autonomous Rover Charging for Planetary Surfaces|X-Hab]] proposals.</li><br />
</ul><br />
<br />
<h2>Legacy and Impact</h2><br />
<ul><br />
<li>Served as conceptual foundation for the autonomous rover charger in the [[NASA X-Hab 2026: Autonomous Rover Charging for Planetary Surfaces|NASA X-Hab 2026]] proposal.</li><br />
<li>Informed design of magnetic and metal-to-metal alignment features later used in [[Excahauler]] attachments.</li><br />
<li>Highlighted the engineering challenges of environmental sealing, connector wear, and autonomous precision.</li><br />
</ul><br />
<br />
<h2>Current Status</h2><br />
<p>The system did not advance to full deployment but remains part of academic documentation and guided later project directions.</p><br />
<br />
<h2>Suggested Further Reading</h2><br />
* [[Excahauler]] and [[NASA X-Hab 2025: Modular Robotic Construction|L-Truss robotic structures in later X-Hab 2025 project documentation]]</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Project_Archives&diff=784Project Archives2025-07-04T20:48:08Z<p>Acmattson3: Consolidated Break The Ice Challenge entries.</p>
<hr />
<div><h1>Project Archives</h1><br />
<br />
== 2024-2025: [[NASA X-Hab 2025: Modular Robotic Construction]] ==<br />
A modular robotic construction project for NASA's [https://www.nasa.gov/exploration-habitat-x-hab-challenge/ eXploration Habitat (X-Hab) Academic Innovation Challenge] where we worked with NASA experts to design a hangar-like structure built from modular "L-Truss" segments. We successfully load tested a scale version and completed to-scale partial robotic assembly.<h2>2021-2023: NASA Break The Ice Lunar Permafrost Mining Challenge, Phases 1 and 2</h2><br />
<br />
=== Phase 1 ===<br />
<p>Designed a robot to mine lunar permafrost from permanently shadowed craters and haul water to a habitat. Won a $25,000 prize for the Phase 1 proposal, funding subsequent development. [https://www.uaf.edu/news/uaf-team-wins-25000-dollar-prize-in-nasa-challenge.php UAF Team Wins Prize]</p><br />
<br />
=== Phase 2 ===<br />
Developed a 60 kg mining robot ([[Excahauler]]) capable of excavating and transporting over 250 kg of lunar permafrost simulant. This robot was tested during a 15-day durability demonstration ([https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor footage of our test]). Currently focusing on automating the prototype for robust lunar mining operations. [https://breaktheicechallenge.com/ NASA Break The Ice Challenge]<h2>2019: Caterpillar Robotic Mining Competition</h2><br />
<p>Constructed a robot to excavate "icy regolith" beneath 30 cm of packed dust. Awarded the "Lightest Robot" despite using a steel frame, thanks to careful finite element analysis. Gained experience with TIG welding for both the frame and mining buckets. [https://auroraroboticslab.com/ More details]</p><br />
<br />
<h2>2016: NASA Robotic Mining Competition</h2><br />
<p>Developed a new approach for lightweight, 3D-printed tracks used to excavate fluffy basalt dust lunar regolith simulant. The polypropylene straps were lightweight, impact-resistant, and durable. [https://ntrs.nasa.gov/api/citations/20170003829/downloads/20170003829.pdf NASA Robotic Mining Competition]</p><br />
<br />
<h2>2014: NASA Robotic Mining Competition</h2><br />
<p>Designed a robot for excavating a thin layer of lunar regolith simulant. Won the "Judges' Innovation Award" for an unfolding wheel design and a computer vision-based localization approach. Invited to the PISCES robotics competition in Hawaii. [https://spacegrant.org/ NASA Space Grant]</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Project_Archives&diff=783Project Archives2025-07-04T20:46:33Z<p>Acmattson3: Added X-Hab 2025. Removed Ongoing Projects.</p>
<hr />
<div><h1>Project Archives</h1><br />
<br />
== 2024: [[NASA X-Hab 2025: Modular Robotic Construction]] ==<br />
A modular robotic construction project for NASA's [https://www.nasa.gov/exploration-habitat-x-hab-challenge/ eXploration Habitat (X-Hab) Academic Innovation Challenge] where we worked with NASA experts to design a hangar-like structure built from modular "L-Truss" segments. We successfully load tested a scale version and completed to-scale partial robotic assembly.<h2>2023: NASA Break The Ice Lunar Permafrost Mining Challenge, Phase 2</h2><br />
<p>Developed a 60 kg mining robot ([[Excahauler]]) capable of excavating and transporting over 250 kg of lunar permafrost simulant. This robot was tested during a 15-day durability demonstration ([https://www.youtube.com/watch?v=pq0jfVteUY0&ab_channel=OrionLawlor footage of our test]). Currently focusing on automating the prototype for robust lunar mining operations. [https://breaktheicechallenge.com/ NASA Break The Ice Challenge]</p><br />
<br />
<h2>2021: NASA Break The Ice Lunar Permafrost Mining Challenge, Phase 1</h2><br />
<p>Designed a robot to mine lunar permafrost from permanently shadowed craters and haul water to a habitat. Won a $25,000 prize for the Phase 1 proposal, funding subsequent development. [https://www.uaf.edu/news/uaf-team-wins-25000-dollar-prize-in-nasa-challenge.php UAF Team Wins Prize]</p><br />
<br />
<h2>2019: Caterpillar Robotic Mining Competition</h2><br />
<p>Constructed a robot to excavate "icy regolith" beneath 30 cm of packed dust. Awarded the "Lightest Robot" despite using a steel frame, thanks to careful finite element analysis. Gained experience with TIG welding for both the frame and mining buckets. [https://auroraroboticslab.com/ More details]</p><br />
<br />
<h2>2016: NASA Robotic Mining Competition</h2><br />
<p>Developed a new approach for lightweight, 3D-printed tracks used to excavate fluffy basalt dust lunar regolith simulant. The polypropylene straps were lightweight, impact-resistant, and durable. [https://ntrs.nasa.gov/api/citations/20170003829/downloads/20170003829.pdf NASA Robotic Mining Competition]</p><br />
<br />
<h2>2014: NASA Robotic Mining Competition</h2><br />
<p>Designed a robot for excavating a thin layer of lunar regolith simulant. Won the "Judges' Innovation Award" for an unfolding wheel design and a computer vision-based localization approach. Invited to the PISCES robotics competition in Hawaii. [https://spacegrant.org/ NASA Space Grant]</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=Main_Page&diff=782Main Page2025-07-04T20:43:13Z<p>Acmattson3: </p>
<hr />
<div>[[File:Original Aurora Robotics Lab Logo.png|alt=The original Aurora Robotics Lab logo, made in Paint.|thumb|The original Aurora Robotics Lab logo, made in Inkscape.]]<br />
<br />
== Welcome to the Aurora Robotics Wiki ==<br />
Welcome to the official wiki for '''Aurora Robotics''' at the University of Alaska Fairbanks! Our team focuses on the research, design, and development of autonomous robotics platforms (like [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]]) for extreme environments, particularly the Moon.<br />
<br />
=== About Us ===<br />
The Aurora Robotics Team is a multidisciplinary group of students and faculty working on various projects aimed at advancing robotics technology for lunar operations. Our team collaborates with NASA and other partners through challenges and grants to explore solutions for challenges in lunar mining, habitat construction, and autonomous navigation.<br />
<br />
=== Current Projects ===<br />
<br />
* '''[[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP (Lunar, Autonomous, Modular, Platform)]]''': A highly modular robotic platform designed to serve as the hands of the [[LUMIN]] control system. [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] is being developed to be capable of executing a wide range of tasks on the lunar surface.<br />
* '''[[LUMIN|LUMIN (LUnar Mining and Infrastructure Network)]]''': The overarching control software for all lunar operations. [[LUMIN]] acts as the central command system, using [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robots to create a functional operational network and managing tasks ranging from autonomous construction to resource distribution.<br />
* '''[[LUMINSim]]''': A lunar robotic simulator for [[LUMIN]] built in [https://godotengine.org/releases/4.4/ Godot 4.4] used to develop [[LUMIN]] software and test [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robot designs.<br />
<br />
=== Previous Projects ===<br />
Check out [[Project_Archives|the project archives page]] to see previous projects Aurora Robotics has done.<br />
<br />
=== Our Mission ===<br />
Our mission is to develop largely open-source robotics solutions that address lunar challenges. By building autonomous systems and control networks ([[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] and [[LUMIN]]), we aim to contribute to the advancement of human presence on the Moon and beyond, and even in remote places here on Earth. <br />
<br />
==== Long Term, our vision is: ====<br />
<br />
# Drop off a few [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] robots and some equipment in a remote location (on Earth, the Moon, or beyond).<br />
# Autonomously (through [[LUMIN]]) explore and begin developing basic infrastructure (cleared paths, basic equipment/structure setup).<br />
# Begin mining, refining, and preparing resources for expansion.<br />
# Build human-ready structures from the ground up.<br />
<br />
Due to the simplicity and modularity of [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]], our vision includes a point where a couple LAMP robots, with assisting equipment, can develop more LAMP robots, equipment, and infrastructure autonomously, potentially allowing us to remotely colonize entire planets, then their moons, then their star systems and beyond, just by sending a couple robots that way. Then, the LUMIN system can coordinate sending resources back to Earth or inhabited planets (from hard-to-inhabit locations), or humans can move right in (to more habitable locations). <br />
<br />
=== Get Involved ===<br />
We welcome students from all backgrounds to join the Aurora Robotics Team. Regardless of your experience in robotics, programming, mechanical design, if you have an interest in anything you see here, we can find a place for you on our team. Reach out to learn more about how you can get involved in our projects!<br />
<br />
<br />
<br />
See more at [https://auroraroboticslab.com auroraroboticslab.com]</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=User:Acmattson3&diff=781User:Acmattson32025-07-03T22:35:00Z<p>Acmattson3: </p>
<hr />
<div><br />
== About Me ==<br />
[[File:Andrew Mattson Portrait Wedding.png|alt=a silly boi at his wedding|thumb|A photo of me at my wedding]]<br />
Welcome to my user page! My name is Andrew Mattson. I am a student at the [https://www.uaf.edu/uaf/ University of Alaska Fairbanks (UAF)] pursuing a combined Bachelor's/Master's degree in Computer Science. <br />
<br />
Before continuing here, you can find a whole lot more about me on [https://andrew-mattson.com/ my website]. Below is the information most relevant to Aurora Robotics.<br />
<br />
== Academic and Professional Background ==<br />
At UAF, I lead the Aurora Robotics Team while taking classes full-time.<br />
<br />
=== Current Projects ===<br />
<br />
* '''[[LUMINSim]] (my master's thesis):''' I am working on developing a robotic simulator for lunar mining and infrastructure, named 'LUMINSim' (Lunar Mining and Infrastructure Network Simulator), built to simulate the [[LUMIN]] system. This project is integral to my master's thesis, and involves aspects of autonomous control, communication, and terrain generation using [https://godotengine.org/ Godot 4.4] and C++. <br />
* I am the administrator of this MediaWiki page!<br />
<br />
=== Past Projects ===<br />
<br />
* '''[[X-Hab_2025_NASA_Proposal|NASA X-HAB 2025]]:''' I led the Aurora Robotics Team at UAF in [https://www.nasa.gov/exploration-habitat-x-hab-challenge/ NASA's X-Hab Academic Innovation Challenge] for 2024-2025.<br />
* '''[[Project Archives|NASA BreakTheIce Challenge]]:''' I contributed some anti-collision logic to the [https://github.com/auroraRoboticsLab/MiningRobot LUNATIC] control stack for the [[Excahauler]] robot.<br />
<br />
== Contact ==<br />
[https://forms.gle/DCzoyNzndu2YePp28 Here is my contact form] that emails me when a response is submitted; feel free to reach out!</div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMIN&diff=780LUMIN2025-07-03T22:26:01Z<p>Acmattson3: Fixed header.</p>
<hr />
<div><h1>LUMIN (LUnar Mining and Infrastructure Network)</h1><br />
<br />
<strong>LUMIN</strong> is a theoretical overarching control software designed to manage and coordinate robotic lunar operations. It acts as the central hub for autonomous and teleoperated systems, coordinating safe and efficient construction, mining, and transport across the lunar surface.<br />
<br />
<h2>Overview</h2><br />
<br />
<p>The LUMIN control system works with various robotic platforms, including the [[L.A.M.P: Lunar, Autonomous, Modular Platform|Lunar, Autonomous, Modular Platform (LAMP)]] and [[Excahauler]]. The goal of LUMIN is flexibility, which is necessary for the incorporation of new tools, modules, and tasks as lunar infrastructure grows, especially in a multi-organizational context.</p><br />
<br />
<p>[[LUMINSim]] is an open-source simulation of the LUMIN system, though many proposed LUMIN features are still in the process of development.</p><br />
<br />
== [[User:Acmattson3|Andrew Mattson's]] Thesis ==<br />
LUMIN, developed in [[LUMINSim]], will be the core of [[User:Acmattson3|Andrew Mattson's]] master's thesis for the Summer 2025, Fall 2025, and Spring 2026 semesters at the [https://www.uaf.edu/uaf/ University of Alaska Fairbanks]. As of July 7th, 2025, Andrew's thesis is titled '''''Multi-Organizational Robot Coordination and Communication via Realistic Lunar Surface Simulation''','' and he will attempt to answer the question: ''Can autonomous robotic systems effectively coordinate tasks, maintain communication, and manage operational safety zones using [https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet] on the lunar surface when operating under constraints such as limited line-of-sight (LOS), signal degradation, and delays, while in a multi-organizational context?'' <br />
<br />
His project aims to:<br />
<br />
* Extend the [[LUMINSim|GodotRobot (LUMINSim) Lunar Mining Simulator]] to simulate realistic communication challenges including LOS, signal degradation, and delayed transmission.<br />
* Evaluate the effectiveness of [https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet] and determine how it compares against traditional mesh networking models.<br />
* Implement dynamic safety zones to test [https://www.nasa.gov/artemis-accords/ Artemis Accords]-inspired coordination constraints.<br />
* Perform incremental testing, scaling from basic two-node scenarios to complex multi-robot networks involving satellites, towers, and robots.<br />
<br />
== Core Functions ==<br />
<p>LUMIN's primary functions will include:</p><br />
<ul><br />
<li><strong>Coordination:</strong> Managing operations across the lunar surface, including but not limited to robotic platforms like [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] and [[Excahauler]], to carry out construction, mining, transport, resource distribution, and maintenance tasks safely and efficiently in accordance with the [https://www.nasa.gov/artemis-accords/ Artemis Accords].</li><br />
<li><strong>Data Collection and Analysis:</strong> Gathering information while working on the lunar environment to improve decision-making and research.</li><br />
<li><strong>Communication:</strong> Providing a reliable communication network ([https://www.nasa.gov/humans-in-space/lunanet-empowering-artemis-with-communications-and-navigation-interoperability/ LunaNet]) for all lunar operations.</li><br />
</ul><br />
<br />
<h2>Future Developments</h2><br />
<br />
<p>As lunar operations expand, LUMIN's feature set will continue to grow, especially as [[User:Acmattson3|Andrew Mattson]] completes his master's thesis.</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=779LUMINSim2025-07-03T21:36:15Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim (AKA GodotRobot)</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p><strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It serves as a tool for testing and refining robots and their operations in a simulated lunar environment, directly supporting the overarching <strong>[[LUMIN]]</strong> control system. The simulation focuses on the challenges of mining, construction, and other infrastructure tasks essential for future lunar exploration.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<p>LUMINSim aims to be a detailed simulation environment for lunar mining operations. As part of the broader [[LUMIN]] system, it allows the team to model various robotic designs, navigation algorithms, and task execution methods under realistic lunar conditions. The simulator currently features the <strong>[[LAMP v1|Astra]]</strong> robot, the first prototype designed for lunar construction and mining.</p><br />
<br />
<p>The insights gained from LUMINSim's testing of Astra led to the development of a new, more versatile robot called <strong>[[LAMP]] (Lunar, Autonomous, Modular, Platform)</strong>. Astra’s limitations and inadequacies identified in LUMINSim directly informed the modular design philosophy of LAMP, highlighting the simulator's crucial role in advancing lunar robotic platforms.</p><br />
<br />
<h2>Features</h2><br />
<br />
<p>Key features of LUMINSim include:</p><br />
<ul><br />
<li><strong>Terrain Simulation:</strong> Realistic lunar terrain with adjustable parameters. The terrain colliders match the mesh, providing an accurate physical environment for robotic interactions. Terrain texture and lighting are enhanced for greater visual fidelity and accuracy.</li><br />
<li><strong>Autonomous Robot Control:</strong> Users can control mining robots, including the Astra prototype, in both autonomous and manual modes. Features include an in-game console for issuing commands, camera controls, and freecam mode for navigation and inspection.</li><br />
<li><strong>Robot Design Testing:</strong> One of LUMINSim's primary purposes is to test and validate new robotic designs. Astra, the current robot in the simulator, serves as a learning tool that guided the development of LAMP by exposing design flaws and providing insight into necessary features for lunar operations.</li><br />
<li><strong>Multi-Platform Support:</strong> Supports multiple platforms, including desktop and Android, providing a versatile simulation environment for different users and use cases.</li><br />
<li><strong>Immersive Astronaut Simulation:</strong> Allows users to control an astronaut avatar within the simulation.</li><br />
<li><strong>Modular Design:</strong> The modular approach supports the addition of new features, robots, terrains, and missions, aligning with LAMP's design philosophy and the adaptive nature of the LUMIN control system.</li><br />
<li><strong>Console Commands and UI Controls:</strong> Includes various user commands and UI elements, such as speed readouts and simulation rate adjustments to enhance the simulation experience.</li><br />
</ul><br />
<br />
<h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage, with ongoing development aimed at refining robot behavior, terrain interactions, and autonomous capabilities. The latest updates focus on improving terrain generation, enhancing the control of the Astra robot, and introducing new elements such as mountable lights, speed controls, and navigation systems.</p><br />
<br />
<p>Although Astra is the only robot currently in the simulator, its design serves as a foundation for the ongoing development of LAMP. LUMINSim continues to be an essential testbed for validating new designs and technologies before their implementation in actual lunar operations.</p><br />
<br />
<h2>Related Projects</h2><br />
<br />
<ul><br />
<li>[[LAMP]] (Lunar, Autonomous, Modular, Platform) - The next-generation robot designed based on the lessons learned from testing Astra in LUMINSim.</li><br />
<li>[[LUMIN]] (Lunar Mining and Infrastructure Network) - The overarching control software that manages various lunar operations, using LUMINSim as its primary simulation environment for testing and development.</li><br />
</ul><br />
<br />
<h2>How to Get Involved</h2><br />
<br />
<p>The Aurora Robotics Team welcomes collaboration with students and researchers interested in lunar robotics, simulation, and autonomous systems. For more details on LUMINSim or to contribute to its development, please visit our [https://github.com/auroraroboticslab/godotrobot/ GitHub repository].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LUMINSim&diff=778LUMINSim2025-07-03T20:43:34Z<p>Acmattson3: </p>
<hr />
<div><h1>LUMINSim</h1><br />
[[File:Astronaut Cinematic.png|alt=The LUMINSim astronaut standing on the edge of Shackleton crater.|thumb|The LUMINSim astronaut standing on the edge of Shackleton crater.]]<br />
<p><strong>LUMINSim</strong> (Lunar Mining and Infrastructure Network Simulator) is an [https://github.com/auroraroboticslab/godotrobot/ open source] lunar robotic simulator developed by Aurora Robotics using [https://godotengine.org/ Godot 4.4]. It serves as a tool for testing and refining robots and their operations in a simulated lunar environment, directly supporting the overarching <strong>[[LUMIN]]</strong> control system. The simulation focuses on the challenges of mining, construction, and other infrastructure tasks essential for future lunar exploration.</p><br />
[[File:Astra Digging.png|alt=The Astra robot digging in LUMINSim.|thumb|The Astra robot digging in LUMINSim.]]<br />
<h2>Overview</h2><br />
<br />
<p>LUMINSim aims to be a detailed simulation environment for lunar mining operations. As part of the broader [[LUMIN]] system, it allows the team to model various robotic designs, navigation algorithms, and task execution methods under realistic lunar conditions. The simulator currently features the <strong>[[LAMP v1|Astra]]</strong> robot, the first prototype designed for lunar construction and mining.</p><br />
<br />
<p>The insights gained from LUMINSim's testing of Astra led to the development of a new, more versatile robot called <strong>[[LAMP]] (Lunar, Autonomous, Modular, Platform)</strong>. Astra’s limitations and inadequacies identified in LUMINSim directly informed the modular design philosophy of LAMP, highlighting the simulator's crucial role in advancing lunar robotic platforms.</p><br />
<br />
<h2>Features</h2><br />
<br />
<p>Key features of LUMINSim include:</p><br />
<ul><br />
<li><strong>Terrain Simulation:</strong> Realistic lunar terrain with adjustable parameters. The terrain colliders match the mesh, providing an accurate physical environment for robotic interactions. Terrain texture and lighting are enhanced for greater visual fidelity and accuracy.</li><br />
<li><strong>Autonomous Robot Control:</strong> Users can control mining robots, including the Astra prototype, in both autonomous and manual modes. Features include an in-game console for issuing commands, camera controls, and freecam mode for navigation and inspection.</li><br />
<li><strong>Robot Design Testing:</strong> One of LUMINSim's primary purposes is to test and validate new robotic designs. Astra, the current robot in the simulator, serves as a learning tool that guided the development of LAMP by exposing design flaws and providing insight into necessary features for lunar operations.</li><br />
<li><strong>Multi-Platform Support:</strong> Supports multiple platforms, including desktop and Android, providing a versatile simulation environment for different users and use cases.</li><br />
<li><strong>Immersive Astronaut Simulation:</strong> Allows users to control an astronaut avatar within the simulation.</li><br />
<li><strong>Modular Design:</strong> The modular approach supports the addition of new features, robots, terrains, and missions, aligning with LAMP's design philosophy and the adaptive nature of the LUMIN control system.</li><br />
<li><strong>Console Commands and UI Controls:</strong> Includes various user commands and UI elements, such as speed readouts and simulation rate adjustments to enhance the simulation experience.</li><br />
</ul><br />
<br />
<h2>Current Status and Development</h2><br />
<br />
<p>LUMINSim is currently in its alpha stage, with ongoing development aimed at refining robot behavior, terrain interactions, and autonomous capabilities. The latest updates focus on improving terrain generation, enhancing the control of the Astra robot, and introducing new elements such as mountable lights, speed controls, and navigation systems.</p><br />
<br />
<p>Although Astra is the only robot currently in the simulator, its design serves as a foundation for the ongoing development of LAMP. LUMINSim continues to be an essential testbed for validating new designs and technologies before their implementation in actual lunar operations.</p><br />
<br />
<h2>Related Projects</h2><br />
<br />
<ul><br />
<li>[[LAMP]] (Lunar, Autonomous, Modular, Platform) - The next-generation robot designed based on the lessons learned from testing Astra in LUMINSim.</li><br />
<li>[[LUMIN]] (Lunar Mining and Infrastructure Network) - The overarching control software that manages various lunar operations, using LUMINSim as its primary simulation environment for testing and development.</li><br />
</ul><br />
<br />
<h2>How to Get Involved</h2><br />
<br />
<p>The Aurora Robotics Team welcomes collaboration with students and researchers interested in lunar robotics, simulation, and autonomous systems. For more details on LUMINSim or to contribute to its development, please visit our [https://github.com/auroraroboticslab/godotrobot/ GitHub repository].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=LAMP_v1&diff=777LAMP v12025-07-03T20:42:13Z<p>Acmattson3: </p>
<hr />
<div><h1>LAMP v1 (Astra)</h1><br />
[[File:Astra Digging.png|alt=Astra in LUMINSim, digging on a hill.|thumb|Astra in LUMINSim, digging on a hill.]]<br />
<p><strong>LAMP v1, also known as Astra</strong>, is the first proposed candidate to become [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP (Lunar, Autonomous, Modular, Platform)]]. Astra was developed in [https://www.autodesk.com/products/fusion-360/overview Fusion360] and tested in <strong>[[LUMINSim]]</strong> to assess its mining, mobility, and transport capabilities on the lunar surface. This testing revealed core flaws requiring near-complete redesign, which (as of July 3rd, 2025) has yet to be completed.</p><br />
<br />
<h2>Design Overview</h2><br />
<br />
=== Modular Tool Coupler ===<br />
<p>Astra features a single arm equipped with a modular tool coupler, allowing it to utilize any tool designed for it. Unlike <strong>[[Excahauler]]</strong>, Astra does not have a pre-attached bucket, as it's design prioritizes modularity. Astra's tool coupler is located on the end of a two-joint arm and has tilt functionality, providing versatility in operating a range of tools.</p><br />
<br />
=== Modular Bed ===<br />
On Astra's back is a modular bed coupler. This coupler allows it to carry a large variety of beds, including but not limited to:<br />
<br />
* A hopper-style bed (seen in the photo above; for transporting loose material).<br />
* A flatbed (for general transport of solid objects).<br />
* A tool bed (for carrying multiple tool types).<br />
* A communications relay (possibly with an antenna to be lifted by the arm's tool coupler).<br />
<br />
=== Frame ===<br />
Astra's frame was designed to be highly modular while also allowing high mobility across lunar terrain, with emphasis on ease of travel and transport.<h2>Design Flaws and Testing</h2><br />
<br />
<p>During its development and testing in <strong>[[LUMINSim]]</strong>, several design flaws in Astra were identified:</p><br />
<br />
<ul><br />
<li>The arm's hinge point on the frame was positioned too far forward, causing the robot to easily tip over, especially during heavy lifting.</li><br />
<li>The original built-in hopper design was deemed inefficient. This was replaced with the aforementioned modular bed interface, but was not enough to save the overall design due to the previous issue.</li><li>The wheelbase generally struggles in lunar agility.</li><br />
</ul>These insights have guided plans for design improvements in the next [[L.A.M.P: Lunar, Autonomous, Modular Platform|LAMP]] candidate.<h2>Related</h2><br />
<br />
<p>For more information or to contribute to the development of the LAMP project, visit the team's [https://github.com/AuroraRoboticsLab GitHub page].</p></div>Acmattson3https://aurorarobotics.sssn.us/index.php?title=L.A.M.P:_Lunar,_Autonomous,_Modular_Platform&diff=776L.A.M.P: Lunar, Autonomous, Modular Platform2025-07-03T20:22:36Z<p>Acmattson3: </p>
<hr />
<div>LAMP is the hands of the [[LUMIN]] control system. It is a highly modular robotic platform designed to enforce safety protocols, develop lunar infrastructure, and generally do what [[LUMIN]] requires. Through coordination with [[LUMIN]], LAMPs in the field will work together to achieve tasks that would be extremely difficult or impossible for a single robot to accomplish.<br />
<br />
== Overview ==<br />
LAMP's modularity will allow it to serve a wide range of needs on the Moon. LAMP robots might: <br />
<br />
* Enforce general safety (like patrolling safety zone borders, decommissioning or disabling rogue agents, or developing and maintaining reliable infrastructure)<br />
* Collect data (for use in research, decision-making processes, and policy refinement)<br />
* Distribute resources (by hauling tools, materials, or power across the lunar surface)<br />
* Act as communication relays (before communication infrastructure is in place and during its development, or in especially remote locations)<br />
<br />
LAMP's modularity allows it to complete a large variety of tasks. For example, materials transport may require a flatbed or dump bed, communications infrastructure development may need a specialized toolhead for trenching and a rear payload for spools of wire or tubing.<br />
<br />
=== Influential/Previous Designs: ===<br />
* [[Excahauler]]<br />
* [[LAMP v1]] (A.K.A. Astra)<br />
<br />
== Design Philosophy ==<br />
<p>LAMP's design revolves around its versatility for ranges of tasks on the Moon. Specialized tools for LAMP should always be built as attachments that can be easily interchanged to maintain said versatility. Any permanent additions to the main frame should be carefully designed to function across multiple purposes.</p><br />
<br />
To meet the demands of lunar infrastructure, LAMP must maintain simplicity without compromising its abilities in order to: <br />
<br />
# Keep manufacturing costs down.<br />
# Encourage simpler parts, which are ultimately easier to make durable and repair.<br />
# Encourage extension through the system's modularity.__FORCETOC__</div>Acmattson3