[DiffDrive] Test fixing #318
Conversation
avoid testing on a default constructed message.
|
@bmagyar @efernandez Hola. |
|
The failing CI job may again be due to the same issue. ros_controllers/diff_drive_controller/test/diff_drive_multiple_cmd_vel_publishers_test.cpp:58
Expected: (fabs(roll_new - roll_old)) < (EPS), actual: nan vs 0.01 |
|
I've restarted the jobs again. Please try adding the same fix to all the tests that seem affected. We shall see. |
|
This should fix #292 |
|
This does not fully solves #292 but seems to help - over more than a dozen run this particular test did not fail again. const ros::Duration actual_elapsed = new_odom.header.stamp - old_odom.header.stamp;
const double expected_traveled = cmd_vel.linear.x * actual_elapsed;
...
EXPECT_NEAR(expected_traveled, sqrt(dx*dx + dy*dy), POSITION_TOLERANCE);@bmagyar What's your take about that ?? |
|
Currently failing the kind of issue I was trying to describe in my previous comment: [diff_drive_controller.rosunit-skid_steer_test/testTurn][FAILURE]---------------
/root/catkin_ws/src/ros_controllers/diff_drive_controller/test/diff_drive_test.cpp:124
The difference between fabs(new_odom.twist.twist.angular.z) and 3.14159265358979323846/10.0 is 0.1029772675980104,
which exceeds EPS, where fabs(new_odom.twist.twist.angular.z) evaluates to 0.41713653295698971,
3.14159265358979323846/10.0 evaluates to 0.31415926535897931,
and EPS evaluates to 0.01. |
|
That's a very good idea and would explain why we only experience this I
stability on Travis. Thanks for looking into this.
…On Mar 14, 2018 7:57 PM, "Jeremie Deray" ***@***.***> wrote:
This does not fully solves #292
<#292> but seems to
help - over more than a dozen run this particular test did not fail again.
There are other issues, one taking place in tests where a
ros::Duration::sleep is used to wait for the controller to execute an
expected trajectory - e.g. diff_drive_test - testForward
<https://github.com/ros-controls/ros_controllers/blob/kinetic-devel/diff_drive_controller/test/diff_drive_test.cpp#L61>.
Those tests seems to fail by a very little overshoot. I'll try to do some
monitoring tomorrow, my best guess by now is that the thread may wake up a
little too late (machine under heavy load, cosmic ray...), thus the
controller does 1/2/3... more iterations of its loop than expected. A
possible fix would be that the expected trajectory/distance traveled ain't
a hard-coded value. E.g. from the link above:
const ros::Duration actual_elapsed = new_odom.header.stamp - old_odom.header.stamp;const double expected_traveled = cmd_vel.linear.x * actual_elapsed;
...EXPECT_NEAR(expected_traveled, sqrt(dx*dx + dy*dy), POSITION_TOLERANCE);
@bmagyar <https://github.com/bmagyar> What's your take about that ??
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADXH4cqHF4L2X5OT4xT-wZRnayvC3iN9ks5teXYOgaJpZM4SqntQ>
.
|
| // check if the robot traveled 1 meter in XY plane, changes in z should be ~~0 | ||
| const double dx = new_odom.pose.pose.position.x - old_odom.pose.pose.position.x; | ||
| const double dy = new_odom.pose.pose.position.y - old_odom.pose.pose.position.y; | ||
| const double dz = new_odom.pose.pose.position.z - old_odom.pose.pose.position.z; | ||
| EXPECT_NEAR(sqrt(dx*dx + dy*dy), 1.0, POSITION_TOLERANCE); | ||
| EXPECT_NEAR(sqrt(dx*dx + dy*dy), expected_distance, POSITION_TOLERANCE); |
| Diffbot<> robot; | ||
| ROS_WARN_STREAM("period: " << robot.getPeriod().toSec()); | ||
| controller_manager::ControllerManager cm(&robot, nh); | ||
|
|
||
| ros::Rate rate(1.0 / robot.getPeriod().toSec()); | ||
| ros::Publisher clock_publisher = nh.advertise<rosgraph_msgs::Clock>("/clock", 1); |
There was a problem hiding this comment.
@bmagyar @efernandez The simulation now publishes its own clock which should fix time/integration erratic failures.
|
|
|
I kept restarting the travis jobs in the last 2 days. We have now around 10 runs when there was no failure from the patched up tests, nice job! |
|
👍 |
|
You're welcome ;) |
- Same code in ros-controls#318
Fix time-sensitive tests of diff_drive_controller
Fixing diff_drive_odom_frame_test.
In some cases the test
testOdomTopicmight be callinggetLastOdom()before any odom message is received. It thus evaluate a default constructed msg.I also turned the
whileloop that wait for the controller to be up into a function. It also ensure thatros::ok()otherwise launching manually a test without the controller get stuck in an infinite loop...