pyros-dev / rostful

A lightweight package for providing and consuming ROS services, actions, and topics as RESTful web services
68 stars 41 forks source link

Running rostful and rosbridge_websocket apps on single tornado server. #59

Open dhirajdhule opened 8 years ago

dhirajdhule commented 8 years ago

I checked https://github.com/asmodehn/rostful/issues/34

For some applications REST + Websockets would be great as each of them have their own pros and cons. For example streaming data continuously from robot would be efficient using websockets instead of polling it with GET call. Also for a user who just want to do simple stuff with robot, calling a control command using GET will be easier to code than calling a service from wesockets . So if a robot extends x no of things some could be accessed from REST and others using websockets depending on users will.

For users who need Websocket and REST together, wouldnt it be great to have a combined package which will run rosbridge_websocket app and rostful app(under WSGI container) on single tornado server?

I read here http://stackoverflow.com/questions/13163990/why-use-tornado-and-flask-together and some other pages that a hybrid case implemented using single server would NOT be Inefficient in terms of resources and performance.

By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user. But will it be suitable for REST application(short lived multiple connections)?

After reading this http://stackoverflow.com/questions/8143141/using-flask-and-tornado-together I've done some initial tests with sample flask apps and rosbridge websocket app. Will post results when I run rostful with it.

Has anybody tried similar approach before? Is there a better option?

asmodehn commented 8 years ago

I think REST is appropriate to interface ROS Services, but for Publishers/Subscribers websockets is an option that definitely makes sense when you want data streaming (or push instead of pull). There are also other options (xmpp)

But rosbridge is there if you want websockets, so rostful doesn't focus on it. I actually sometime run both on some robots, from two tornado servers. But for most users ( non robot-devs ) applications, REST access to ROS service is enough.

What I think would be nice is a REST interface to start/stop streaming (via websocket or other) from a specific publisher.

But I don't currently have a usecase that need it right now, so I probably wont work on it for a long while... I am currently focusing on getting the REST interface right for interfacing python frameworks with ROS for a simple use. First things first.

One option is to join rostful and rosbridge_websocket at the web level as you said. Not sure if it would work. Rostful aims to be pure python code, so it can run from a python environment on any setup (ROS or cloud server or something else).

Another option is to interface directly with topics in https://github.com/asmodehn/pyros. Thats the dependency rostful rely on for interfacing multiprocess python with ROS, and it s could also be there that things should start for implementing a "streaming-like" interface...

dhirajdhule commented 8 years ago

Yeah, I too agree that Rosbridge and Rostful have their own focus areas and separate use cases.

Data streaming using repeated pulls is not efficient. I have tried it and it makes everything slow at faster data rates. Also there is chance of missing important data.

I use data streaming and services together in my webapp. And I guess it wont be too long for non-devs to start using robot web consoles which would stream them realtime data and make available services to control their robot. Users will prefer such complete apps for their robots, i guess.

your second option make me more curious? I will look more into it.

For now, I have tested the rostful and rosbridge apps on single tornado server successfully. As both are python frameworks it was painless. I am able to run these apps on single or independent ports and using WSGIcontainer for rostful app. I have tested topics, params, services from websocket and REST.

This option could serve better for now, instead of running two servers.

"What I think would be nice is a REST interface to start/stop streaming (via websocket or other) from a specific publisher." I guess this is doable by calling services of 'rosapi' node of 'rosbridge suit'. But i'm not sure about this way.

I will look more into the second option that you suggested.

asmodehn commented 8 years ago

Interesting that WSGI integration of both rostful and rosbridge. Interfacing in pyros is probably a long term, optimum solution. In the mean time having a quick solution could be good, to find out how people actually use that feature...

Since you got both rostful and rosbridge on one server working, there might be a quicker way to provide users with the REST service to hook/unhook a webclient to a ROS topic using rosbridge. It could be interesting to have in rostful, as another way of interfacing with topics... We still need to think about how users might want to trigger that (launch file, config, rest service, etc.)...

Do you have any links, code, or something I could have a look at ? Thanks, and let me know what you find out !

dhirajdhule commented 8 years ago

Yeah, Sure.

I've tested it and it seems to work fine. Here are the links to files that i have changed.

https://www.dropbox.com/s/l0l3xe8bgsnyxdh/server.py?dl=0 https://www.dropbox.com/s/2ht0crwtilbcywm/rostful.launch?dl=0

and a readme on using it. https://www.dropbox.com/s/d41r33j7grttc4f/rostful_socket_readme.txt?dl=0

*I'm using older rostful than one you have here.

I'm interested in the thing you said about adding triggers from rest which could control streaming using sockets. This could evolve as a good quick solution.

asmodehn commented 8 years ago

Thanks. I will probably not be able to work on that in the short term (other priorities for christmas and work). If you would like the switch on/off feature, feel free to give it a try and post a PR. Otherwise I'll eventually do it when I get some time.