Closed rayvburn closed 1 year ago
It seems that there are some resources interactions because the same execution of SocialForceModel::computeInteractionForce
can take: 21/15/18/134 microseconds (for 7 static objects).
It seems logical that the thread of a planner is managed by the move_base
node so it can be the source of problems? Maybe it is crucial to make planner finish previous computation step before starting another because move_base
blindly calls for a new velocity command?
This is another interesting example:
[computeForces] full 37 us | sfm 29 us | fis 5 us (processor 0 us, conductor 2 us)
[computeForces] full 41 us | sfm 33 us | fis 4 us (processor 0 us, conductor 2 us)
[SFM us] FUL 535, RST 0, GRBT 0, ITRNL 1, GOBJ 3, ITRSTAT 522 (5 objects), ITRDYN 0 (0 objects), COEFF 0, NONLIN 5
[computeForces] full 566 us | sfm 551 us | fis 9 us (processor 0 us, conductor 4 us)
[computeForces] full 55 us | sfm 43 us | fis 7 us (processor 0 us, conductor 4 us)
[computeForces] full 57 us | sfm 45 us | fis 7 us (processor 0 us, conductor 4 us)
Diffs for debugging:
```diff
diff --git a/src/sfm/social_force_model.cpp b/src/sfm/social_force_model.cpp
index 2fd0a7c..5dcf66c 100644
--- a/src/sfm/social_force_model.cpp
+++ b/src/sfm/social_force_model.cpp
@@ -135,14 +135,18 @@ bool SocialForceModel::computeSocialForce(
std::vector
```diff
diff --git a/src/social_trajectory_generator.cpp b/src/social_trajectory_generator.cpp
index 7ec84bd..1ec12be 100644
--- a/src/social_trajectory_generator.cpp
+++ b/src/social_trajectory_generator.cpp
@@ -8,6 +8,9 @@ namespace hubero_local_planner {
using namespace base_local_planner;
using namespace geometry;
+bool g_just_initialised = false;
+auto g_ts_stg_start = std::chrono::high_resolution_clock::now();
+
SocialTrajectoryGenerator::SocialTrajectoryGenerator():
params_set_(false),
limits_planner_ptr_(nullptr),
@@ -72,6 +75,8 @@ void SocialTrajectoryGenerator::initialise(
const double& robot_mass,
bool discretize_by_time
) {
+ g_just_initialised = true;
+
// save copies for later use
world_model_ = world_model;
vel_local_ = robot_local_vel;
@@ -246,6 +251,11 @@ void SocialTrajectoryGenerator::initialise(
}
bool SocialTrajectoryGenerator::nextTrajectory(Trajectory& traj) {
+ if (g_just_initialised) {
+ g_ts_stg_start = std::chrono::high_resolution_clock::now();
+ g_just_initialised = false;
+ }
+
bool result = false;
if (hasMoreTrajectories()) {
// try to generate a new trajectory, starting with the initial world model given in `initialise`
@@ -258,6 +268,11 @@ bool SocialTrajectoryGenerator::nextTrajectory(Trajectory& traj) {
}
}
next_sample_index_++;
+ if (!hasMoreTrajectories()) {
+ auto ts_full_end = std::chrono::high_resolution_clock::now();
+ auto full_time = std::chrono::duration_cast
SocialTrajectoryGenerator::computeForces
timing:
```diff
diff --git a/src/social_trajectory_generator.cpp b/src/social_trajectory_generator.cpp
index 7ec84bd..e9b0a78 100644
--- a/src/social_trajectory_generator.cpp
+++ b/src/social_trajectory_generator.cpp
@@ -570,6 +570,8 @@ void SocialTrajectoryGenerator::computeForces(
geometry::Vector& force_human_action,
bool update_motion_data
) {
+ auto ts_full_start = std::chrono::high_resolution_clock::now();
+
// store vectors of poses of closest points between robot and other objects; makes use out of obstacles
// representation (extracted from costmap) and robot's footprint;
// these, in fact, are used only for visualisation
@@ -603,12 +605,14 @@ void SocialTrajectoryGenerator::computeForces(
social_conductor_.setEquationParameters(sample_amplifiers.fis_as_amplifier);
// begin calculations
+ auto ts_sfm_start = std::chrono::high_resolution_clock::now();
sfm_.computeSocialForce(
world_model,
dt,
meaningful_interaction_static,
meaningful_interaction_dynamic
);
+ auto ts_sfm_end = std::chrono::high_resolution_clock::now();
// actual `social` vector
geometry::Vector human_action_force;
@@ -616,6 +620,11 @@ void SocialTrajectoryGenerator::computeForces(
std::vector
Note that all above timings are for system clock, not for ROS time that the move_base
uses.
Timing of
SocialTrajectoryGenerator::computeForces
:whereas generation of all trajectories (checked in the last call to
SocialTrajectoryGenerator::nextTrajectory
):So main thing is checking why SFM calculations take so long