Physics lockstep for all sensors

[mabelzhang]

Part of issue #2736. Builds on top of #2746 (can't target that branch because that's on a fork. Should merge that one first).

Extends the physics lockstep from CameraSensor in #2746 to all sensors.

All non-rendering sensors are covered by new code in Sensor.

Rendering sensors that do not inherit from CameraSensor are GpuRaySensor and MultiCameraSensor. Each of these classes has new variables renderNeeded and nextRenderingTime, which are updated by new methods (SetActive(), PrerenderEnded(), NeedsUpdate(), NextRequiredTimestamp(), ResetLastUpdateTime()) and existing method Render().

Because of these new members, while it's possible to check whether a sensor is a rendering one via this->dataPtr->category == IMAGE and put everything in Sensor, I decided to only have these members in the rendering sensor classes, even if it means the methods look mostly similar (but not exactly the same because the actual sensor variable is different) across all 3 rendering sensors.

Tests for strict rate have been added to:
INTEGRATION_camera_sensor
INTEGRATION_gpu_laser
INTEGRATION_multicamera_sensor
INTEGRATION_logical_camera_sensor
INTEGRATION_contact_sensor
INTEGRATION_laser
INTEGRATION_imu
INTEGRATION_transceiver

[mabelzhang]

Sorry about the fidgeting above. The 5 latest commits weren't showing up in the Draft state for some reason. Closing and reopening the PR made them show up.

[mabelzhang]

This is ready for review.
The only thing pending is I can't quite get the new transceiver test to work yet. I have to manually call Update() for some reason, otherwise it hangs. It doesn't Update() automatically when physics is unpaused... Is there something special about this sensor or am I missing a flag? I call Init(), SetActive(true) on the sensor, and then I call SetPause(false). No messages come in. I will look more into this.

[mabelzhang]

Now that we aren't using the SDF tag, some .world files can be removed. They are mostly copies of existing ones except the <update_rate> tag, which we can set via SetUpdateRate(). I'll change that.

[mabelzhang]

Transceiver test is done.
I've added all the sensor tests that are currently being tested with a world file.

I tried to eliminate some new .world SDF files to reduce the line diffs, but I couldn't get them to pass the tests. With laser, it seems calling SetUpdateRate() has no effect, maybe the sensors are already completely loaded after Load()? Logical camera I suspect will have the same issue. With contact sensor, it got a null pointer for the sensor whenever I switched to the existing world file, which is only different from the one I added by one line, the <update_rate> line. I can't see a reason it'd get a null pointer for the sensor for one file but not the other. Most peculiar.

So it seems the most solid to test with the new .world files specifying a large <update_rate> directly. The other new world files (gpu laser, imu, multicamera) are very stripped down from the original ones, so I think these are good to keep anyway.

[iche033]

I wonder if the update rate issue you are experiencing is due to the same problem mentioned in pull request #2784. I can see that bug occurring if you are calling SetUpdateRate with a larger value than what's defined in SDF since the sensor manager's update loop is being throttled by the original rate.

[iche033]

changes look good to me. I tested the remaining rendering sensors (depth, gpu ray, and multicamera) and confirm that lockstep is working. There is one test failure to address.

I made one comment about ABI which I think we don't have to do anything for now. Other places look fine and I don't see an ABI issue. There are probably more ABI issues when merging from respect_fps_gz11new branch to gazebo11. Once this is merged, we could just create a draft PR and look at the abi-checker report to find all ABI issues.

[iche033]

I think overriding these functions should be fine according to explanation here since we're overriding virtual functions from primary base class

[iche033]

jenkins build caught a test failure here. I can also reproduce it locally.

[mabelzhang]

Okay. In 02269c0, I am disabling that test for Simbody, which is test number 2 that is failing. Many other tests in this file disabled it, and I thought about that but left it in since it didn't give me a problem. Maybe that was because I don't have Simbody installed. Let's see if Jenkins is happy now.

[mabelzhang]

same problem mentioned in pull request #2784

Does that need to be in gazebo11 or do we just leave it, since the tests here now work around it?

[mabelzhang]

In e7da851, I changed Sensor::useStrictRate to be static, re Steve's comment in Sensor.hh https://github.com/osrf/gazebo/pull/2746/files#r453859682
We said that since lockstep is now a global setting, this variable can be static for ABI compatibility.

[iche033]

Does that need to be in gazebo11 or do we just leave it, since the tests here now work around it?

I think we can leave the changes here as they are now since the tests are passing.

[iche033]

the latest changes look good to me. I'll wait for jenkins build to finish

[iche033]

there are a few tests failing in the ubuntu-gpu-nvidia build due to a weird boost problem, which I can't reproduce locally. It could just be an issue on the jenkins machine.

[mabelzhang]

I looked at the ones on ubuntu_auto-amd64-gpu-nvidia that had actual errors (as opposed to "test did not run" kind of thing), and looks like it's these ones:
PhysicsEngines/JointForceTorqueTest.GetForceTorqueWithAppliedForce/3
PhysicsEngines/JointForceTorqueTest.GetForceTorqueWithAppliedForceReset/3
PhysicsEngines/Pioneer2dx.StraightLine/1
JointInspector_TEST.AppliedSignal
ModelData_TEST.BoundingCollision
ManTest.gzserver
ManTest.gazebo

The ManTest ones I tried to fix in 9c61a7c.

All the others I can reproduce locally. They are also failing on the buildfarmer dashboard though, so I think they are not new:
https://build.osrfoundation.org/job/gazebo-ci-gazebo11-bionic-amd64-gpu-nvidia/lastBuild/testReport/

[iche033]

good catch on the ManTest. The latest builds look good now.