Suggestions

[mikepurvis]

Nice work! A few small things—

• systemd by default limits the number of processes per service. Our jobs are set to TasksMax=infinity to turn off this limitation.
• To ensure a clean shutdown, set it to send SIGINT to roslaunch instead of SIGKILL, with
  KillSignal=SIGINT.
• Consider setting up a ros or robot user to avoid running the background ROS job as root. Unfortunately it's not in 18.04, but as of eoan, there's a debhelper for this: http://manpages.ubuntu.com/manpages/eoan/en/man1/dh_sysuser.1.html
• Your roslaunch invocation should probably have --wait to avoid racing the roscore unit that starts at the same time.

[LucidOne]

Nice work! A few small things—

* `systemd` by default limits the number of processes per service. Our jobs are set to `TasksMax=infinity` to turn off this limitation.

Done

* To ensure a clean shutdown, set it to send SIGINT to roslaunch instead of SIGKILL, with
  `KillSignal=SIGINT`.

Done

* Consider setting up a `ros` or `robot` user to avoid running the background ROS job as root. Unfortunately it's not in 18.04, but as of eoan, there's a debhelper for this: http://manpages.ubuntu.com/manpages/eoan/en/man1/dh_sysuser.1.html

So the current set of unit are designed to be run as user units, so a turtlebot user can have ROS start when they login and not have issues running nodelets. Once this is tested a bit more I'll integrate a system unit.

* Your `roslaunch` invocation should probably have `--wait` to avoid racing the roscore unit that starts at the same time.

I'm using netcat right now to detect when the socket is up, but I'll look at implementing this and providing a means to configure roslaunch a bit more after some testing.

I think the following roslaunch arguments might be nice to support, let me know if I'm missing anything.

--numworkers
--timeout

[LucidOne]

I'm testing this as an install strategy.

After an ISO install, when a user logs into the turtlebot roslaunch starts and the robot beep bloops.
I'm working on porting the app indicator for starting and stopping the service and running enable-linger. Long term I want to update/refactor the old PR2 robot cli to handle users claiming the robot and things like that.

[mikepurvis]

Ah, I see. Yeah, having to wait for a login is a non-starter for us. :)

I was never a PR2 user or developer myself, but I recall the whole "stop and rerun the robot job as me" thing being about a different user not being able to launch their own nodelets into a camera pipeline process owned by a non-login robot user. It would be neat if you could launch the robot service in the background at boot, and then upon login re-launch it as a user job for the logged-in user; that way the user would have full control to stop and restart it at will without needing to sudo anything.

Another thought— we haven't finished our implementation of this yet, but one more fun thing that systemd can do is differentiate between a unit that starting vs running— with Type=notify it becomes the responsibility of the invoked process to notify systemd (sd_notify) once the unit is considered ready. The definition of "ready" is probably going to vary a lot from system to system, but an easy starting point could be something that subscribes to /diagnostics_agg and reports ready once there's nothing left in a non-OK status. Reason this is useful for having other units able to hang off a successful (or failed) robot bringup.

[LucidOne]

If you need it to start at bootup you just need to run

sudo loginctl enable-linger $USER

for whatever user you want.
I think this can also be added to the postinst for a ros-<distro>-<robotname>-env package if desired.

The thinking here is that someone takes the robot out of the box, logs in, the robot starts, then the use selects the app indicator in the top right (like the gui volume control) and enables "Start at boot" if that is the operation they want. I think this makes more sense for arms and shared robots like turtlebots. The issue we keep running into during development is that everyone shares to robot, so either you end up with git commits being from the robot or some kludge to get the code back on to a devs machine to commit.

I'm interested in sd_notify for watchdog support, I'm hesitant to pull in systemd as a dependency for roscore/roslaunch, but I want to try having a node started by roslaunch report back to Systemd.

[LucidOne]

It look like it might be more robust to just do a

touch /var/lib/systemd/linger/$USER

in the posinst, so you don't have issues with dbus during the install.

[LucidOne]

It still needs some work, but here is the GUI frontend.
https://github.com/LucidOne/robot_indicator