pepms / eagle-mpc Goto Github PK
View Code? Open in Web Editor NEWEagleMPC is a model predictive control & optimal control library for unmanned aerial manipulators (UAMs)
License: BSD 3-Clause "New" or "Revised" License
EagleMPC is a model predictive control & optimal control library for unmanned aerial manipulators (UAMs)
License: BSD 3-Clause "New" or "Revised" License
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:
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.
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.
Yaml parser folder should be added as a submodule. Therefore, a separate repo should be created for yaml_parser.
Do the unittests for this method at every controller and Mission.
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.)
Create the unittests related to the python bindings of the waypoint class.
Bindings should be created for this class
Now, the hovering is not handled well in the picwise controller. When hovering, all nodes should have terminal weights
Ability to use internal gains with any mpc controller. This should be probably handled by MpcMain
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.
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.
There are some methods being used from Crocoddyl that are deprecated. Change them to the new ones
Unittest for the low-level-controller is required
Python bindings:
YAML parser should be added in order to tune the optimal control problem parameters without having to compile after each modification
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.
Instead of stating a state reference trajectory for every node, follow the same philosophy as with the trajectory generator.
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:
createProblem()
method with no arguments. This method will take the solving parameters from the struct.createProblem()
method is called, since the solving parameters structure will be empty.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.
Following the idea of the low-level-controller, unittest for trajectory generator should be done
Configure "make uninstall"
CostModel are deprecated
Also constructors of MultiCopterActuatuionModel
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):
There are some duplicated exposed classes from Crocoddyl
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.
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!
Create the unittests related to the python bindings of the mission class.
Create the unittests related to the python bindings of the waypoint class.
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.
Right now we have the following YAML folder structure:
YAML folder:
Since all yaml
file names contain the robot name, we could simplify this by doing:
YAML folder:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.