rayvburn / hubero Goto Github PK

Once lying task was requested and actor has already finished standing up, a moment od "delay" is required to generate a valid navigation plan. Also, close goals will most likely be aborted.

This is not avoidable if perception is operational while actor is lying. The cause of such behaviour is wide FOV of lidar "attached" to actor legs.

• waiting for a fixed version to become available online
• https://www.jamris.org/index.php/JAMRIS/article/view/664
• BibTeX (check month and title (- -> --))

@article{karwowski2021hubero,
title={HuBeRo - a Framework to Simulate Human Behaviour in Robot Research},
volume={15},
url={https://www.jamris.org/index.php/JAMRIS/article/view/664},
DOI={10.14313/JAMRIS/1-2021/4},
number={1},
journal={Journal of Automation, Mobile Robotics and Intelligent Systems},
author={Karwowski, Jarosław and Dudek, Wojciech and Węgierek, Maciej and Winiarski, Tomasz},
year={2021},
month={Jul.},
pages={31-38}
}

E.g. SitDown should not consist of MoveToGoal -> SitDown -> Sitting -> StandingUp -> Standing. A better approach would use MoveToGoal, SitDown and StandUp (separately) - user has better control over scenario execution then.

Currently - hard-coded values, referenced to ground. Transitions are implemented but may look awkward while standing up etc.

Lack of possibility to mark template method as virtual led to create an ugly workaround

Symptom: base class request methods got called each time, instead of derived class'

To avoid a need of copying whole world files only to place actors in other locations

Currently, in the scenario code one must call

while(ros::ok() && <TaskFeedbackType> == <EXPECTED_FEEDBACK>) {
	std::this_thread::sleep_for(std::chrono::milliseconds(1));
	ros::spinOnce();
}

there are those elaborate spencer_tracking_msgs and typical people_msgs

ref: http://wiki.ros.org/actionlib_tutorials/Tutorials/Writing%20a%20Simple%20Action%20Client%20%28Python%29

Appeared first on Ubuntu 18:

CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (PkgConfig)
  does not match the name of the calling package (gazebo).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPkgConfig.cmake:99 (find_package_handle_standard_args)
  /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:30 (include)
  CMakeLists.txt:11 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindBoost.cmake:1511 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "chrono" will no longer be dereferenced when the
  policy is set to NEW.  Since the policy is not set the OLD behavior will be
  used.
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindBoost.cmake:2117 (_Boost_MISSING_DEPENDENCIES)
  /usr/share/OGRE/cmake/modules/FindOGRE.cmake:318 (find_package)
  /usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:175 (find_package)
  CMakeLists.txt:11 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

Currently, first attempt to plan path to a static object (that is shown in the occupancy grid used for planning) usually fails, so it takes Actor::GOAL_UPDATE_PERIOD_DEFAULT seconds until next planning triggers (usually successful).

This error happens when hubero_bringup_gazebo_ros/CMakeLists.txt tries to find hubero_gazebo package:

find_package(catkin REQUIRED COMPONENTS
  hubero_gazebo
  hubero_ros
)

Build error descrption:

CMake Error at <PATH_TO_WORKSPACE>/devel/share/hubero_gazebo/cmake/hubero_gazeboConfig.cmake:173 (message):
  Project 'hubero_bringup_gazebo_ros' tried to find library
  'hubero_gazebo_actor'.  The library is neither a target nor built/installed
  properly.  Did you compile project 'hubero_gazebo'? Did you find_package()
  it before the subdirectory containing its code is included?
Call Stack (most recent call first):
  /opt/ros/kinetic/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
  CMakeLists.txt:9 (find_package)

In fact libhubero_gazebo_actor.so is generated, but is located in src/hubero/hubero_gazebo/lib directory. The problem is that I could not manage to add this directory to hubero_gazebo_LIBRARY_DIRS.

I've tried to put into hubero_gazebo/CMakeLists.txt:

link_directories(${CMAKE_SOURCE_DIR}/lib)
set(CMAKE_PREFIX_PATH "${CMAKE_PREFIX_PATH} ${CMAKE_SOURCE_DIR}/lib")
set(CMAKE_LIBRARY_PATH "${CMAKE_LIBRARY_PATH} ${CMAKE_SOURCE_DIR}/lib")

and then in hubero_bringup_gazebo_ros/CMakeLists.txt:

find_package(catkin REQUIRED COMPONENTS
  hubero_gazebo
  hubero_ros
)
# ...
link_directories(${hubero_gazebo_LIBRARY_DIRS})

and hubero_bringup_gazebo_ros/package.xml:

  <build_depend>hubero_gazebo</build_depend>
  <build_depend>hubero_ros</build_depend>

did not help.

Note that .so file path relative to package src is needed to extend GAZEBO_PLUGIN_PATH env variable. So it's not handy to export the library somewhere into devel/.private/....

Possible workaround: PAL, for example, do not place any packages to be found in CMakeLists example. Then, there is no need to find libraries, but lack of any package is detected when trying to launch an executable.

Encountered in Gazebo version 9 - console is flooded with:

[Wrn] [Model.cc:732] Model::SetAngularAccel() is deprecated and has no effect. Use Link::SetTorque() on the link directly instead. 
[Wrn] [Link.cc:747] Link::SetAngularAccel() is deprecated and has no effect. Use Link::SetTorque() instead.

Animations are triggered properly but freeze on the first "frame"

• Gazebo-related
• ROS-related
• core/common packages
• gazebo-ros-bringup

• make a shared core library

• prepare markdown with separate files first

Header:

/// Thread that provides callbacks to be processed (otherwise task requests won't be recognized by ActionServer)
std::thread callback_spinner_;

Source (ctor):

	callback_spinner_ = std::thread([this]() {
		// single-threaded spinning
		ros::spin();
	});

It does not compile ATM:

• ROS Melodic,
• gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

new task objectives will be requested properly but there is no trigger that could update navigation goal in, e.g., TaskRequestRos

Create NavigationRos::updateGoalToClosestReachablePose() method that will internally compute plan to the goal in a separate thread - this will prevent from perdiodic freezes while calling ROS service

Camera sensors disabled until working solution for PCL conversion is found.

Relates to #21

differentiate actors between each others

• evaluate whether there is some correlation between trajectory execution duration and actual poses
  • if after few seconds the pose resets then the idea fails
• implement publishing people data according to the people_msgs/People message
• implement similar mechanism for static models from Gazebo - Standing person and Walking person

Green sofas were somehow moved onto each other. Location difference is noticeable by comparison of world and some old map.

Despite of proper execution of, e.g., MoveToGoal, action status returned is PREEMPTED.

Details: TaskRequestRos::actionCbHandler template method (defined in header)

Navigation stack's odometry requires Twist to be defined in actor (robot base) coordinates

Example - publish goal to lie down action before Gazebo launched:

rostopic pub --once /hubero/actor4/task/lie_down/goal hubero_ros_msgs/LieDownActionGoal "header:
  seq: 0
  stamp:
    secs: 0
    nsecs: 0
  frame_id: 'world'
goal_id:
  stamp:
    secs: 0
    nsecs: 0
  id: ''
goal:
  frame: 'world'
  pos:
    x: 0.5
    y: 6.0
    z: 0.0
  yaw: 0.0"

currently it's hard-coded to lie down on the ground: AnimationControlGazebo::adjustPose, ANIMATION_LIE_DOWN section

also, create a node that aggregates human messages and republishes it according to new message types (for social navigation)

In dynamic scenarios, actors might sometimes be stuck forever.

Possible solution: create a thread that takes care of tracking the velocity command's validity.

Usually the delay of a blocked planning service is 500 ms. Error:

[ERROR] [1696377720.614312985, 52.176000000]: move_base must be in an inactive state to make a plan for an external user

Each package reports

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at CMakeLists.txt:7 (cmake_policy):
  The OLD behavior for policy CMP0054 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at /usr/src/googletest/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at /usr/src/googletest/googlemock/CMakeLists.txt:41 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at /usr/src/googletest/googletest/CMakeLists.txt:48 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

How to reproduce:

Launch:

roslaunch hubero_bringup_gazebo_ros example.launch world:=parking rviz:=false

First, call:

rostopic pub --once /hubero/actor4/task/lie_down/goal hubero_ros_msgs/LieDownActionGoal "header:
  seq: 0
  stamp:
    secs: 0
    nsecs: 0
  frame_id: 'world'
goal_id:
  stamp:    
    secs: 0
    nsecs: 0
  id: ''
goal:
  frame: 'world'
  pos:
    x: 3.5
    y: 6.0
    z: 0.0
  yaw: 0.0"

and when actor is already lying, call:

rostopic pub --once /hubero/actor4/task/move_to_goal/goal hubero_ros_msgs/MoveToGoalActionGoal "header:
  seq: 0
  stamp:
    secs: 0
    nsecs: 0
  frame_id: 'world'
goal_id:
  stamp: now
  id: ''
goal:
  frame: 'world'
  pos:
    x: 5.50
    y: 6.0
    z: 0.0"

Currently, just use actions with caution - when actor is lying, call first:

rostopic pub --once /hubero/actor4/task/lie_down/cancel actionlib_msgs/GoalID "stamp:
  secs: 0
  nsecs: 0
id: ''" 

e.g. https://github.com/ros-tooling/action-ros-ci