If different dt are considered accross experiments, the definition of the mission in the YAML file has to change. To avoid this, we should use the time interval between waypoints instead of nodes. Nodes should be calculated when filling the mission in the problem.

Right now, if new objects and methods are added to the API along with the corresponding unittest, you need to install the library to so the test can be ran.

Do the unittests for this method at every controller and Mission.

YAML parser should be added in order to tune the optimal control problem parameters without having to compile after each modification

Due to its close dependency on Crocoddyl, the library started using boost smart pointers.

Since the minimum required C++ version for Eagle-MPC is C++11, these could be moved to std and only use the boost library when strictly necessary.

Create the unittests related to the python bindings of the waypoint class.

The idea behind a trajectory is that it only contains the information related to the trajectory itself but has nothing to do with how this is solved. The information of the trajectory is specified in the YAML file.

This is why when creating the problem we have to pass the parameters related to solving the problem (time step, integrator method, and boolean indicating whether the solver we want to use is squashed based).

There might be cases where we might only want to work via YAML files. Thus, it might be useful to have the possibility to specify the solving parameters in the YAML file too.

Solution proposed:

• If the YAML file DOES contain the solving parameters, fill a struct inside Trajectory with these parameters. Then overload the createProblem() method with no arguments. This method will take the solving parameters from the struct.
• If the YAML file DOES NOT contain the solving parameters, throw an error if the createProblem() method is called, since the solving parameters structure will be empty.

Bindings should be created for this class

I was fascinated by your excellent work on UAM control ('Full-Body Torque-Level Nonlinear Model Predictive Control for Aerial Manipulation') and wanted to reproduce your open-source code.

According to the instructions you provided here, I have installed all the dependencies and then encountered a fatal error during the ROS compilation process, which suggested that a key file named "path.h" was missing from the specified folder.

The compilation process is shown in the following figure.

Looking forward to your reply, thank you very much!

CostModel are deprecated

Also constructors of MultiCopterActuatuionModel

Create the unittests related to the python bindings of the mission class.

This is the problem that we should solve for the first approach of the mpc_main class working with both controllers (low_level_controller and trajectory geneerator):

• Trajectory generator: solve an ocp for a given mission when constructing the mpc_main class
• The state trajectory output by the trajectory generator will be fed in the low_level_controller
• Mission in the traj. generator has to end with a hover state, since when the low_level_controller runs out of reference state, hover states will be added at the end.

The current LOG messages inside the code are too wordy that are useless when running the code.

There should be different log levels.

Also, if logging has to be done properly, we should consider using external tools such as Boost logger or spdlog.

The callbackVerbose() is not useful when use it, e.g., in the MPC case since it forbids you to see other terminal messages. Instead, some safety checks should be added to warn about possible bas solutions (e.g. bad stopping value, max iterationts reached, etc.)

The ability to give an interpolated trajectory should be inside the class. Inside, via switch case, we should be able to use different methods, e.g. SE3 or R3+SO3.

There are some methods being used from Crocoddyl that are deprecated. Change them to the new ones

Create the unittests related to the python bindings of the waypoint class.

Instead of having the mpc main with a trajectoryGenerator and the controller, this issue aim is to add the trajectory generator as a part of the controller. Therefore, the MPCMain will only have one controller.

Configure "make uninstall"

1. Expose all the methods of low-level-mpc-controller class
2. Create the bindings unittest

Instead of stating a state reference trajectory for every node, follow the same philosophy as with the trajectory generator.

Now, the hovering is not handled well in the picwise controller. When hovering, all nodes should have terminal weights

Python bindings:

• WayPoint
• McBaseParams
• Mission
• TrajecotryGeneration

Instead of having to pass the yaml server as an object to open specific yaml file. We better do this inside the corresponding methods and pass the path to the method.

Variables of std::size_t are used as a substitute for uint. It should only be used where it specifies a dimension and use, e.g. uint64_t instead for all other uses.

Following the idea of the low-level-controller, unittest for trajectory generator should be done

Unittest for the low-level-controller is required

Ability to use internal gains with any mpc controller. This should be probably handled by MpcMain

Currently, you need to set absolute paths in the YAML files. This is a bad approach since every time the repo is downloaded, the user must set the absolute paths of all the existing YAML files.

Proposed approach:

• Set a default path for YAML files (installed via include)
• In the YAML file:
  • A single name indicates this file is located in the default location
  • Otherwise, it will be considered as an abosulte path

There are some duplicated exposed classes from Crocoddyl

Yaml parser folder should be added as a submodule. Therefore, a separate repo should be created for yaml_parser.

Right now all gains associated to the optimal control problem of any controller based on the ocp-base class are hardcoded. Thus, after any change we need to recompile, and it takes too long due to template based Crocoddyl lib.

This parameters should be read from a yaml file.

1. Expose all the methods of trajectory-generation class
2. Create the bindings unittest

Right now we have the following YAML folder structure:

YAML folder:

• mpc (mpc controller tunnings for eahc kind of robot)
  • robot1_mpc1.yaml
  • robot1_mpc2.yaml
  • robot2_mpc1.yaml
• multicopter (platform parameters)
  • robot1.yaml
  • robot2.yaml
• trajectories
  - robot1_trajectory1.yaml
  - robot1_trajectory2.yaml
  - robot2_trajectory1.yaml

Since all yaml file names contain the robot name, we could simplify this by doing:

YAML folder:

• robot 1:
  • mpc
    • mpc1.yaml
    • mpc2.yaml
  • platform
    • platform.yaml
  • trajectories
    • trajectory1.yaml
    • trajectory2.yaml
• robot 2:
  • mpc
    • mpc1.yaml
  • platform
    • platform.yaml
  • trajectories
    • trajectory1.yaml