My firmware version is 3.70.1, I am using Linux natively, Ubuntu 18.04. Also I tried many different scenarios I let it sleep for over 3-4 minutes, tried waking it up immediately after putting it in sleep mode etc.,
craig@craig-desktop:~$ ptpcam --info
Camera information
==================
Model: RICOH THETA V
manufacturer: Ricoh Company, Ltd.
serial number: '00105377'
device version: 3.70.1
extension ID: 0x00000006
extension description: (null)
extension version: 0x006e
craig@craig-desktop:~$ ptpcam --info
Camera information
==================
Model: RICOH THETA V
manufacturer: Ricoh Company, Ltd.
serial number: '00105377'
device version: 3.70.1
extension ID: 0x00000006
extension description: (null)
extension version: 0x006e
craig@craig-desktop:~$ ptpcam --set-property=0xD80E --val=1
Camera: RICOH THETA V
'UNKNOWN' is set to: 0
Changing property value to 1 [(null)] succeeded.
craig@craig-desktop:~$ ptpcam --set-property=0xD80E --val=0
Camera: RICOH THETA V
'UNKNOWN' is set to: 1
Changing property value to 0 [(null)] succeeded.
Result: Did not wake up.
retry test with Z1 - woke up
craig@craig-desktop:~$ ptpcam --info
Camera information
==================
Model: RICOH THETA Z1
manufacturer: Ricoh Company, Ltd.
serial number: '10010104'
device version: 2.00.1
extension ID: 0x00000006
extension description: (null)
extension version: 0x006e
craig@craig-desktop:~$ ptpcam --set-property=0xD80E --val=1
Camera: RICOH THETA Z1
'UNKNOWN' is set to: 0
Changing property value to 1 [(null)] succeeded.
craig@craig-desktop:~$ ptpcam --set-property=0xD80E --val=0
Camera: RICOH THETA Z1
'UNKNOWN' is set to: 1
Changing property value to 0 [(null)] succeeded.
craig@craig-desktop:~$
I recently started using a ThetaV also for robotics with live streaming (as a virtual pan and tilt unit). For the the real system automation and integration I just can not afford to push buttons so I scraped down ptpcam from libptp2 and thus started to build a c++ thetaV API using ptp… it is coarse and early stage, but I am happy to share the code. I can changes modes, streaming works fine,
Just one issue, when it comes to waking up the device I have the same issue as above. Neither with with my code nor with ptpcam as above it works.
My observation, we had 2 thetas in the lab and before programming, I am 99% sure it worked with ptpcam on a theta where I did not upgrade the firmware… Then later I did and when coding I could not make it work ever again.
Can anyone confirm or try with a theta V that does not have 3.70.1 (I think the working version was bought in 2018 and not upgraded)
I hope this helps and someone knows?
It would be really cool to use the low latency live streaming in remote operated robots as “pan and tilt unit without moving parts”
thanks for the quick response. Let us hope that this in interest of RICOH, if there is anything we can do I would be open for it. For my use case the automation and wake-up would be really important but we could also buy a Z1 if it supports it.
For the code: It is really fresh and I was just putting together and documenting a bit to get it out here. As said a bit coarse, missing features and robustness checks but a foundation for something more. It also re-use a bit of original code from ptpcam…
This is a start for controlling it via c++ using underlying ptp
The overall goal, using the above lib is a virtual pan and tilt unit…
Both work but lack yet robustness and have hardcoded values… But I will improve and could help out attempts building it.
The Z1 works with wake from sleep. See this post. The second test is with the Z1 and it did wake from sleep. This is with firmware 2.00.1, which is the newest firmware for the Z1.
The V used to work, but the newest firmware 3.70.1 does not work with wake from sleep. There is no way to roll the firmware back.
This is an example putting the camera to sleep and waking it up as well as powering it on and powering it off. Older firmware, but the API still worked with the Z1 in my more recent test with firmware 2.00.1
This is very cool. What type of board do you have connected to the RICOH THETA? Is it a Raspberry Pi, Jetson Nano, x86? The libptp code is a bit difficult to work with, so this type of project is a big help to add an easier layer of abstraction.
The controller is amazing. Well done! I’m curious as to what the board you are using is so that I can test it out with similar hardware. Maybe I should try it on x86?
Thanks, I used both x86_64 Debian and the jetson nano, both worked with the control libs…
For the streaming part itself I was very closely (re)using this example but build the GStreamer pipeline bit by bit. It works well on the x86_64 Debian but on the Nano it was very slow, even using the omx decoders but I think here it is my mistake just somewhere in the pipeline, caps filter or so.
I will check your example would be even curious if the Z1 has better latency in streaming via USB than the V
I believe the Z1 and the V have roughly the same latency. On x86, I can get 250ms using nvdec and glimagesink with the Z1. I did not test the V. However, I have both a V and a Z1, so I could run some comparison tests.
I normally don’t use a joystick with Linux. Should I just plug an XBox One controller into the Linux box with a USB cable? I have one lying around the living room.
Thanks for hint to the gestreamer plugin - a theta gstreamer plugin (that is able to switch the device automatically on and to the right mode) would be one of the most desirable things for many projects…
I hope Linux detects the XBox Controller as joystick
apt install joystick
you could check with
ls /dev/input
and hopefully it shows up as js0 or js1 …
then a quick test with
jstest /dev/input/jsX
I just hardcoded js1 because on my computer even the accelerometer shows up as a joystick. Otherwise, the input velocity [line 471-472] of could just come from a timer (or keyboard, or in the case of a real robot over the network ).
e.g. comment the joystick code out and set the yOffset to 800 and set the xVel to 6. and then slowly it should pan from left to right, each timer-step the xOffset is incremented by xVel.
On Nano, I often have to reduce the resolution from 4K to 2K. If you want to switch back and forth between 2K and 4K for testing, you can change THETAUVC_MODE_UHD_2997 to THETAUVC_MODE_FHD_2997.
Example.
if (argc > 1 && strcmp("--format", argv[1]) == 0) {
if (argc > 2 && strcmp("4K", argv[2]) == 0) {
printf("THETA live video is 4K");
res = thetauvc_get_stream_ctrl_format_size(devh,
THETAUVC_MODE_UHD_2997, &ctrl);
} else if (argc > 2 && strcmp("2K", argv[2]) == 0) {
printf("THETA live video is 2K");
res = thetauvc_get_stream_ctrl_format_size(devh,
THETAUVC_MODE_FHD_2997, &ctrl);
}
else {
printf("specify video device. --format 4K or --format 2K\n");
goto exit;
}
}
The Xavier seems to handle 4k video transformations better, but at higher cost.
Thanks, I have the feeling that the nano should be able to handle 4K h264 hw accelerated decoding very well… My suspicion is that to use the nvidia decoders properly the data needs to be in the video RAM similar to … nvvidconv with the caps video/x-raw(memory:NVMM). Here we would need to see how to get the data from the app source there … just a guess, will try it out.
Oh, I think you’re right. Now that I think about it, the problem with the Jetson Nano at 4K is in the OpenCV processing or the DetectNet AI, not with the video frames itself.
I am trying to build a wheeled robot with a Ricoh Theta V installed on it to detect objects. Is it possible to turn on the camera automatically when the computer (NUC x86 ubuntu 18.04) is turn on?
Yes, plug the camera into the USB port of the NUC. The camera must be in a power off state, not “sleep”. If it is powered off, the camera will turn on when you turn on the NUC.
You can test this behavior quickly by unplugging and plugging the USB cable back in when the camera is in a “power off” state.
We reported the bug to RICOH a few weeks ago. I have no further information.
Some things to consider:
I do not work for RICOH and do not have information on the development plans
this site does receive sponsorship from RICOH and we do report community feedback back to management
My personal opinion is that I do not think there will be a fix to the V firmware for the USB API unless it is easy to fix. The reason I suspect this is that the THETA V is no longer in production and the Z1 works with wake from sleep from the USB cable.
I realize that this is unfortunate as the Z1 is considerably more expensive than the V. Again, I do not have any special information on RICOH plans. This is just my opinion.