|
1 | | -# CIRCINUS |
| 1 | +# SPRINT |
2 | 2 |
|
3 | | -**C**onstellation |
4 | | -**I**nvestigation |
5 | | -**R**epository with |
6 | | -**C**ommunications, |
7 | | -**I**nter-agent |
8 | | -**N**etworking, |
9 | | -**U**ncertainty, and |
10 | 3 | **S**cheduling |
| 4 | +**P**lanning |
| 5 | +**R**outing |
| 6 | +**I**nter-satellite |
| 7 | +**N**etworking |
| 8 | +**T**ool |
11 | 9 |
|
12 | 10 | # General Setup |
13 | 11 |
|
14 | | -1. Clone the repo: `git clone --recursive git@github.edu:apollokit/circinus.git` |
| 12 | +1. Clone the repo: `git clone --recursive git@github.com:apollokit/circinus.git` |
15 | 13 | 1. Set up your environment: |
16 | | - 1. Install and configure your default `python` and pip to exactly Python **3.5**, (recommended in a virtual environment, see next step). |
17 | | - 1. Recommended: Direct installation, if needed: Download from https://www.python.org/downloads/. Note that the global planner code is currently tested with Python 3.5.4. |
18 | | - 1. Not recommended: alternatively Homebrew, [pyenv to set to 3.5](https://github.com/pyenv/pyenv). |
| 14 | + 1. Install and configure your default `python` and pip to exactly Python **3.6**, (recommended in a virtual environment, see next step). |
| 15 | + 1. Recommended: Direct installation, if needed: Download from https://www.python.org/downloads/. Note that the global planner code is currently tested with Python 3.6.7. |
| 16 | + 1. Not recommended: alternatively Homebrew, [pyenv to set to 3.6](https://github.com/pyenv/pyenv). |
19 | 17 | 1. Pick your poison and stick with it or it'll get messy. |
20 | 18 | 1. Confirm your version of Python (`python --version`) & location of the installation (`which python`) is the same for all subsequent steps. |
21 | 19 | 1. Make the virtual environment: |
22 | | - 1. cd to your new circinus repo |
| 20 | + 1. cd to your new SPRINT repo |
23 | 21 | 1. Install virtual environment executable if needed, `pip install virtualenv` |
24 | 22 | 1. Create the virtual environment and install requirements with `./create_virtualenv.sh` |
25 | | - 1. Note that this DOES NOT install the required matlab package needed for many CIRCINUS repos. See below for those instructions |
| 23 | + 1. Note that this DOES NOT install the required matlab package needed for many SPRINT repos. See below for those instructions |
26 | 24 | 1. Activate the virtual environment: `source source_virtualenv` |
27 | | - 1. Install [Matlab python engine](https://www.mathworks.com/help/matlab/matlab_external/install-the-matlab-engine-for-python.html?refresh=true) (assumed Matlab 2017a+ installed). |
| 25 | + 1. Install [Matlab python engine](https://www.mathworks.com/help/matlab/matlab_external/install-the-matlab-engine-for-python.html?refresh=true). Last tested with Matlab 2019b. |
28 | 26 | 1. Ensure the correct version of python is enabled being referenced where you execute this installation command (pyenv is directory specific, for instance). |
29 | 27 | 2. Sudo or admin terminal will be necessary. |
30 | | - 3. after installation, check output of `pip freeze` to see that a line like `matlabengineforpython===R2017a` appears. |
| 28 | + 3. after installation, check output of `pip freeze` to see that a line like `matlabengineforpython===R2019b` appears. |
31 | 29 | 4. install screen. Ubuntu: `sudo apt-get install screen` |
| 30 | + 5. `nano source/ |
| 31 | + _tools/matlab_if/interface.py`, edit `matlab_ver='NOT_SET'` in MatlabIF's init to be `matlab_ver='MATLAB_R2019b'`, according to your version. |
32 | 32 | 1. Install Gurobi: |
33 | 33 | 1. Download and install [Gurobi 8.0.0](http://www.gurobi.com/downloads/gurobi-optimizer) |
34 | | - 1. Acquire and activate Gurobi License ([Academic is free if appropriate](https://user.gurobi.com/download/licenses/free-academic)) |
| 34 | + 1. Acquire and activate Gurobi License ([Academic is free if appropriate](https://www.gurobi.com/downloads/end-user-license-agreement-academic/)) |
35 | 35 | 1. Framework setting: |
36 | 36 | 1. `nano ~/.matplotlib/matplotlibrc` |
37 | 37 | 1. add line: `backend: TkAgg` |
38 | 38 |
|
39 | 39 | # GlobalPlanner-only Demo: |
40 | 40 | 1. Setup: |
41 | | - 1. Init empty folder for outputs: `mkdir CIRCINUS/source/access_global_planner/python_runner/plots` |
42 | | - 1. Ensure scenario referenced by each stage in the pipeline is the same by settings at top of<br> `run_gp.sh` and `run_circinus.sh`:<br> |
| 41 | + 1. Init empty folder for outputs: `mkdir SPRINT/source/access_global_planner/python_runner/plots` |
| 42 | + 1. Ensure scenario referenced by each stage in the pipeline is the same by settings at top of<br> `run_gp.sh` and `run_circinus.sh` (in `SPRINT/scripts`):<br> |
43 | 43 | ``` |
44 | 44 | dir_opt=1day |
45 | 45 | scen_name=zhou2017_comparison |
46 | 46 | dir_opt_params=dlnk_and_xlnk |
47 | 47 | ``` |
48 | 48 | 1. Set solver to Gurobi (alternatively set up CPLEX instead of Gurobi above): |
49 | | - 1. Navigate to: `CIRCINUS/inputs/1day/zhou2017_comparison/dlnk_and_xlnk` (per above settings) |
| 49 | + 1. Navigate to: `SPRINT/inputs/1day/zhou2017_comparison/dlnk_and_xlnk` (per above settings) |
50 | 50 | 1. Modify `const_sim_params_fullday.json` and `gp_general_params_inpus.json`: |
51 | 51 | 1. change value associated with `solver_name` to `gurobi` |
52 | 52 | 1. Run: |
53 | | - 1. Navigate to `CIRCINUS/scripts` |
| 53 | + 1. Navigate to `SPRINT/scripts` |
54 | 54 | 1. Circinus must be run first: `./run_circinus.sh` |
55 | 55 | 1. Copy output file to inputs location: `cp ../source/circinus_orbit_link/python_runner/data_rates_output.json ../inputs/1day/zhou2017_comparison/dlnk_and_xlnk/` |
56 | 56 | 1. Run Global Planner: `./run_gp.sh` |
57 | 57 |
|
58 | 58 | # Simulation Pipeline Demo: |
59 | 59 | 1. Setup: |
60 | 60 | 1. Init empty folder for outputs:<br> |
61 | | - `mkdir CICINUS/source/circinus_sim/python_runner/logs`<br> |
62 | | - `mkdir CICINUS/source/circinus_sim/python_runner/pickles`<br> |
63 | | - `mkdir CICINUS/source/circinus_sim/python_runner/plots`<br> |
64 | | - 1. In `CIRCINUS/inputs/1day/zhou2017_comparison/dlink_and_xlink/const_sim_params_fullday.json`<br> |
| 61 | + `mkdir SPRINT/source/circinus_sim/python_runner/logs`<br> |
| 62 | + `mkdir SPRINT/source/circinus_sim/python_runner/pickles`<br> |
| 63 | + `mkdir SPRINT/source/circinus_sim/python_runner/plots`<br> |
| 64 | + 1. In `SPRINT/inputs/1day/zhou2017_comparison/dlnk_and_xlnk/const_sim_params_fullday.json`<br> |
65 | 65 | set `restore_from_checkpoint` to `false` for (at least) the first run. |
66 | | - 1. Ensure scenario referenced at top of `run_const_sim` references:<br> |
| 66 | + 1. Ensure scenario referenced at top of `scripts/run_const_sim.sh` references:<br> |
67 | 67 | ``` |
68 | 68 | dir_opt=1day |
69 | 69 | scen_name=zhou2017_comparison |
70 | 70 | dir_opt_params=dlnk_and_xlnk |
71 | 71 | ``` |
72 | 72 | 1. Set solver to Gurobi (alternatively set up CPLEX instead of Gurobi above): |
73 | | - 1. Navigate to: `CIRCINUS/inputs/1day/zhou2017_comparison/dlnk_and_xlnk` (per above settings) |
| 73 | + 1. Navigate to: `SPRINT/inputs/1day/zhou2017_comparison/dlnk_and_xlnk` (per above settings) |
74 | 74 | 1. Modify `const_sim_params_fullday.json` and `gp_general_params_inpus.json`: |
75 | 75 | 1. change value associated with `solver_name` to `gurobi` |
76 | 76 | |
77 | 77 | 2. Run: |
78 | | - 1. Navigate to `CIRCINUS/scripts` |
| 78 | + 1. Navigate to `SPRINT/scripts` |
| 79 | + 1. Circinus must be run first: `./run_circinus.sh` |
| 80 | + 1. Copy output file to inputs location: `cp ../source/circinus_orbit_link/python_runner/data_rates_output.json ../inputs/1day/zhou2017_comparison/dlnk_and_xlnk/` |
79 | 81 | 1. Run simulation: `./run_const_sim.sh` |
80 | 82 |
|
81 | 83 | # Updating git submodules |
82 | 84 |
|
83 | 85 | In general you should use the command `git submodule update --recursive`. This checks out all the right commits for all the (possibly multiple layers of) submodules within the top git repo. `git pull` by itself won't do it. |
84 | 86 |
|
85 | | -In CIRCINUS there are actually submodules within the submodules in many cases, so the `--recursive` flag is needed to recursively update all layers of submodules. |
| 87 | +In SPRINT there are actually submodules within the submodules in many cases, so the `--recursive` flag is needed to recursively update all layers of submodules. |
86 | 88 |
|
87 | | -Note that working with git submodules can be a bit confusing. Usually when you update submodules you'll afterwards find the submodule in a detached state, saying something like `HEAD detached at af4512d` at the command line - it's no longer on an existing branch. This is alright, and is related to the fact that git thinks of submodules as a specific commit for a remote repo, and not a branch. However, we have added branch information in .gitmodules file in CIRCINUS that specifies which branch to track for the submodules. In this case you can use the command: `git submodule update --recursive --remote` to update to the most recent commit of the desired branch for that submodule. One problem here though is that when you directly pull the latest commit on a submodule branch with this method, the commit in the repo containing the submodule may not have updated its commit history for that submodule, and this will be reflected with the "new commits" indicator when you run `git status`. Basically, unless all the repos from top to bottom (through all submodules) are committed (within the parent repo) at the latest commit for the specified branch, you'll have an out of date repo somewhere. General rule to keep in mind: as long as `git status` from the top-most repo indicates no changes, your submodules are all checked out on the right commit. |
| 89 | +Note that working with git submodules can be a bit confusing. Usually when you update submodules you'll afterwards find the submodule in a detached state, saying something like `HEAD detached at af4512d` at the command line - it's no longer on an existing branch. This is alright, and is related to the fact that git thinks of submodules as a specific commit for a remote repo, and not a branch. However, we have added branch information in .gitmodules file in SPRINT that specifies which branch to track for the submodules. In this case you can use the command: `git submodule update --recursive --remote` to update to the most recent commit of the desired branch for that submodule. One problem here though is that when you directly pull the latest commit on a submodule branch with this method, the commit in the repo containing the submodule may not have updated its commit history for that submodule, and this will be reflected with the "new commits" indicator when you run `git status`. Basically, unless all the repos from top to bottom (through all submodules) are committed (within the parent repo) at the latest commit for the specified branch, you'll have an out of date repo somewhere. General rule to keep in mind: as long as `git status` from the top-most repo indicates no changes, your submodules are all checked out on the right commit. |
88 | 90 |
|
89 | 91 | For pushing from a detached HEAD to the master branch at origin: `git push origin HEAD:master` |
| 92 | +
|
| 93 | +
|
| 94 | +# History |
| 95 | +SPRINT was initiated as CIRCINUS, by [apollokit](https://github.com/apollokit) |
| 96 | +
|
| 97 | +**C**onstellation |
| 98 | +**I**nvestigation |
| 99 | +**R**epository with |
| 100 | +**C**ommunications, |
| 101 | +**I**nter-agent |
| 102 | +**N**etworking, |
| 103 | +**U**ncertainty, and |
| 104 | +**S**cheduling |
0 commit comments