Battle Room Perspective UI

[stonier]

No description provided.

[stonier]

Goal : assist the project manager and developers to plan the layout of the multi-robot orchestration required to realise a cento project.

Motivation : If you've ever tried to assemble all the ros nodes for a complex robot, you'll understand how notoriously difficult ros can be. For multi-robot orchestration with non-interacting and often remote software groups (e.g. control and web app devs) this is even worse.

Analogies : compare with a traditional software project that is required to supply a suite of binaries and libraries to its customer - in a large team it is usually a good idea to attack the big picture problem of roughly what binaries and libraries have to be built and what api they should expose before coding too much. For teams developing a single ros system, each developer likes to have a map of the ros api (i.e. pubs, subs, services and actions) they need to implement on their individual nodes as well as a big picture map of how it will all get assembled. Knowledge of existing nodes that you will use is also important. For a rocon system you need to take a similar approach, but with rocon resources, rocon services and rocon interactions in mind instead of nodes.

Important Points

• Assist but do not control the process.
  • We are orchestration agnostic, rocon service development can be BPES, ros style, ...
  • Orchestration for robotics is still very experimental and volatile.

Ideas

I am picturing the following ideas as being important for us:

• Information : put as much detail about existing reusable components at our disposal so we don't have to go chase them down
  • These components would include rocon services, apps and interactions.
  • What public interfaces do they have? What platforms can they run on? What parameterisation is allowed?
• Big Picture : enable a visualisation of the rocon services, apps and interactions
  • e.g. a bit like, but not exactly:

• Mapping Views : easily generate some quick and easy mapping diagrams showing where connections from rocon services, resources and interactions should land in the concert workspace.
  • This is where you can get scifi'ish. Think ender or battle star galactica battle maps.
• Generator : from the big picture, spin up tasks for each component that can be assigned and emailed to a dev with alot of filled in information
  • e.g. create rocon service 'foo' with parameters x, y, z to utilise resources a, b, c with a local mapping view like diagram 'x'.

Demo

So what to do for the demo? I think pumping information into this perspective is a good start. Only once we have information can we start really doing something. However being able to visualise a big picture might also be worthwhile.

Final Thoughts

This is just to kickstart things - by no means assume any of the above are fixed and Huey's input here is more valuable than mine.

[adamantivm]

This is a great start. Thank you, @stonier!

I have a few questions to follow-up on this:

• Is there a repository or location where rocon resources, services and interactions available somewhere? Or where they normally get stored during a project? I'm trying to understand where we would pull these from
• In a normal ROS system, are you aware of any tools ROS developers use to map out the ROS API they need to put together (pubs, subs, services, msgs)? I agree with the usefulness of doing this on a regular ROS system, but I don't know of any tool like Cento for doing it. Perhaps Cento can have this component which will turn out generally useful for standard ROS development as well?

At a meta-level:

• I wonder if it wouldn't make sense to open a Google Doc to work the details out of this discussion. Not sure, just throwing it out there
• In terms of Demo, as appealing as I find this one perspective, from what I hear from @hughie and considering the time and speed we're achieving, I wonder if it wouldn't be a better idea to focus on Ideation and Diagram and leave battle loom as a concept only (i.e..: charts) for the Teaser.

[stonier]

leave battle loom as a concept only

Yeah, I think this is probably good. I do think however that it would be good to at the very least, embed a simple picture in this view for the teaser.

• A picture conveys a thousand words..... 😜
• It's a good reminder to everyone to keep thinking about it
• Can perhaps spark some thoughts if it keeps popping up in front of you while developing.

[stonier]

Is there a repository or location where rocon resources, services and interactions available somewhere? Or where they normally get stored during a project? I'm trying to understand where we would pull these from

We are working with Dirk/Esteve at OSRF right now (actually was in the middle of a big github issues when you connected tonight!) to get remote rapp repos indexed so that something like Cento can pull the index and introspect on the rapps.

Once that is done, we extend that to services/interactions as well.

[stonier]

In a normal ROS system, are you aware of any tools ROS developers use to map out the ROS API they need to put together (pubs, subs, services, msgs)?

Someone was working on a qt application to do this. It's surprising that more people haven't given the very fixed nature of roslaunch files. You always see this as a very important part of component based systems/government projects as well. The curious thing though...at the end of the day, ros users don't seem to have a burning need for them.

My thoughts on this

• Roslaunch is immensely powerful, trying to recreate that is hard
• Ros has very little IDL type information (c.f. component robotics)
• Nodes under the hood can dynamically register and unregister connections
  • Very hard to concretely represent this
• Such interfaces are usually not for robot developers (robot devs ~ ros devs right now)
  • Bit of a chicken and egg situation - no simple app devs yet, so no need for it.

Probably lots of other reasons too. Anyway, my thought is not to replicate such a thing exactly, especially as the concert is even more dynamic than a ros system (robots come and go, human interactions come and go).

What I would like is to replicate the process we seem to always do before a big multi-robot scenario hackathon. That is, we get a whiteboard, and draw pictures of connections in the system. These are not always the whole thing, but could be just the connections between a rocon app and service, or a service and an interaction. Or the parameterisation needed to be supplied to a rapp. i.e. 'views'. Just simple diagrams and drawings that can be passed off to engineers to help them develop their own part of the big picture. The real problem is we do this on a whiteboard here at Yujin. But what happens when the control team and web team aren't in the same building, or in the same country? Can't do this at all. Or the manager is elsewhere? Thats what I want to replicate.

[adamantivm]

For this I think that having a very simple online diagram tool which allows you to search and pull components (ROS nodes, or rapp repos, services and interactions) represented as an icon or box, and easily wire them together with some lightweight annotation would go a long ways.

I can think of how to go about developing this with a reasonably good level of confidence.

---

I also think there is value on the reverse-engineering part of it (i.e.: reading a launch file or a running system and graphing all the connections and configuration) would be very valuable, although based on experience, perhaps to a second degree.

The main thing I wanted to know though is whether you knew about tooling here that I wasn't aware of. But I think we're on the same page.

---

I would in fact split the battle loom function in these two and start to the first and make the second optional. What do you think?

[stonier]

pull components (ROS nodes, or rapp repos, services and interactions) represented as an icon or box, and easily wire them together with some lightweight annotation would go a long ways.

This would be great for the big picture at least - then we can work out how to do them for creating views.

---

I also think there is value on the reverse-engineering part of it (i.e.: reading a launch file or a running system and graphing all the connections and configuration) would be very valuable, although based on experience, perhaps to a second degree.

I agree, helping to automatically visualise some parts would be good, especially as unlike ros, our system starts to specify some IDL style structures (e.g. formal public interface for a rapp, whereas a node's public interfaces might get specified on the wiki). I suspect it will mostly be an exercise in working out what is practically useful I think rather than trying to do everything.

---

I would in fact split the battle loom function in these two and start to the first and make the second optional. What do you think?

Sounds like a plan.

[adamantivm]

Ok, I created all the related issues.

It would be great if you and especially @hughie can review and close this issue if you think we have come to an agreement about this.

[stonier]

Looks good to me, @hughie?

[hughie]

I have no time for checking this now. I'm on document deadline. I will check it soon.