Launch failed

[routiful]

I have written simple launch file to run this node.
But it occured termios error and didn't run.

[ros2-1]     settings = termios.tcgetattr(sys.stdin)
[ros2-1] termios.error: (25, 'Inappropriate ioctl for device')

How can I fix this?

[clalancette]

So, running this particular node in a launch file ends up not making much sense. That's because this node expects to get its input from stdin, and I believe that launch does....something with stdin. If you think about it further, it still doesn't make sense; what if you launched this node along with another node that needed its input from stdin? Which one would get the data?

I'm going to close this out as CANTFIX, but feel free to reopen if you think otherwise.

[routiful]

@clalancette
I agreed that this node doesn't have to be launch.
However, I wondered that turtlebot3_teleop could launch in ROS 1. It developed simillar code in this repo.
https://github.com/ROBOTIS-GIT/turtlebot3/blob/be8b6fdcae0221dd650be4b80b8a9f2e80a079de/turtlebot3_teleop/nodes/turtlebot3_teleop_key#L126
But ROS 2 version can't launch. It includes same code in above.
https://github.com/ROBOTIS-GIT/turtlebot3/blob/758c89ae4a1bf5c1cb665e6b836732073c822e26/turtlebot3_teleop/turtlebot3_teleop/script/teleop_keyboard.py#L126

[clalancette]

The launch system in ROS 2 is very, very different from ROS 1. So I'm not surprised that there are differences here. The question is whether we want to support this going forward in the new ROS 2 launch system. I don't personally thinks it makes much sense, but others might have a different opinion. @hidmic any thoughts here?

[hidmic]

Wow, I've been skipping this one when pruning my notification backlog for quite a while. My apologies to you both for the delay.

So, as @clalancette correctly states, you can't forward stdin to a launched process in ROS 2. You can't even grab the pipe that's connected to the launched process stdin. And this is still true for Eloquent.

As to whether it makes sense to add support, I have to agree with @clalancette. Nodes that get input from stdin don't really make much sense in launch (and FWIW, probably the same goes for other process management tools). I can see value in being able to programmatically interact with a launched process via stdin in some specific scenarios (like when you're testing a process using launch), but that's a different thing.

[HappySamuel]

Hi @routiful

Now, the teleop_twist_keyboard can be started via launch file. Thanks to @caelinsutch.

Pre-requisite (sudo apt install xterm)

Launch Method 1 (xxxxxxxxx.launch.py)

Node(
    package="teleop_twist_keyboard",
    executable="teleop_twist_keyboard",
    name="teleop_twist_keyboard",
    prefix='xterm -e'
)

Launch Method 2 (xxxxxxxxx.launch.xml)

<node pkg="teleop_twist_keyboard" exec="teleop_twist_keyboard" name="teleop_twist_keyboard" launch-prefix="xterm -e"/>

Note: Above methods are for ROS2 launch files

Best,
Samuel

[fake-name]

So, running this particular node in a launch file ends up not making much sense. That's because this node expects to get its input from stdin, and I believe that launch does....something with stdin. If you think about it further, it still doesn't make sense; what if you launched this node along with another node that needed its input from stdin? Which one would get the data?

Having more then one car cannot possibly make sense, since you can't operate both at once. No one will ever need 2 cars.

I'm going to close this out as CANTFIX, but feel free to reopen if you think otherwise.

At minimum, this is WONTFIX, not CANTFIX.

---

Sure, the case of having two nodes consuming from stdin is poorly defined. However, the case for having just one node consuming stdin can be extremely handy, and from reading around the ros Q&A and other issues, this is a pretty common thing people want.

In my case, I have a pile of nodes that do things, and I'm trying to have one node that takes simple key-presses to start and stop various other nodes, emit messages, etc...

The entire concept of "here's a bunch of nodes that do various things, with one node that you interact with via key-presses to control them" maps perfectly to the launch-file concept, except it doesn't work because stdin is unavailable.

[fake-name]

FWIW, I was able to work around this mis-feature in a spectacularly horrible way.

Since I'm using python launch files, and the context of the launch file itself has the proper stdin/stdout connections, you can fork off a thread there, and run a thread that reads from stdin and pipes those results somewhere else (in this case, it bridges them to a ros topic, which I have another node that then handles further).

In any event, I now have a single launch file that does everything I want, including live interactivity via keyboard.