when pids values cause errors that crash system
When PID values are changes via rviz dynamic plugin to values that are too large both rviz and gazebo ros plugin crash. The model attemps to jump out of bounds ...but error should be handled more gracefully , yes?
for ros gazebo plugin:
[ INFO] [1379439029.301559081, 1.676000000]: Loaded gazebo_ros_control.
gzclient: /build/buildd/ogre-1.7.4+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion `(min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.
Aborted (core dumped)
and for rviz move-base
python: /build/buildd/ogre-1.7.4+dfsg1/OgreMain/include/OgreAxisAlignedBox.h:252: void Ogre::AxisAlignedBox::setExtents(const Ogre::Vector3&, const Ogre::Vector3&): Assertion `(min.x <= max.x && min.y <= max.y && min.z <= max.z) && "The minimum corner of the box must be less than or equal to maximum corner"' failed.
[rqt_gui-1] process has died [pid 7495, exit code -6, cmd /opt/ros/hydro/lib/rqt_gui/rqt_gui __name:=rqt_gui __log:=/home/viki/.ros/log/c890f9ee-1fbe-11e3-807c-28cfe95d78b1/rqt_gui-1.log].
log file: /home/viki/.ros/log/c890f9ee-1fbe-11e3-807c-28cfe95d78b1/rqt_gui-1*.log
move_base: /usr/include/pcl-1.7/pcl/conversions.h:247: void pcl::toPCLPointCloud2(const pcl::PointCloud<PointT>&, pcl::PCLPointCloud2&) [with PointT = base_local_planner::MapGridCostPoint]: Assertion `cloud.points.size () == cloud.width * cloud.height' failed.
[move_base-7] process has died [pid 7590, exit code -6, cmd /opt/ros/hydro/lib/move_base/move_base __name:=move_base __log:=/home/viki/.ros/log/c890f9ee-1fbe-11e3-807c-28cfe95d78b1/move_base-7.log].
log file: /home/viki/.ros/log/c890f9ee-1fbe-11e3-807c-28cfe95d78b1/move_base-7*.log
TrajectoryPlannerROS:
# for details see: http://www.ros.org/wiki/base_local_planner
max_vel_x: 5
max_trans_vel: 5
min_vel_x: 3
min_trans_vel: 3
max_rotational_vel: 1.0 # 0.1 rad/sec = 5.7 degree/sec
min_in_place_rotational_vel: 0.1
acc_lim_th: 2.5
acc_lim_x: 2.5
acc_lim_y: 0
Control yaml
rrbot:
# Publish all joint states -----------------------------------
joint_state_controller:s
type: joint_state_controller/JointStateController
publish_rate: 15
# Position Controllers ---------------------------------------
joint1_position_controller:
type: effort_controllers/JointVelocityController
joint: joint1
pid: {p: 5, i: 5, d: 5}
joint2_position_controller:
type: effort_controllers/JointVelocityController
joint: joint2
pid: {p: 5, i: 5, d: 5}
In urdf:
<transmission name="tran1">
<type>transmission_interface/SimpleTransmission</type>
<joint name="joint1"/>
<actuator name="motor1">
<hardwareInterface>EffortJointInterface</hardwareInterface>
<mechanicalReduction>1</mechanicalReduction>
</actuator>
</transmission>
<transmission name="tran2">
<type>transmission_interface/SimpleTransmission</type>
<joint name="joint2"/>
<actuator name="motor2">
<hardwareInterface>EffortJointInterface</hardwareInterface>
<mechanicalReduction>1</mechanicalReduction>
</actuator>
</transmission>
For Gazebo in model.sdf
<plugin name="ros_control" filename="libgazebo_ros_control.so">
<robotNamespace>/rrbot</robotNamespace>
<robotSimType>gazebo_ros_control/DefaultRobotHWSim</robotSimType>
</plugin>
Asked by rnunziata on 2013-09-17 07:51:15 UTC
Answers
There is no way a PID instance can determine if a set of gains will make a specific robot setup unstable or not, as the outcome depends on many external factors like mechanism dynamics (inertia, friction, interactions between bodies) and the simulation timestep. Your best bet is to start with a reasonable approximation of your robot dynamics, and then start tuning your gains, from lower to higher values. I recognize that the process can be frustrating and time-consuming at times, especially when simulation-specific factors come into play.
Asked by Adolfo Rodriguez T on 2013-09-17 21:26:57 UTC
Comments
This I understand quite well....its that if the system crashes as I try different pid setting then it makes convergence almost impossible in a testing environment.
Asked by rnunziata on 2013-09-18 01:27:17 UTC
I get your question now. The unstable simulation is propagating nonsense values that trigger an assertion in rviz code. I agree that a more graceful error handling would be desirable. Can you get a backtrace of the crash?.
Asked by Adolfo Rodriguez T on 2013-09-18 02:15:17 UTC
I can reproduce the crash...but I need to know what information..logs, dumps,...etc you need and how to generate them if debug setting must be set. Not sure what you mean by backtrace , trace report?
Asked by rnunziata on 2013-09-18 02:20:55 UTC
Build rviz with debug symbols and run it with a debugger like gdb, trigger the crash and get a backtrace (bt), which will give you the call stack when the crash happened. It will hopefully contain useful information.
Asked by Adolfo Rodriguez T on 2013-09-18 03:41:11 UTC
I set up my launch file to invoke rqt and rviz independently. So not to use the plugin and specified the Debug on the rviz node. In the rviz package in my catkin src I created a rosconfig.cmake file and place in it the line set(ROS_BUILD_TYPE Debug) When I run my launch file the dbg window opens but it says no debug symbols found in catkin/devel...etc.
Is this not the correct way to compile with debug? The compile has warnings but no errors.
Asked by rnunziata on 2013-09-18 06:48:09 UTC
This maybe become moot topic as I am unable to replicate error. I have made many changes to my nav config files and even my tf and cmd publisher. Sorry. But I am still would like to know how to set debug in compile for future reference. If I run into it again I will be ready.
Asked by rnunziata on 2013-09-18 07:05:39 UTC
I would like to see a better choice list for closing items of this nature. I will close under too localized.
Asked by rnunziata on 2013-09-18 08:08:40 UTC
If using catkin, set the standard cmake variable CMAKE_BUILD_TYPE; if using rosbuild set ROS_BUILD_TYPE, as you mention above. Default build types containing debug symbols are: Debug or RelWithDebugInfo
Asked by Adolfo Rodriguez T on 2013-09-18 21:19:07 UTC
Comments
What values are you sending? Can you provide instructions on how to reproduce?
Asked by tfoote on 2013-09-17 08:18:13 UTC
added configuration.....just increase pid to some large number. Was trying to get cmdvel up past unit value of 1 inorder to move.
Asked by rnunziata on 2013-09-17 13:17:37 UTC