0
$\begingroup$

I'm new to this forum so I apologise if I disrespect some rules. I am considering using HTTP requests to control a robot remotely. The design problem I am trying to solve is that I would like to operate my robot using a wireless controller. The controller communicates to my pc, which then transmits data about its joystick to the robot. I am thinking of sending this data by means of HTTP requests. Based on the design problem, the communication will happen frequently.

  1. Are there any glaring issues with this approach?
  2. Are there any alternative communication protocols that might be better?

Thanks!

$\endgroup$
1
$\begingroup$

HTTP is a request reply communication. This is inherently limited to only one of the parties (the client) to initiate the exchange of messages. Furthermore as it is defined at the upper layers of the OSI stack it has more overhead, then protocols on lower layers.

One alternative a protocol on the transport layer, like TCP, SCTP or UDP. TCP opens a communication channel and until this channel is open messages can be exchanged and messages are guaranteed to arrive. UDP does not offer this guarantee, but in a small network messages should not get lost. SCTP is a newer portocoll and it is meant for streaming applications, so it could fit your application well.

Another option to consider is MQTT or similar streaming protocols (similar is RabbitMQ, zeroMQ). MQTT uses a message broker and instead of request-reply it uses publish-subscribe pattern. It is at a higher layer then TCP, UDP or SCTP (This usually means that it is more convenient to use but has more overhead). The robot can publish its measured coordinates and the joystick can publish its reference position. The robot subscribes to the joystick reference positions and a user interface can subscribe to both reference and measured coordinates in order to display them.

All above solutions are supported by libraries for all popular programing languages and cross platform use is also possible.

If you prefer a browser based interaction HTTP would be the easiest to implement. For native apps all above is similarly complex and plenty tutorials can be found.

Please not that none of the above methods will reach a cycle time suitable for using them inside a closed control loop, MQTT, SCTP, TCP or UDP will all be ok for supplying reference values for control loops. I would expect HTTP to be a bit slower the the others.

| improve this answer | |
$\endgroup$
0
$\begingroup$

If you want communicate over internet:

I think you should explore websockets for the purpose. Websocket connections allow both clients and server to send data. It's a full duplex communication mode. If you are using python, you can simply use a websocket client package like this one and get the python code to talk to your server (and let server talk to the python code).

On user browser side too(assuming you want to control your robot using a web application), implementing websocket is fairly easy. If you are not using a web application for the user, you can use the same python websocket client method to get the job done. Websocket server can be easily implemented in various langugages, however I suggest you not to use PHP for the job. It will make your life complicated. Check this link for example of a websocket server using Node.js

For a local network:

Go for ROS and do Network setup and get the job done fairly easily than working on RPC yourself.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.