baronep's profile - activity

I am experiencing very slow builds (and I have been for a while) using catkin_make building the ROS navigation stack. I have tried -DCMAKE_BUILD_TYPE=Release, --use-ninga, ccache, etc but the problem still persists. Specifically, clean builds sometimes take me over an hour on a modern machine (i7 w/ 8GB RAM).

The build process proceeds rather quickly until it seems to stall out at 100%. A quick htop reveals that the culprit is a couple of linking threads that are taking 100% CPU and often are costmap_2d or trajectory planner related.

Has anyone seen this before or have any insight on how to fix this?

Additional Information

OS: Ubuntu 16.04.5 LTS  
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)  
cmake version 3.5.1  
ROS Version: Kinetic 

ROS Install: ROS installed from .debs (desktop-full) and upgraded w/ apt

Steps to reproduce:

mkdir -p ~/test/src  
cd ~/test/src  
catkin_init_workspace  
git clone https://github.com/ros-planning/navigation.git  
git checkout kinetic-devel  
cd ..
catkin_make  
... wait ...

Total Build Time: 22.5 min

The build got to 100% after <5min with the last message printed ... `

[100%] Built target move_base_node 

[100%] Built target costmap_2d_cloud
[100%] Built target costmap_2d_markers
Base path: /home/patrick/test
Source space: /home/patrick/test/src
Build space: /home/patrick/test/build
Devel space: /home/patrick/test/devel
Install space: /home/patrick/test/install
####
#### Running command: "cmake /home/patrick/test/src -DCATKIN_DEVEL_PREFIX=/home/patrick/test/devel -DCMAKE_INSTALL_PREFIX=/home/patrick/test/install -G Unix Makefiles" in "/home/patrick/test/build"
####
####
#### Running command: "make -j6 -l6" in "/home/patrick/test/build"
####

The full output of catkin_make is available here ... https://pastebin.com/ZkFUqU2s

Additional Information - Second Round

Memory consumption during the first 5 minutes of the build ...

patrick@patrick:~/test$ free -mh
              total        used        free      shared  buff/cache   available
Mem:           7.2G        4.1G        222M        1.1G        2.9G        1.5G
Swap:          7.4G        3.2G        4.3G

After reaching the 100% ...

patrick@patrick:~/test$ free -mh
              total        used        free      shared  buff/cache   available
Mem:           7.2G        4.6G        180M        1.2G        2.5G        1.0G
Swap:          7.4G        3.2G        4.2G

It looks like there should be plenty of free memory right?

Also, here are the processes that are "stalling" out in the second 15min of the build ... https://pastebin.com/CDb2qLQs

Specifically, the /usr/bin/ld threads (there are 2, costmap_2d_cloud and costmap_2d_markers) which are taking 100% CPU

I was able to reduce my build time of the navigation stack by 75% by simply disabling the following targets in the costm

Just an observation, if I comment out the costmap_2d_cloud and costmap_2d_markers targets in the CMakelists.txt, my buil

Added additional information above

Slow build time I am experiencing very slow builds (and I have been for a while) using catkin_make building the ROS navi

Slow build time I am experiencing very slow builds (and I have been for a while) using catkin_make building the ROS navi

Added additional information in the post above

Slow build time I am experiencing very slow builds (and I have been for a while) using catkin_make building the ROS navi

Slow build time I am experiencing very slow builds (and I have been for a while) using catkin_make building the ROS navi

Resurrecting this thread a few years later. We are seeing this exact issue running indigo. Does anyone know if this issu

Yes I did. The UM7 (and all accelerometers) are very sensitive to mechanical strain, temperature and a variety of other factors. As such, you need to calibrate the accelerometer fairly frequently. I would suggest the CH Robotics utility to do this

So since posting this question, one of the base local planners has been extended to incorporate the kinodynamic constraints associated with an ackermann drive vehicle. Check out

TEB_LOCAL_PLANNER

I have not managed to get it running too robustly but that may just be a problem with my configuration. Good luck

I am experiencing some odd behavior with my CH Robotics UM7 IMU that I recently purhcased. When the unit is just sitting on the table, it reads 9.2 instead of 9.8 m/s/s for acceleration. I can find instructions on how to zero the rate gyros but nowhere does it mention calibrating the accelerometers. Has anyone run into something similar before with these IMUs or any other unit? I have included an example message

header: 
  seq: 3506
  stamp: 
    secs: 1450136355
    nsecs: 252817294
  frame_id: imu_link
orientation: 
  x: -0.0238677723
  y: 0.0203094265
  z: -0.9840840295
  w: -0.1747282065
orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
angular_velocity: 
  x: -0.000581685356641
  y: -0.000610669209776
  z: 7.07960511619e-05
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration: 
  x: -0.0682945557769
  y: 0.22608049971
  z: 9.21032193719
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

I have been monitoring this interest group and it doesn't look like there has been any movement in the past year.

Not sure if you still need to know, but ...

http://planning.cs.uiuc.edu/node658.html

Theta_dot would be angular.z and phi is steering angle

Let me begin by saying that I have done my obligatory "google-ing" and I know there has been discussion, but I have not found a satisfactory answer and therefore I am asking here ...

I am trying to come up with a solution for path planning for a large, custom UGV (essentially a drive-by-wire utility vehicle). I understand that the ros nav packages generally do not support "Ackermann steering" vehicles. I would like to solicit opinions on how I should proceed, here are a couple paths forward that I can see ...

1) Write custom base_local_planner and base_global_planners which take into account the kinematic constraints of an Ackermann steering vehicle

2) Use a library like MoveIt (is this even possible?)

3) Start from scratch and ditch move_base and everything inside

I see blog posts and such of people using ROS on their steered vehicles, but the documentation of such systems seems to be lacking. Any advice would be well appreciated!

I was able to wireshark the comms using the -x and -v socat options. It looks like the commands being sent by sicktoolbox wrapper are being split up into multiple serial write operations and the laser is not responding. I'm going to try the socat rawer and nodelay options.