Revision history [back]

We can roughly do it, but it would be great to bulletproof this with a use case like you have. I should be able to allocate time to make this happen.

Wireless Connections - we can move in and out without too much problem (thanks Piyush). Would need to do more testing to 'guarantee' this works fine across access points, but that is something we will be doing here at Yujin shortly as we are extending our wifi infra. One issue might be in recognising when some delivery fails to be sent - is that a requirement?

Data Relaying - if we find problems with basic ros connections, there are a few things I'd like to implement via gateway relays. Instead of flipping the actual ros connections across, flip across a customised connection (different transport, throttling, compression, connection feedback, ...) that relays between the ends of a pub/sub pair or service. I've started experimenting with this and started also looking at similar needs from a couple of groups doing the darpa challenge (HK and WPI groups). Shouldn't be too hard to make this easily disappear under the hood of the usual gateway api but take advantage of the gateway hub to handle autodiscovery and setup the connections.

ROCON - If concert clients are expected to feed this information back, it would be basically an 'unscheduled' continuous feedback from clients to the concert, i.e. agnostic to the starting and stopping of rapps. We'd also like to continuously make available some things like robot urdf's as well, so that is a useful feature we could bump up the priority on as well.

We can roughly do it, but it would be great to bulletproof this with a use case like you have. I should be able to allocate time to make this happen.

Wireless Connections - we can move in and out without too much problem (thanks Piyush). Would need to do more testing to 'guarantee' this works fine across access points, but that is something we will be doing here at Yujin shortly as we are extending our wifi infra. One issue might be in recognising when some delivery fails to be sent - is that a requirement?

Data Relaying - if we find problems with basic ros connections, there are a few things I'd like to implement via gateway relays. Instead of flipping the actual ros connections across, flip across a customised connection (different transport, throttling, compression, connection feedback, ...) that relays between the ends of a pub/sub pair or service. I've started experimenting with this and started also looking at similar needs from a couple of groups doing the darpa challenge (HK and WPI groups). Shouldn't be too hard to make this easily disappear under the hood of the usual gateway api but take advantage of the gateway hub to handle autodiscovery and setup the connections.

ROCON - If concert clients are expected to feed this information back, it would be basically an 'unscheduled' continuous feedback from clients to the concert, i.e. agnostic to the starting and stopping of rapps. We'd also like to continuously make available some things like robot urdf's as well, so that is a useful feature we could bump up the priority on as well.