Automated Miner (Released)

https://steamcommunity.com/sharedfiles/filedetails/?id=433545870


This is driven by programming scripts.

• Automated asteroid mining
• Stops when battery low, cargo full, etc
• Collision detection between ships when mining
• Ranged targeting. Used to target asteroids for automated mining
• Automated launch from docking
• Automated move to asteroid (with collision detection)
• Automated 'Go Home' when needed and on command (with collision detection and avoidance)
• Camera on array of Displays for remote access to information.

Main walk-through video:

Here is a video of some testing of collision avoidance from a couple days ago:

Like I say in the video: I can just watch the miner do its thing for way too long:

 

Explanation of the sensors on the ship and what they are used for.

 

Update just posted with more collision detection/avoidance.

 

You, sir are a true engineer. Well done!

 

Here is a video from my test last night of four mk3 miners working from an LMDI103.

Beginning part is me figuring out the programming blocks were turned off (by the LMDI103 when docked)

Three of them I use the 'launch' and they have a 'home' set.

The fourth I reset and just set a target mining location. Later I drive it back home manually.

After letting them mine for a bit, I tell them to 'Go Home'.

The first one sent back detects collision with the overhang of the solar panels and calls for help.

At about 19:00 there is a minor problem where one going home glances an asteroid and then can't find it again to maneuver around it. I have a plan to fix this issue. I spent a little time testing how to use the gyros to see the problem; normally a player would just 'miner reset' and 'Go Home' again.

The others get into position without problems.

it ends with all the miners re-docked and a check of the new ore in LMDI103 being processed.

 

Features:

• Added sorter to control ejector contents
• User manual Created
• Support for user added batteries and solar panels (tested with xpar mods)
• Start to back into dock. Still can't quite align for connection, but it gets closer
• Hid all blocks in UI not 'needed'.
• Was at 100k Code in controller program, so I split it into two blocks

Bug fixes:

• Turn off ejectors when docking, etc.
• Aft camera orientation

 

ooh, new features

also: 100k code... perforated excrement! I knew it was complex but thats... thats 3 times bigger than DOS 2.0 (thats an operating system for PC for the less temporally advanced readers)

 

Well, that's 100k SOURCE code.. but still. it is a lot.

If anybody has questions about how stuff works, please let me know.

The code is basically just C; no object oriented weirdness

I taught myself C from the K&R book, and my coding style hasn't changed much since

 

Found bug Crashed wico main program block when using ranged targeter
Line 2869 filterBlocks < IMyTerminalBlock > (blocks, "Connector Trash");
There is no such block.
There is a Miner Connector.
So changed line 2869 to
filterBlocks < IMyTerminalBlock > (blocks, "Miner Connector");

 

Fixed and re-published.

 

wait, its c!? I know c the wiki said it was c#. bad wiki! Bad! gentlemen, ladies, please excuse me while I go dive back into my native element...

 

I get it now! its C#. but c# uses the old imperative C command sets and structures for writing methods. lets say you wanted to drive a 8 segment display using a DB9 serial connector, your entire program can be written as a single method attached to a single object, the serial controler. so you need never use the object orientated parts. thats an aproach I have never considered. so basicaly, the PB script in SE is a single method attached to the PB object in the source code. mind blown. from the looks of the function libraries I've found, it looks like they have kept the heirarchal relationship concept of OO, which actually looks useful here. but everything else is a stored variable. they again kept the OO method of splitting constants and variables then giving them new names like actions. but its just a user defined variable from C. to get at a variable in c you would address it directly, here you address it through the heirarchy, but its more of a path name than an object/method relationship. does this sound right, or am I overtired and over caffinated and its giving me a psudo epiphany?

 

Yes, that's correct. Long story short, my C# code for the miner (and everything I write, basically) looks like C code with a few exceptions (List<T>, etc)

 

User Manual for Wico Miner mk3 See User Manual block in the ship.

View the videos and other information in the workshop.

* I recommend testing in creative before spending the resources to make in survival.

* There are know bugs in multiplayer with drills and mining.

The miner needs clear space from its connector and 50m in front for launch and recovery.
Because the docking is near a ship, limited collision detection is done. There should be a connector per miner; don't try to share.

Most blocks are hidden to make control easier. Use the remote control command bars for ormal access.

After construction, take ownership, then recompile all of the programming blocks. Some are hidden.

NOTE: The configuration of the ship (including block information like batteries, solar panels, etc) is only read at startup. To have changes take effect, you will need to Open the status and main programming blocks and 'remember and exit" on each of them.

If a projector is present, the miner control will assume it is being constructed and go into a special state. This is reported in the information panel of the programmable block.

Normal use
After creation, make sure to put enough uranium in reactor for emergency usage. Connect the miner to a connector. The battery should automatically start to recharge and the thrusters should turn off.

If you are using a "Tender" type ship, move the tender (with mk3 attached) to the cluster you want to mine.

Setting Home

Launch
When ready to mine, "Launch" the miner. Command Bar 1/#1. This will launch the miner away from the connector about 50 meters. This area must be kept clear. The miner remembers the launch waypoints and it assumes that the connector will still be in the same place when it returns "home".

Set Home
If you don't have a spare connector, or have multiple miners and limited connectors, use the
'Set Home" command: Command Bar 4/#2. This will set the "home" location.

Asteroid Mining Selection

Manual Asteroid Selection
You can manually drive the ship to a asteroid to mine and press "Mine"; Command bar 1/#7. The miner will mine until done and then return home. This method can also be used to change which asteroid the miner thinks of as 'target'.

Remote Target
You can also remotely target an asteroid to go mine.

Control the ship and view the front camera (Command Bar 1/#3). Zoom in with the camera onto a visible feature of the target asteroid. Select "Target" Command Bar 4/#3.

Move the miner. The further away from the first point, the more accurate the target. Then zoom in with the camera to the same feature and press "Target" again: Command Bar 4/#3.

Go Mine

After a mining target is created, select "Go Mine": Command Bar 1/#5. The miner will go to the target and begin mining.

A found asteroid will be the mining target over the ranged target; the found asteroid is 'known' to be something to mine. Setting a ranged target will reset any found asteroid location.

Done Mining

When done mining (cargo full, battery low, etc, the miner will try to "Go Home". If no "Home" waypoint was set, the miner will call for attention.

The miner can be ordered to "Go Home". Command Bar 1/#6. You should remove the miner from inside a mining tunnel before issuing the command or it will just report collision.

Home

When the miner arrives "home", the miner will try to dock if a dock location was set (by "Launch"ing).

NEW: if Keen autopilot has been setup and mode toggled, then the ship will use the keen autopilot. This WORKS and will completely dock the ship.

When the miner needs manual assistance docking it will alert you.

Docking

When docked, the miner turns off thrusters and sets the battery(ies) to recharge.

Re Launch
When Launched, if the miner has a mine target set, it will automatically "Go Mine" after the launch is completed.


NEW: Setting up Keen Autopilot

You must launch the ship. Then edit the public text on the [gps] panel. Then go the the Keen GPS panel to import the GPS waypoints into Keen's waypoint system.

NEW: the waypoints have the antenna name of the ship added. This allows you to easily name the ships and their waypoints.

After the waypoints are in Keen's GPS system, you must add them to the remote control blocks autopilot.
First add Docking Entry, then Dock. Select Prevision mode and "Backwards" and "One Way".

Tell the miner you have correctly set up the autopilot by toggling the docking mode. (Command bar 4/#1)

Now the ship will use the Keen autopilot to dock.

Verify selected docking mode by viewing the far right text panel on the displays camera.

Needed Groups
Verify the following groups exist:

"Heavy Forward Thrust" Heavy thrust forward group. Used when inside asteroid mining.
On Miner are all named "H FTThruster". This blocks in this group must have an override set.

"Auto Forward Thrust" Small thrust forward group. used when approaching asteroid and kept on until exit.
On Miner all named "A FTThruster. This blocks in this group must have an override set.

"Small Miner Normal Thrusters" All other thrusters that are not overridden (ie, the two groups above).
This is used to turn off thrusters when docked.

"NAV Thrusters" Thrusters that move the ship forward. On the miner these are all named FTThruster

"Thrust Backward" Thrusters that move the ship backward. On the miner these are all named BKThruster

"Drills" turned on when starting to mine.

"Thrust Down" Group of Thrusters that move the ship down.

"Thrust Up" Group of Thrusters that move the ship up.

Optional Groups
"-Remote Control" Convenience group for selecting remote control. Note: when docked, groups are shared, so this group will be ALL remote controls.
"Lights" Turned on when mining and and waiting to mine. Turned off when done mining.


"Thrust Left" Not currently used
"Thrust Right" Not currently used

"WicoPBMain" The main control program for the miner. Group used as shortcut by developer when doing testing.
"WicoPBStatus" The status reporting program for the miner. Group used as shortcut by developer when doing testing

Visible Blocks
* wsam Mk3. The antenna. Name can be changed. Do not use ! in the name as that's used by the status reporting.

* Miner Connector. The back connector on the miner. Visible so settings can be manually changed.
The control program will normaly manage the connector itself (including docking).

* User Manual. Contains this file. Edit to view.
* Miner Remote Control. The remote control. Normally, access through the "-Remote Control" group. But, when docked, access the block directly.
* Miner Conveyor Sorter. Sorter with whitelist to throw out unwanted items.
Is set up to pass stone by default.
* Text Panel L3 [GPS]. This panel contains the waypoint information in GPS format.
Click on Edit for the public text, then close. Then open the GPS tab and the waypoints will appear.
* Wico Miner Config. Configuration file for control of basic settings of the miner control.
Edit the public text to change the configuration.


NOTE: The configuration of the ship (including block information like batteries, solar panels, etc) is only read at startup. To have changes take effect, you will need to Open the status and main programming blocks and 'remeber and exit" on each of them.

If a projector is present, the miner control will assume it is being constructed and go into a special state. This is reported in the information panel of the programmable block.

Command Bars

Command Bar 1: Common Automated Controls
*
#1: "Launch"
#2: view displays camera
#3: View front camera
#4: View aft camera
#5: Go Mine. This command will go to a ranged target (if set) or back to a previously mined asteroid.
#6: Go Home. This command will return to the home launch point. Currently, the only way of setting this point is to "launch".
#7: Start Mining. Assume an asteroid is in front and start mining. Same as in mk2 and mk1
#8: Start Search. Search for an asteroid in sensor range.
#9: Miner reset. reset automated control to allow manual control. Does NOT reset waypoints. This does reset all alert states (displayed in antenna).

Command Bar 2: Common Manual Controls
* This bar is set up for using the automated miner without waypoint automation.
* This bar is similar to main bar from mk2 and mk1.

#1: "Drills" On
#2: view displays camera
#3: View front camera
#4: View aft camera
#5: Connector On/Off. used for docking
#6: "Auto Forward Thrust" override on/off. used for mining
#7: "Heavy Forward Thrust" override on/off. used for mining
#8: Master Reset. Resets miner state including waypoints.
#9: "Lights" group on/off.


Command Bar 3: Advanced controls
*
#1: Gyro Miner Yaw block on/off. use in case out of control
#2: Gyro Miner Roll block on/off. use in case out of control
#3: "NAV Gyros" group on/off. use in case out of control

#5: "Small Miner Normal Thrusters" group on/off. used when docked. Miner should turn these off automatically when docked.

#7: Gyro Miner Yaw Override on/off. use in case out of control
#8: Gyro Miner Roll Override on/off. use in case out of control


Command Bar 4: Advanced Automation Controls
* Other commands will be added here as implemented.
#1: Toggle using Keen autopilot for docking.
#2: Set Home. Sets the home location for the miner. This reset any connector dock that has been set.
Miner will go to home location and ask for assistance docking. Useful if you don't have a
dedicated connector for each miner.
It is accessible in the [GPS] text panel.

#3: Ranged Target. Start or finish a ranged target. Calculated target is stored in Target Asteroid;
It is accessible in the [GPS] text panel.

#4: Toggle automatic relaunch. Miners will automatically relaunch if they have been launched once and if battery power >80% and cargo % < 5

#8: Master Reset. Resets miner state including waypoints.
#9: Miner reset. Reset automated control to allow manual control. Does NOT reset waypoints. This does reset all alert states (displayed in antenna).

Alerts

The miner communicates alerts to the user by changing the name of the antenna that is being broadcast.

Most of the alerts are informational. The Attention alert means the miner needs user intervention to continue. The informational alert will let the user know which alert needs attention.

"ATTENTION NEEDED"

The miner needs user attention. This alert is only reset by the user; Command bar 1/#9.

Usually the miner will need remote control to move the miner or recover from some error.

"Cargo Full"
Informational. The cargo is above the high water mark

"Collision Detected"
Informational. A collision has been detected. In most the miner will be able to avoid the collision.

"Search Failed"
Informational. A search for an asteroid has timed out.

"Battery Low"
Informational. The battery is below the low water mark

"NAV Timeout"
Informational. The navigation system has timed out.

"Cannot reach target"
Informational. The target is not defined or unreachable. For example, "Go Home" when no "home" waypoint is set.

"Docking Assist Needed"
Informational. The miner needs user assistance to complete the docking procedure.

"Going Home"
Informational. The miner is currently going home under automated control.

"Launching"
Informational. The miner is currently launching automated control.

"Going to mine"
Informational. The miner is currently going to mine under automated control.

"Docking"
Informational. The miner is currently trying to dock under automated control.

Problem Solving
If something goes wrong
* Select the Main Programming Block and see if there are any errors reported. If any blocks are missing, replace them from blueprint

If you replace any damaged sensors, find hidden "Programmable block Sensor State" and run it. Default argument is "load". This will reset the sensors to their default state (from information in "Sensor State Save")

* Check all groups are created. See list at top

Status displays are not updating
check all timers are actually running. Hit start if they are not:
* Timer Block LCD
* Timer Block Wico Miner Status
* Timer Block Wico Miner

Use 'miner reset' to reset states. Then try action again.

Use 'Master reset' to fully reset.

* Please post any bugs you find in the workshop discussion.

 

Update for a couple features and bug fixes:

Features:

• tested with some mods
• show alert state in status
• fix keen bug with timers on reload for NAV
• turn on/off sensors as needed to conserve power
• added 'action launch" group for when multiple docked

Bug Fixes:

• fix setting to recharge batteries >1 when docked

Programming changes (internal):

• get init() and mode processing out of main()
• add 'enter mode' routine to handle transitions (sensors, etc)

 

Update with automated docking using Keen's autopilot.

 

Update: Jun 15 @ 10:38am
Features:

• Auto relaunch ability added
  Toggle on command bar 4/#4. Status displayed on right text panel.
  
  Battery and cargo space are validated before starting a relaunch. There is a 5 second countdown before launch.
  
  Currently the values are hardcoded at >80% battery and <5% cargo space. I will move these to the configuration text panel.

Bug Fixes:

• Keen autopilot cannot be used while remote control is under player control.
  
  Miner now detect this and displays "Attention needed" alert. Autopilot control resumes when the player stops control.

 

I made this thread so that others in the community could have a complex example of what's possible with scripts.

I had expected questions asking "how did you...?" And "why the heck did you do that?" And "I don't understand what you're doing here...".

But I'm not getting that.

I'm trying to keep the code in the PBs commented and formatted so it is readable.

So, a couple of questions
Have you tried looking at what the ship does at a functional level? (Not the code itself, just viewing the videos or even trying the blueprint)

Have you looked at the code?

Why or why not?

 

I think most players just want to use the drone.
For the remaining players that are interested in the code its simply too long I guess. As I read you needed a 2nd block because you reached the 100k character limit it just puts me off. As beeing a software engineer myself it tells me you should refactor your code to make it worth reading for other peoples. Use multiple PBs to split your functionalities and to introduce abstraction layers. You would also do it in C by splitting your code into differend *.c/h files. For instance: use separate PB to manage movement and rotation. The code should be about 200-300 lines of code for each PB which is really readable.
And ontop of the two "low level" PBs you have the main PB that coordinates everything by telling the movment PB and the rotation PB what to do.

 

Sure. Most do. And I did make a post in the Community Creations forum for those people.
But this is "Released Codes" where things are posted for script-orient people.

Complexity is high. And, in fact, you understate the actual complexity. There is a separate NAV script that does the actual ship moving to and fro (but the main control has the collision detect/avoid).

PBs are monolithic; there is one source file for the PB. There is no #include. You cannot call routines or access data in other PBs. The only way PBs can 'communicate' is by changing and reading other blocks in the grid (text blocks, for example).

So what you propose for good software engineering really isn't possible. FYI: The NAV script is about 700 lines of code. My "Main" PB is 3300 loc and the "Status" is about 2000. There is a good amount of duplication of code between the two for things like variable definitions and helper functions because there is no sharing of code.

I could make examples of the different functional areas of the code and make those available. This would demonstrate areas of functionality in a much more "clean" environment. It would, by definition, have to remove some of the complexity of some of the areas.

Examples would be configuration reading, serialization, then handling reload/recompile in a state machine (builds on serialization), using sensors, communicating between PBs (with NAV as an example), 'user alerts' and displaying them on the antenna...

So focused examples/tutorials... Would that be interesting?

 

sorry, I've been distracted for a couple of weeks (learning c# and arguing on the forums. and steam sale). expect code focused questions over the next few days (now I know a little more I might be able to read it better) I'm glad you had a win with the docking, thats quite an advancement for drone automation in SE. I'm looking forward to seeing what impact your experiments with sensors has had on your system as well.

 

No real sensor experiments so far because time is being spent on the miner and retesting, etc. But I did show you a little bit of my mapper system.

 

And it was cool

 

Hi, I'm glad you didn't take my post as an offense as I feared you could

Yes, I know you can't invoke methods from another PB. And I meant using text blocks to communicate between PBs. You actually have a second option to realize it: use the run method with an argument passed to it.
Regardless which solution you prefer it is possible to change or control the behavior of another PB.

It is not possible the way one would usually do. But you can define a PB to be a class and use text panels as interfaces in terms of OO languages.
I started a drone project myself a few months ago. I've seperated functionalities (rotation/movement) and logic into separate blocks. For communication I used a single text panel together with a helper class that can be used like this:

Code:

DataPanel data = new DataPanel (GridTerminalSystem.GetBlockWithName ("LCD Data Panel"));
//Logic PB writes data this way
data.Write ("TargetLocation", new Vector3D (1, 2, 3));
//The movement PB reads data this way:
data.ReadVector3D("TargetLocation")

The DataPanel class helped me to introduce a communication interface which helps to abstract between the logic and function blocks like real interfaces do in OO programming languages. This way one does not need to understand the implementation of the functional block (=> black box) but one knows what they are supposed to do when I write something like "TargetLocation" or "MoveToLocation" into the data panel.
I currently have no access to the code as I'm not at home, but I can post the helper class here if you are interested.

So I guess you introduced some abstraction between your nav/main/status PBs as I just tried to explain.
I'm really interested in the movement/rotation part of the PB. I myself had the problem that my movment PB only worked reliable when I set the timer to run it every simulation cycle. So I would like to know the location in your code so I can have a look at it when I have some time. State machine diagrams would help to understand the whole system without question.

 

Please do, it would be very useful to me and I'd be very grateful.

 

Yes, that's correct. I'm communicating between the PBs using text panels. I do have it on my 'todo' list to separate the functionality modules of my current system further. For example, master control, mining control, command processing, navigation waypoint control (including collision), and (future) mapping, waypoint management, cargo management (for back and forth cargo mover) and some kind of weaponization.

But note that this increases complexity. And complexity was your main complaint about looking at the code in the first place.

Also, (as I've explained previously in this thread), I taught myself C by using the K&R book (first edition). So I probably won't me making proper OO classes. I do understand their usefulness, but I just don't trust myself to do it

 

@Newton ahha, i see you found my inspiration

@Wicorel have i sent you the link to the yellow book yet? it beat C# into my head (the first OO language text i have understood after near a decade of trying) i highly recommend it. if it can get my rubbery old head roughly wrapped halfway around it, imagine what it could do for yours
https://www.robmiles.com/c-yellow-book/

Edit: yours being a younger, less rubbery head that doesn't need rough treatment. Sorry, just re-read and realised there was a possible wrong interpretation there.

 

Yes it increases the complexity but I can't remember I wrote explicit about complexity. What I wanted to say is, to structure the code by swapping out different functionalities. So what frightened me was the imagination of so much code in a single PB where all kind of functionalities are put together. I love abstraction so one does not need to understand the whole code at once althought it might become a bit more complex but structured code

@Newton I've uploaded the DataTerminal script.

 

You didn't, explicitly, call it complexity.

I assumed that you meant complexity. What did you mean, then?

 

I was remembering my first bigger project with some friends about 9 years ago. We put all our code in a single java class as we didn't know anything about OO and not much about programming
But as you already said you have separated your code and you are planning to refactor it. As soon as I have some time I'll check it out.