Closed gui2dev closed 4 years ago
I will need more information to help you debug. Try to manually roslaunch your launch file, and paste the errors that you get. If you only get the error "Failed to load nodelet...", then I'd suspect that you did not install (apt-get
or catkin make
and/or source setup.bash
) the package properly.
@anqixu I got no error while launching manually. It's only when it's launch on the background/ at startup that it does not work properly. So I guess something wrong with init / permission ?
I'll try to get some more logs out.
EDIT : package was installed using apt-get
I suspect that your upstart script is running as root (or another user than the one you use to manually test), and for this alternative user, ROS's setup.bash / ueye_cam package path are not set properly.
Try to sudo bash
to get a fully-rootified shell, and then try roslaunch
, followed by job-start
. If all these fail, then I'm afraid that I don't have any more ideas on what's wrong (but, perhaps naively, I suspect that it's not due to ueye_cam).
well these two are working...
It's only when using sudo service job start
that it fails.
From all that I could investigate, it looks as if somehow libraries where not found when launched as a service.
Using cron at @reboot with the appropriate sh files, it's working fine.
Hello @gui2dev , I ran into the same problem when trying to start a nodelet on start-up (using robot_upstart
).
Can you explain how you solved your problem ? Thank you :)
I did not solved it actually. I just used cron and some scripts. Found this in that post. Worked like a charm.
Thanks, that looks great ! I will also use this solution.
@anqixu I solved the issue. The upstart script needs to wait for the ueye driver service to be up, which was not the case, hence the bug.
@gui2dev Your use case may vary, but our preference at Clearpath has been to launch everything as early on possible on startup, and make it the responsibility of individual nodes/drivers to manage their own retry loops and publish diagnostics about the status of any external dependencies.
In a case like ours where it's an end-user robot, it's not realistic to have failure modes where the entirety of ROS just doesn't come up (or is delayed coming up) and the only way to figure out what went wrong is going in over SSH and examining logs.
I won't disagree with that.
@gui2dev We also found out that the ueye driver service had to be up before the upstart service started. So we created our own services with systemd that made sure the ueye.service was started before.
But I'm curious, are you still using cron or did you find a way to make the upstart service wait for another one (i.e. the ueye.service)?
Also @mikepurvis , also out of curiosity, do you mean you would make every node loop check for the availability of the resources (i/o, serial, udp, service ...) it will use ?
@ejalaa12 Yes, but obviously this mostly just matters for the cases where you actually have external dependencies, so basically, device drivers.
@ejalaa12 we use the same solution as you do. Specifying after ueye in the.service file.
I see, thanks guys ! :)
Hi !
I'm using robot_upstart to load some nodelet at startup.
I'm getting a weird issue, it seems that it fails to load nodelet as I'm getting this kind of fatal error:
Lauching
sudo job-start
on foreground is working fine (no permission issue).Here is my launch file: