It is installed inside the container under the Python libraries.
Since you have both video devices showing up under the container now, are you able to run this cell?
# change capture_device to 1
camera = USBCamera(width=224, height=224, capture_width=640, capture_height=480, capture_device=1)
I ran:
camera = USBCamera(width=224, height=224, capture_width=640, capture_height=480, capture_device=1)
Same error response as before. Appears that USBCamera cannot be found.
Also, I redid all steps in the “JetBot ROS GitHub Reposiitory” with successful completion up to:
roscore
in a new terminal, I entered:
rosin jetbot_ros jetbot.motors.py
Hmm ok, not sure why since it is showing up in the container as /dev/video1, sorry about that.
Are you able to view your CSI camera ok with the csi_camera notebook?
Does your USB camera work as capture_device=0 if you disconnect your CSI camera (you will want to shut your Nano down before disconnecting it)
dusty_nv,
I so appreciate your tenacity is following my experiences with Jetson Nano and offering guidance. I am a Noob.
I’ve been working with my Jetson Nano for five weeks, first with a PC and in recent weeks a Mac. I have reflashed the basic Jetbot image zip file many times using Etcher and reinstalled the NVIDIA-AI-IOT. I have not yet seen wheels turn or seen any camera image, so keep wondering if there is some basic step or sequence that I am overlooking or doing incorrectly.
I suspect that there could be some file path labelling error (e.g., /vern/ rather than /nvidia/). I don’t understand why I can’t find basic files like USBCamera or motors.py on any path in my file searches via Ubuntu on my Jetbot.
Sometimes, when starting with a fresh Etcher flash, I have followed NVIDIA’s Course, step by step. Sometimes I have followed your GitHub Software Setup (NVIDIA-AI-IOT) process. The error messages appear to remain the same.
If you are using the JetBot SD card image, my guess is these files are located in another user’s home directory (i.e. /home/nvidia/). If you look around the home directories, you might find it there.
If you can attach a display to your Jetson, I recommend running the nvgstcapture-1.0 program. This should show you the CSI camera’s video feed and confirm that the camera is working.
dusty_nv,
I have an image. A new threshold. Thanks.
nvgstcapture-1.0 works with the CSI camera, connected to JetBot with power off and USB Camera disconnected. [NOTE: USB camera resulted in an error message: camera not available]Camera’s view shows on HDMI attached screen/head. Here is the terminal session:
vernludwig$ ssh vern@192.168.55.1 vern@192.168.55.1’s password:
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.9.140-tegra aarch64)
To restore this content, you can run the ‘unminimize’ command.
25 packages can be updated.
15 updates are security updates.
Last login: Tue Oct 27 09:32:14 2020 from 192.168.55.100 vern@vern-desktop:~$ ls /dev/video*
/dev/video0
vern@vern-desktop:~$ nvgstcapture-1.0
Encoder null, cannot set bitrate!
Encoder Profile = High Supported resolutions in case of ARGUS Camera
(2) : 640x480
(3) : 1280x720
(4) : 1920x1080
(5) : 2104x1560
(6) : 2592x1944
(7) : 2616x1472
(8) : 3840x2160
(9) : 3896x2192
(10): 4208x3120
(11): 5632x3168
(12): 5632x4224
Runtime ARGUS Camera Commands:
Help : ‘h’ Quit : ‘q’ Set Capture Mode:
mo:
(1): image
(2): video Get Capture Mode:
gmo Set sensor orientation:
so:
(0): none
(1): Rotate counter-clockwise 90 degrees
(2): Rotate 180 degrees
(3): Rotate clockwise 90 degrees Get sensor orientation:
gso Set sensor mode:
smo: e.g., smo:1 Get sensor mode:
gsmo Set Whitebalance Mode:
wb:
(0): off
(1): auto
(2): incandescent
(3): fluorescent
(4): warm-fluorescent
(5): daylight
(6): cloudy-daylight
(7): twilight
(8): shade
(9): manual Get Whitebalance Mode:
gwb Set Saturation (0 to 2):
st: e.g., st:1.25 Get Saturation:
gst Set Exposure Compensation (-2 to 2):
ec: e.g., ec:-2 Get Exposure Compensation:
gec Set Auto Whitebalance Lock:
awbl: e.g., awbl:0 Get Auto Whitebalance Lock:
awbl Set Auto Exposure Lock:
ael: e.g., ael:0 Get Auto Exposure Lock:
gael Set TNR Mode:
tnrm: e.g., tnrm:1
(0): OFF
(1): FAST
(2): HIGH QUALITY Get TNR Mode:
gtnrm Set TNR Strength (-1 to 1):
tnrs: e.g., tnrs:0.5
Get TNR Strength:
gtnrs Set EE Mode:
eem: e.g., eem:1
(0): OFF
(1): FAST
(2): HIGH QUALITY Get EE Mode:
geem Set EE Strength (-1 to 1):
ees: e.g., ees:0.5
Get EE Strength:
gees Set Auto Exposure Anti-Banding (0 to 3):
aeab: e.g., aeab:2
(0): OFF
(1): MODE AUTO
(2): MODE 50HZ
(3): MODE 60HZ Get Auto Exposure Anti-Banding:
gaeab Set Gain Range:
gr: e.g., gr:1 16 Get Gain Range:
ggr Set Exposure Time Range:
etr: e.g., etr:34000 35000 Get Exposure Time Range:
getr Set ISP Digital Gain Range:
dgr: e.g., dgr:2 152 Get ISP Digital Gain Range:
gdgr Capture: enter ‘j’ OR followed by a timer (e.g., jx5000, capture after 5 seconds) OR followed by multishot count (e.g., j:6, capture 6 images) timer/multihot values are optional, capture defaults to single shot with timer=0s Start Recording : enter ‘1’ Stop Recording : enter ‘0’ Video snapshot : enter ‘2’ (While recording video) Get Preview Resolution:
gpcr Get Image Capture Resolution:
gicr Get Video Capture Resolution:
gvcr
Runtime encoder configuration options: Set Encoding Bit-rate(in bytes):
br: e.g., br:4000000 Get Encoding Bit-rate(in bytes):
gbr Set Encoding Profile(only for H.264):
ep: e.g., ep:1
(0): Baseline
(1): Main
(2): High Get Encoding Profile(only for H.264):
gep Force IDR Frame on video Encoder(only for H.264):
Enter ‘f’
bitrate = 4000000 Encoder Profile = High Encoder control-rate = 1 Encoder EnableTwopassCBR = 0 Opening in BLOCKING MODE ** Message: 09:39:23.039: main:4670 iterating capture loop …
NvMMLiteOpen : Block : BlockType = 4 ===== NVMEDIA: NVENC ===== NvMMLiteBlockCreate : Block : BlockType = 4 GST_ARGUS: Creating output stream CONSUMER: Waiting until producer is connected…
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3264 x 2464 FR = 21.000000 fps Duration = 47619048 ; Analog Gain range min 1.000000, max 10.625000; Exposure
Range min 13000, max 683709000;
GST_ARGUS: 3264 x 1848 FR = 28.000001 fps Duration = 35714284 ; Analog Gain range min 1.000000, max 10.625000; Exposure
Range min 13000, max 683709000;
GST_ARGUS: 1920 x 1080 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure
Range min 13000, max 683709000;
GST_ARGUS: 1280 x 720 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;
GST_ARGUS: 1280 x 720 FR = 120.000005 fps Duration = 8333333 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;
GST_ARGUS: Running with following settings:
Camera index = 0 Camera mode = 4 Output Stream W = 1280 H = 720 seconds to Run = 0 Frame Rate = 120.000005 GST_ARGUS: Setup Complete, Starting captures for 0 seconds GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
OK, cool - so your CSI is confirmed now to be working (outside of the container).
Next, with your USB camera still disconnected, can you try launching the DLI container again using this command?
sudo docker run --runtime nvidia -it --rm --network host \
--volume ~/nvdli-data:/nvdli-nano/data \
--volume /tmp/argus_socket:/tmp/argus_socket \
--device /dev/video0 \
nvcr.io/nvidia/dli/dli-nano-ai:v2.0.0-r32.4.3
Then try running the csi_camera notebook, and fingers crossed see if you have a video feed from the container’s notebook.
dusty_nv,
Yes it did run and toggled off(unobserve) and on one time. Success. Still and moving images. Thanks.
Not sure how to recover camera functionality. Will try to shut down terminal and juypter and restart.
We have some updates in the latest DLI container to address this - but some things you can do:
Shutdown the container and run sudo systemctl restart nvargus-daemon on the Jetson. And when the container is restarted, CSI camera will be back to normal
Alternatively, add the end of the notebook, add and run this cell:
camera.running = False
camera.cap.release()
The next version of the container will have that cell at the end of the notebooks to properly release the camera.
dusty_nv,
Your response for release of the CSI Camera in the Docker container looks very promising for resolving a persistent hang/error set. I hope to run these today.
csi_camera.jpynb
Also, perhaps the error string in the camera.py notebook could be updated. The error message could be amended with something like this:
“RunTimeError: Cannot read directly while camera is running. [adding] Release kernel or run
sudo systemctl restart nvargus-daemon,
or
camera.running = False
camera.cap.release()
to unlatch device from Docker Container.”
usb_camera.jpynb
Are similar RunTimeErrors also causing the USBCamera to remain latched? Is a similar string useful to release the USB camera in those containers? Would similar Error message edits in usb_camera.py clarify the needed release?
Also, is the Logitec C920 model USB camera hardware/device acceptable or is a C270 needed or better suited?
If both a CSI and a USB camera are attached to the JetBot, can either run by releasing the other. or is there some hardware or communication conflict that is not easily resolved while both are connected?
jetbot_motors.py
Does the robot motor driver also latch and need to be released once I run**:**
…$ roscore
or:
…$ rosrun jetbot_ros jetbot_motors.py
What is the release command line for rosrun and JetBot_motors.py?
Are similar RunTimeErrors also causing the robot motor driver to remain latched? Is a similar string useful to release the robot motor driver in those containers? Is that equivalent to a kernel shut down? Would similar Error message edits in jetbot_motors.py clarify the needed release?
Thanks. You have been most helpful.
I don’t believe that USB cameras or the JetBot motors suffer from the same issue after the notebook shutdown. The Logitech C920 should be fine - I have a C920 and a C270 and both work well here.
I think the JetBot software is configured for CSI camera, but may be possible to change it to use USB camera in the JetBot notebooks. Or are you talking about running non-JetBot software with USB camera (i.e. running the Nano DLI course on your JetBot)
dusty_nv,
I believe I did get a bit of wheel turn weeks ago. I do wonder if there is some latching with ros that results in errors arising on second-time run launch. I hope to check it out perhaps identify what step might avoid repeating errors, call failures, on my ros runs.
I prefer the image quality of the C920 over the CSI camera-brightness, contrast, detail. However I want to use whichever camera provides most workable data for image recognition, if I get that far.
I am alternately attempting to run both jetbot and NVIDIA Nano DLI software and that may well add to the persistence of error messages.
I hope to run some tomorrow, am sitting with grandchildren today.
Vern
Have you gone through the Jupyter-based JetBot tutorials from https://github.com/nvidia-ai-iot/jetbot first? Those include motor/driving tests. I recommend to make sure your JetBot is working first through the official JetBot Jupyter notebooks before attempting the ROS nodes.
dusty_nv,
Thanks for the guidance. I tried to upload the JetBot tutorial from GitHub and run it. I hav not succeeded. so basic loading of Robot and ADAFruit drivers is not working. I’m unsure about what Iv’e failed to upload or how to upload correctly.
See Errer messages in first two basic steps in a new Python3 kernel: What upload steps or process am I missing?
From your JupyterLab file browser, it appears to me that you have taken the ‘Getting Started with AI on Jetson Nano’ DLI container, and copied the JetBot files into it. Instead, you should run the JetBot container which already has these files and additional dependencies installed into the JetBot container.
For more info about running the JetBot container, please see here: https://jetbot.org/master/software_setup/docker.html
dusty_nv,
Thanks. Looks like I’ve created a problem. I set up my juypterLab access through the DLI course (weeks ago) using their dli**** PW. Now I cannot access JuypterLab via the je**** PW to launch the motion Notebook and Basic Motion guide.
Is there some way to have access to both or to extinguish the path through the dli**** PW? Thanks.
Hi vludwig - which container are you referring to? Is it the JetBot container? The JetBot container should have these dependences and JetBot notebooks already installed inside it.
Here is how you download/run the JetBot container: Using Docker Container - JetBot
dusty_nv,
Thank you for your continuing help.
I started over by flashing jetbot_image_v0p4p0.zip on a replacement card using Balena Etcher. Set up Wi-Fi and then proceeded without error through each step of https://jetbot.org/master/software_setup/docker.html, but one, the last step. Error message remains the same. It appears that Adafruit_MotorHAT can’t be found. Can you suggest a work-around? Thanks.
As you know, with another SD card, I have executed the on-board Camera with still and live-motion images.
Vern
Dusty,
I am very close. Robot is not recognized. Can you offer syntax corrections in [4] and [5], below? I did restart kernel at [1], [2], and [4]. Thanks.
