Update for rtmros common test

[snozawa]

Update for rtmros common test.

[snozawa]

Travis passed.

Fixed problems

• HrpsysSeqStateROSBridge variable initialization (moved from Initialize prev_odom_acquired flag. #876)
• Reduce unnecessary sleep in sensor_ros_bridge.py
• Update travis to include PIP problem (Initialize prev_odom_acquired flag. #876 (comment), https://github.com/jsk-ros-pkg/jsk_travis/pull/208/files) and mongodb setting (Purge mongodb setting. jsk-ros-pkg/jsk_travis#216)
• Dirty workaround for test-samplerobot.test's hztest (hztest sometimes fails #877 (comment))

[snozawa]

Dirty workaround for test-samplerobot.test's hztest (#877 (comment))

Debug memo

I could reproduce too small hztest problem on my PCs.
I increased wait_time and test_duration, but problem not solved.

I doubted frequency of hrpsys-simulator or HrpsyseqStateROSBridge.
I added usleep to both of them (like usleep(10000)) and HrpsysSeqStateROSBridge [Hz] printing became small.
But, problem cannot be reproduced by this usleep.

[k-okada]

On Wed, Dec 16, 2015 at 9:18 PM, Shunichi Nozawa [email protected]
wrote:

I added usleep to both of them (like usleep(10000)) and
HrpsysSeqStateROSBridge [Hz] printing became small.
But, problem cannot be reproduced by this usleep.

do you mean adding usleep decrease Hz messe, but it did not fail on hztest?

◉ Kei Okada

[snozawa]

Sorry for late.

do you mean adding usleep decrease Hz messe, but it did not fail on hztest?

Yes.
[Hz] print message from HrpsysSeqStateROSBridge is real-time Hz, which is different from simulation-time's Hz.
Even if real-time Hz is slow, hztest succeeded because it seem to check clock's time originally derived from hrpsys-simulator.

[k-okada]

it is called 'Wall-Clock' (https://wiki.ros.org/Clock) and when you use
hrpsys-simulator, ros uses as same clock as hrpsys simuation cllock as
"simulaated clock", whcih was returnd by ros::Time::now()
And I think hz test checks on "simulated clock", sso adding sleep may not
work.

◉ Kei Okada

On Mon, Dec 21, 2015 at 2:09 PM, Shunichi Nozawa [email protected]
wrote:

Sorry for late.

do you mean adding usleep decrease Hz messe, but it did not fail on hztest?

Yes.
[Hz] print message from HrpsysSeqStateROSBridge is real-time Hz, which is
different from simulation-time's Hz.
Even if real-time Hz is slow, hztest succeeded because it seem to check
clock's time originally derived from hrpsys-simulator.

—
Reply to this email directly or view it on GitHub
#879 (comment)
.

[snozawa]

it is called 'Wall-Clock' (https://wiki.ros.org/Clock) and when you use hrpsys-simulator, ros uses as same clock as hrpsys simuation cllock as "simulaated clock", whcih was returnd by ros::Time::now() And I think hz test checks on "simulated clock", sso adding sleep may not work.

Yes, I thought so.
So I wanted to confirm some kinds of slowness of hrpsys-simulator or HrpsysSeqStateROSBridge execution does not influence on hztest error thanks for Wall-Clock.
#879 (comment) shows hztest error is not derived from slowness of execution.