tue-robotics / rgbd Goto Github PK

If a client is created before a server, THAT client will reconnect to any server, if servers are closed and opened again. Any client that connects to an existing server, will not reconnect to another server, if the original server is closed.

I am not sure if something in the build chain has changed, but using the newest docker image from osrf/ros kinetic-full I am getting build errors:

CMakeFiles/rgbd.dir/src/View.cpp.o: In function `main':
View.cpp:(.text+0x0): multiple definition of `main'
CMakeFiles/rgbd.dir/src/Server.cpp.o:Server.cpp:(.text+0x721): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [/build/devel/.private/rgbd/lib/librgbd.so] Error 1
make[1]: *** [CMakeFiles/rgbd.dir/all] Error 2
make: *** [all] Error 2

Removing say View.cpp from library rgbd in CMakeLists.txt results in linker errors. I am also getting linking errors in macOS.

Now the response of the GetRGBD service is not a RGBD msg, but a custom response. I think this should be a RGBD msg.

That way, you can see multiple RGBD streams at once
http://wiki.ros.org/roscpp/Overview/Initialization%20and%20Shutdown#Initializing_the_roscpp_Node

Current information: it breaks!

We should add proper testing of the rgbd system considering how often it breaks.
Currently the test file rgbd/test/serialization_gtest.cpp is symbolic at best.

Things that should be tested:

• creating shared memory. verify memory with the specified name exists after creation
• writing a new image to shared memory. verify the content of the shared memory is updated
• reading shared memory when none exist. verify correct behaviour.
• reading an image from shared memory. verify that the send image is identical to the received image.
• destruction of shared memory.

See what compressed (depth) image stuff can be used.

Issues

1. Server can't create new SHM, so server doesn't boot
2. Clients don't switch between SHM and topic mode.
   • If in topic mode, don't switch to SHM if it comes online
   • If in SHM, doesn't switch to topic mode if SHM isn't written anymore.
3. Server doesn't reconnect to ROS. (ROScore is rebooted)

Constraints

2 Needs to be solved before 1 as clients don't close the SHM at the moment. So the server can't create a new SHM. Because the old SHM is still open.
3 can be solved seperatly.

Proposed solutions

1. Will be solved if clients close their SHM in case the old server dies.
2. Servers will publish their hostname on a string topic with a frequency X. Clients will use SHM as long as hostname is published on the topic less than Y seconds ago. Otherwise client will switch to topic mode. Client will switch back in case the hostname is published again.
   Client will check for the hostname on a fixed rate, not on the nextImage call. So the SHM is closed quickly after the server is died and not on a nextImage call, which is not called with any fixed rate.

• Server publishes hostname on string topic, in case ServerSHM is initialized. fb5b7b6, bb3a25c and b680941
• ServerSHM opens SHM on initialization, but can only fill the header on first image
• ClientSHM connects to an SHM with empty header
• Client listens to hostname topic on a fixed (Wall)Rate and switches to and from SHM

3. Check on a fixed rate if master is still ok,

if (!ros::master::check())
{
    // Make sure node will die
}

Make sure the node will restart in the service/launch file

• Check master on a fixed rate, implemented in e2e000c
• Make sure nodes restart in service/launch files

Tests

• Standalone testing
• Reconnecting to ROS
• Client switching from SHM to topic mode
• Client switching from topic mode to SHM
• Robust reboot of Server, which requires that old SHM is closed before new server start.

Will fix #15