Tutorial fixes and additions: build deps, path optimization, Gazebo execution#165
Tutorial fixes and additions: build deps, path optimization, Gazebo execution#165psardin001 wants to merge 24 commits intohumanoid-path-planner:develfrom
Conversation
…celeration - Move obstacle to [0.5, -0.2, 1.2] so it blocks the straight-line path - Add RandomShortcut path optimization before time parameterization - Use maxAcceleration=0.5 for slower, more visible motions - Document that effortScale requires mass/inertia data (disabled for Staubli)
- tutorial_6: Dockerfile, controllers, init.py, launch_sim.py - CMakeLists: install rules for tutorial_6 and tutorial_7 - Makefile: add hpp-core, hpp-manipulation, hpp-exec build targets - README: update tutorial 6 description, add tutorial 7 - tutorial_5: remove duplicate graph.initialize() - run_docker.sh: fix executable permission
robotpkg hpp-core/hpp-manipulation headers were shadowing the devel versions built from source, causing compilation failures in hpp-python. Remove robotpkg packages that overlap with source-built ones from the Dockerfile and add hpp-manipulation-urdf to the Makefile with proper dependency chain, so each package comes from exactly one source. Test build — to be validated.
qgv has no hpp dependency, safe to keep from robotpkg binary. Remove qgv source build from Makefile, add robotpkg-qt5-qgv to Dockerfile.
[tutorial_5] Set constraint graph on problem before optimization
for more information, see https://pre-commit.ci
| TOPPRA typically produces shorter execution times than `SimpleTimeParameterization` because it | ||
| computes the time-optimal solution rather than a conservative polynomial approximation. |
There was a problem hiding this comment.
Actually, TOPPRA does not stop at waypoint, making the velocity discontinuous. We need to better understand how those algorithms work.
Probably, TOPPRA should be used after SplineGradientBased_bezier3.
|
In In this case in by |
| ``` | ||
| cd <your devel directory> | ||
| docker run --gpus all --env DISPLAY --env QT_X11_NO_MITSHM=1 \ | ||
| --volume=/tmp/.X11-unix:/tmp/.X11-unix:rw --net host --privileged \ | ||
| -v .:/home/user/devel --rm --name hpp -it hpp-tutorial-ros2 | ||
| ``` |
There was a problem hiding this comment.
For consistency, I would provide a run_ros_docker.sh script either in the root directory or in this directory.
Co-authored-by: Florent Lamiraux <florent@laas.fr>
Co-authored-by: Florent Lamiraux <florent@laas.fr>
Co-authored-by: Florent Lamiraux <florent@laas.fr>
Co-authored-by: Florent Lamiraux <florent@laas.fr>
for more information, see https://pre-commit.ci
that is on virtually all machines, except corporate ones.
If you are going to re-invent dev-containers, please try those that already exist first : https://containers.dev/ (IMHO, the right class of tool for this problem is a package manager, not a piece of the cloud stack) |
| hpp-toppra_repository=${HPP_REPO} | ||
| hpp-toppra_branch=main | ||
| hpp-toppra_extra_flags= | ||
| toppra_repository=${HPP_REPO} |
There was a problem hiding this comment.
Please explain why do you need to fork
There was a problem hiding this comment.
i approved a commit suggestion by @florent-lamiraux but i must admit i'm not sure why this change was needed. there was also an error in the suggestion so the lines were duplicated. I can clean up and revert the changes.
There was a problem hiding this comment.
Please explain why do you need to fork
For stability reasons. I do not want to depend on the develop branch of a third-party repository belonging to a private person.
Another solution is to create a docker image without sharing volumes, but I do not like this solution. |
I guess that is what they were made for, yes. |
Co-authored-by: Florent Lamiraux <florent@laas.fr>
tutorial_1 : build fixes
qttools5-devdependency and fixhpp-plotdependency chain--system-site-packagesto the python venvqgvfrom robotpkg instead of building from sourcecompilation failures in hpp-python)
tutorial_5 : path optimization
tutorial_6 : Gazebo execution (new)
Execute HPP-generated motions on a simulated robot via
hpp_exec