4

I have been looking for a good answer to this question for some time now.

I am trying to remotely control a robot with an Xbox controller. The challenge is that the controller is to be connected to a control station and not to the on-board computer of the robot. The on-board computer is running Ubuntu and ROS (Robotic Operating System) and requires access to the character device as if it is directly connected.

I am looking for a way to ssh into the on-board computer and forward the character device events from the control station. Real time updates are required. What is the best approach? Is it even possible?

Slippers
  • 143
  • 4

2 Answers2

4

Have a look at CUSE (character device in user space).

Forward device events to/from an UDP port, have ssh forward the UDP stream.

This is only "real time" for somewhat small values of "real time", because you have a considerable amount of delay inherent in your requirements.

dirkt
  • 31,679
  • 3
  • 40
  • 73
  • Anything involving UDP sounds like the wrong tool for this particular task. Moreover port forwarding in ssh is for TCP. – kasperd Feb 10 '18 at 22:07
  • @kasperd: Didn't know that ssh does port forwarding always via TCP, in that case, use TCP. UDP came to mind because it's more "real time"; games use UDP instead of TCP. – dirkt Feb 11 '18 at 05:45
  • 1
    That's not how you should be characterizing the difference between UDP and TCP. A more appropriate question to ask is do you want packet loss or do you want all the data to be delivered? With TCP you get all the data delivered, so you don't need to be concerned with packet loss. If the character device works through just `read` and `write` system calls and it treats the data as a stream of bytes, then you can run it over TCP mostly transparently and get the expected behavior. – kasperd Feb 11 '18 at 10:31
  • Please see question update. – Slippers Feb 11 '18 at 15:04
  • @kasperd: Do you want the increased delay if packets have to be retransmitted, or don't you need packets to be retransmitted, because the next UDP packet will contain the current control position anyway? That's the point of UDP vs. TCP. – dirkt Feb 11 '18 at 15:04
  • @dirkt UDP has valid usages, but you need much deeper understanding of the requirements to make it work than in the case of TCP. If you don't know the higher layer communication protocol in details, you don't know if losing a few bytes every now and then will cause the receiving side to get out of sync with the sender or otherwise in a bad state. It's all a moot point when running the traffic over ssh anyway as ssh runs over TCP and the latency of which you speak will be there no matter what you do. – kasperd Feb 11 '18 at 15:43
1

If you're using a SystemOnAChip (like RPi, BananaPi, OrangePi, ODroid...) and running some OS (Ubuntu in this case), even if it's a RT (RealTime) flavor of any distribution, "Real time updates are required" don't be possible. Just remember OS are far away to be RealTime, they have tons of services running in the background. This doesn't mean that what you're trying to do es impossible, just it will not be in RT really.

But it's possible what you want to do, just buy (if the on-board computer doesn't come with) a WiFi USB dongle, connect to the on-board computer, connect that one in the same network where you have the control station, install openssh-server in the on-board computer and, once both boards are in the same network, try to connect through SSH.

And if you allow me, I could recommend you another platform that I just used: ESP32, it's a micro-contoller with Wi-Fi and Blutooth incorporated, and if you buy it from AliExpress just cost you around 3$, you can program it with the Arduino IDE.

Btw, your project is interesting!!!

k.Cyborg
  • 459
  • 2
  • 7
  • 21