The short answer: First try with an externally powered USB HUB (a HUB which provides its own power without drawing power from the USB cable) in case it is a power issue. More below if you are ambitious on reading.
Some USB information might be useful background: USB is “hot plug”, and thus as a device plugs in it is given a driver if the driver exists. Most USB cameras use a generic video class driver, and thus almost always have a driver assigned (some cameras have custom drivers and would not have the driver without installing it). Apparently your camera uses the generic video class driver, and so this is never an issue.
The video class driver is what creates the device special file, e.g., “
/dev/video0” (or any “
video#” file). Since there can be more than one camera, and because most of those cameras use the same driver, the file name distinguishes by numbering (which is why the “
0” or “
1” of the “
video#” naming convention). The camera will be numbered in the order it is enumerated upon plugin. The only “default” way to know which camera file to use is to plug in just one camera or to plug in multiple cameras in the same order each time (system start up is the same as plugging cameras in with some default order).
You are probably running into a camera which disconnects and reconnects (possibly due to needing more power, e.g., a powered HUB…more on that later). If the reconnect is fast enough, then the camera will be starting when some part of the old setup is still running. This means the camera is competing with itself for the file name, and instead of remaining “
/dev/video0” it will increment the numbering and become “
There is a way to customize this if the information the camera presents to the USB layer has any unique attributes (looking at attributes is the realm of the command “
udev sees anything that command can see). The
udev system looks at USB devices and their drivers each time a device is plugged in. Normally the driver would pick the file name associated with the device, but
udev can manage this and customize the naming. As an example, some camera brand might want to distinguish itself in the market, and so they might use
udev (via a
udev rule installed with a package the company has created) to change it from the scheme of “
video#” to “
some_brand#”, and “
video0” would become “
So if you really want to fix this what you’d do is prevent the device from having a new name each time it inserts, and the proper way is to stop it from re-enumerating if possible, but in some cases if you can’t prevent this you could use a
udev rule to maybe fix the naming convention. Going first with preventing the camera from disconnecting:
- If it is a power consumption issue, then as power requirements go up on the Jetson and the camera, it becomes possible that something running close to what power can correctly regulate will imply the camera momentarily disconnects as the system load goes up. If this is the case, then a USB HUB which is externally powered (and thus stops using or depending on power from the Jetson) will prevent that problem. Try an externally powered HUB first if it is not already self-powered.
- It is also possible that there is a signal quality issue. Not as likely as power as an issue, but still possible. If you monitor the command “
dmesg --follow” (which continuously shows log lines from the system as they occur), then as the device loses and recreates its connection the log would likely indicate an error related to signal. Otherwise the message would just be a disconnect and reconnect without an error.
If there is still some issue, and if that issue is not some sort of disconnect/reconnect failure, then you could try a custom
udev rule (but it is almost certain that
udev is the wrong way to control this). One could for example recognize that camera in
udev and tell it to force the file name to remain constant (there are other situations where a
udev customization would be useful though, so it is worth adding here). The first thing you’d want to do is to see the USB information for the device (which is useful in debugging as well and not just for
udev customization). If you run the command “
lsusb”, then you will see a brief list of devices. Note that the list includes an
ID. As an example, a Nano as a device might show up with ID “
0955:7020”, where “
0955” is assigned to manufacturer “NVIDIA”, and “
:7020” is what NVIDIA designated for that Jetson model. You can limit the “
lsusb” to that manufacturer and device type via the
ID, and as an example, this would limit to that Nano model:
lsusb -d 0955:7020
To make that verbose and to show all details one would have to use
sudo and the “verbose” flag (without
sudo you can see many details, but not all):
sudo lsusb -d 0955:7020 -v
Some devices have unique information, e.g., a serial number, though this is not common among low end cameras. One could use
udev to rename to a single exact device special file name via serial number. One could also do this via a device and manufacturer ID (but this would only be useful in your case if you know there is only a single camera…an alternate naming base name would still get a number incremented in an unknown order if there were multiple cameras).
One cool example to look at on how this naming can help is that a single device can have multiple names through the use of symbolic links in “
/dev”. If you look at human interface devices (e.g., keyboard, mouse, joystick), then know that those devices are generally a naming convention of “
/dev/input/event#”, and those are the real device special files (those files exist only in RAM and are a driver pretending to be a file). However, if you look at “
ls /dev/input/”, then you will see there are subdirectories, e.g. “
by-id/”, and “
by-path”. It is
udev which creates alternate names, and those can just as easily be renaming the original file or creation of an alternate name with a symbolic link. A rule could exist which creates a camera subdirectory and always links the “
video#” to one exact name, e.g., the most recently plugged in camera could always have the name “
Having a specific file name could help, but keep in mind that the driver would still disconnect and reconnect, and even if you force the name to remain constant you would have an error. This is because the file name would disconnect and reconnect the camera and you’d get an error trying to pretend the camera is always present and always has that name. During disconnect/reconnect the camera would require some sort of constructor to restart it, and the state would cause the running program to fail momentarily. So this demonstrates that you are not really after “keeping the name the same” for this case (although there are a lot of cases where it would be convenient to name your specific device among many to make finding it easier).
Here’s a tutorial on
udev customization which seems to be useful (like I said, it probably isn’t useful in your case, but it is useful as a general tool so it is worth mentioning):