mars-sim / mars-sim

Mars Simulation Project Official Codebase
https://mars-sim.com
GNU General Public License v3.0
107 stars 38 forks source link

How should destination distance restrict which mission is chosen ? #904

Open mokun opened 1 year ago

mokun commented 1 year ago

Is your feature request related to a problem? Please describe.

Describe the solution you desire to see

Describe the rationale

Codes

Specifications (please complete the following information):

mokun commented 1 year ago

Will undo a small part of https://github.com/mars-sim/mars-sim/commit/7b92056a53ff314d5b310c3e30d53cbbca9453a8 that prevent any missions from starting.

The reason was that distanceProposed at the moment of reserving a vehicle is always zero. So it won't work.

bevans2000 commented 1 year ago

Will undo a small part of 7b92056 that prevent any missions from starting.

The reason was that distanceProposed at the moment of reserving a vehicle is always zero. So it won't work.

Yes, the vehicle is chosen before the mission destination. The mission locations are based on the calculated range of the vehicle. So I noticed that recently ranges have become very large maybe due to cha ge for Vehiclecontroller.

bevans2000 commented 1 year ago

The capping of distance has to be in the constructor of the specific missions. Either

mokun commented 1 year ago

Just committed this to remove that check.

mokun commented 1 year ago

So I noticed that recently ranges have become very large maybe due to cha ge for Vehiclecontroller.

Yes I've toned down the base range. The calculation was a bit off. It's more reasonable now.

In near future, I'll look up theories on vehicle dynamic and add in a few more params for predicting the drive range better. For now, there's still quite a bit of hacks with handcrafted values.

mokun commented 1 year ago

Actually, it's also possible a mission planning to do a parallel task of both (1) looking for just available vehicle to see what range it can provide thus limiting the visiting locations and (2) finding waypoints and destinations and estimating the total trip distance.

Of course, if there are multiple vehicles available, then it's best to first decide where to go, then select the right vehicle with enough range.

So both approaches are valid.

bevans2000 commented 1 year ago

In #890 I have followed the vehicle first and then mission route second. I think that makes sense but we need to cap the distance when searching for destinations

bevans2000 commented 1 year ago

As part of #890 I am splitting up the various logic blocks to separate class/methods which will give us more flexibility. I want introduce a generic VehicleScorer that can assess a vehicle against a Mission depending on the requirements needed. This will be essential to allow custom Mission to be defined.

mokun commented 1 year ago

We could use the RACI model that @Urwumpe was alluring to potentially crafting better mission. See #226. It was still open.

Urwumpe commented 1 year ago

That one is mostly architectual and only prevents, that too many Settlers do the same, worst of all, doing decisions.

Here, I would rather go having criteria, that could compare vehicles to other vehicles or vehicles to missions. And allow to add criteria to a decision/Rover selection process as needed by the mission.

Can we allow alternative mission plans to a mission in the planning phase? Like a transport mission using a convoy of multiple rovers or fit all into a single big Rover? This could result in more variance of missions with fewer dedicated mission classes and allow fitting a mission better to the capabilities of a smaller or larger settlement. Just the special components of how a mission is planned would need to be hard-coded, like what constitutes a fully-planned mineral exploration mission.

bevans2000 commented 1 year ago

I think where we are trying to go with #890 of making Missions be a sequence of Steps should give us more flexibility. The Steps become individual building blocks. So for multiple vehicles we could create a Mission of Missions; each individual Mission would be control a single Vehicle. But the top level Mission would be about doing a large scale trade with a settlement. Same for Construction as well with the sub-mission being the individual parts, foundation, frame etc. The top level Mission would be the Plan.

mokun commented 1 year ago

that too many Settlers do the same, worst of all, doing decisions.

So we are talking about the degree of Autonomy in governing a settlement.

Also there may be several aspects of mission here, namely, mission determination, mission approval and mission planning, etc..

So, just in terms of deciding what mission to take on, I can think of several paths that we could go down :

  1. Have a space agency or sponsor dictate where settlers need to go in order to fulfill a sponsor's Mission Agenda
  2. Have a settlement itself to fully direct what missions to generate and proceed.
  3. Have the AI commander decide and initiate a mission
  4. Have settlers having the desire and ability to propose, do the ground work to plan and suggest where to go and what to do
  5. Have player commander start a mission

So level 1 from above is the least autonomy we are giving mars-sim while level 4 is the one with the highest degree of autonomy. Level 5 is when mars-sim won't decide anything but wait for player to make up his mind in deciding what to do next.

Ideally speaking, we want to build mars-sim to have all levels from 1 to 5.

While we want settlers (level 4) to propose for a mission but we do want inputs from player commander (level 5) . But player may be benefit from the help of an impartial system (level 2 and 3) that help him to weigh on every relevant factor regarding the mission before approving it.

I suppose mars-sim already have the tradition in spending a lot of time coding level 2-4.

We rarely have any level 1 things yet. MissionAgenda class has some influence on mission and science and is sort of level 1.

May be we should spend more time on level 5.

We'll need to be explicit about mars-sim does EXACTLY at each level.

Also, we should give options in Main Menu sim for a player to adjust how much he wants for each level.

Player may choose to shut down most autonomy from level 1 to 4 so that he'll run the show entirely by himself (level 5), even though it may not be recommended.

mokun commented 1 year ago

Back to the original question regarding the distance, we've since made some progress in making the proposed mission to calculating shorter distance.

However, from time to time, long distance still pops up and got approved.

In this Alpha Base settlement called Tiberius, in the first 2 sols, they proposed over 12 missions. 4 of them have been approved as follows:

image

The last one (a regolith mission with 34 km only) did not get approved. Then on sol 3, a new one (a mining mission with 664 km) got approved. See below:

image

To fix this, I'm thinking of differentiating the opinion score between divisions. For instance,

  1. The safety specialists should be the one who would caution against long distance since the longer the distance, the higher the risk factors are.
  2. The logistic specialists would score on how likely the mission plans would adhere to the EVA time and travel time.
  3. The resource specialists would focus on scoring the food/water/fuel consumable
  4. The science specialists would comment on the scientific returns on investment

Do you guys like that idea ?

bevans2000 commented 1 year ago

So are you saying that a Mission has to be score by multiple Persons, each with a different Role?

mokun commented 1 year ago

a Mission has to be score by multiple Persons, each with a different Role?

Yes. This is how it's done traditionally. It needs to be reviewed by multiple people. Each decision will have a weight of 10 to 20%. If the total score is larger than the last passing score, then the mission is approved.

But now, we want to add a new twist to it.

Since each reviewer has a role, we may as well take advantage of that by having them doing their job based upon their role perspective.