Forum Replies Created
-
Posts
-
The Wayback Machine says the filename for the “Shaping Watersheds Augmented Reality Sandbox” publication was “Shaping-Watersheds-AR-Sandbox-Facilitation-Guide.pdf”. Searching for that filename gives a few likely results. Is this the guide you’re looking for?
Could you post the full output for
bash Build-Ubuntu.sh? There will be detailed info in there that may point to the problem source.libusbx is not used. The README mentions it for historical context. libusbx was merged into libusb.
Is it possible because of using LM21 the Kinect toolkit has some kind of conflict or missing library?
Yes, but such a conflict or missing dependency is most likely to show up during compilation.
IMHO, the heart of the problem you are seeing is that the Kinect is appearing on the wrong USB bus.
When I pass my Kinect V2 USB connection into a LM 21 container and run lsusb, I get the following output.
Bus 003 Device 002: ID 045e:02c4 Microsoft Corp. Xbox NUI Sensor Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hubEvery lsusb output you have posted shows the Kinect on the same Bus as the “2.0 root hub”. I think you could have success on the LM forums by asking for help about this specific issue: why is the Kinect V2 on USB 2 and not USB 3?
I suspect the final answer to this will be to replace the Kinect power supply/USB adapter with a different model.
My strong suspicion is that your Kinect is malfunctioning.
- Reports as a V2.
- Will not connect as a USB 3 device.
- Serial numbers do not match.
The serial numbers (external and reported by KinectUtil) on my Kinect V2 match.
Can you borrow another Kinect to try out?
@solanic Sorry, I missed this post before.
What output do you get with
sudo /usr/local/bin/KinectUtil list?A couple quick ideas:
- Disable fast boot in BIOS.
- Disable secure boot in BIOS.
- Do you have an EFI partition on the SSD? Files needed to boot will be placed in there.
- Can you boot from the USB Drive and run “Boot Repair” on the SSD?
To directly answer your question: from an API and ABI perspective, there is very little difference between Linux Mint (LM) 19 and LM 19.3. The Sandbox build and install instructions should be the same for both versions.
Generally in Linux software, major version changes may contain breaking changes. (See the recent threads on installing the Sandbox software on LM 21.) But, minor version changes should only contain fixes. Often, a binary compiled for LM 19 will run on LM 19.3 without needing to be recompiled.
On a separate note. In previous years, laptops were not recommended for running the Sandbox software due to the fast graphics required. With the speed of recent laptops this may not be a problem. But, keep in mind that if you are not happy with your Sandbox performance, you may want to change to a desktop computer.
I’ve been trying to reply to you in those threads, but my posts fail with an error. I’ll use new verbiage to try to skirt around previous errors.
Connect the Kinect to the front if your computer, not the back.
…so i need to search for the rain…
Have you read “No rain under my hand”?
Congratulations! Now the fun of construction and calibration can begin?
I assume that when @okreylos moves to LM21 the missing include could be added to Vrui for the next release. I don’t think this would cause
backward-compatible problems.Changing the libdc1390-dev package name will probably be part of an update to Build-Ubuntu.sh when Ubuntu 22.04 LTS and LM21 become recommended distributions. Until that time, the current package name is proper for LM19.
Missing 1 line of code?
I misread the error and the Linux Mint forum poster is right, the cstddef header is not included in FrameRateViewer.h.
I have been able to build Vrui (and the full AR Sandbox software) in a LM21 virtual machine with two changes. First, the version number has been removed from the libdc1390-dev package. Edit Build-Ubuntu.sh to change libdc1390-22-dev to libdc1390-dev.
Second, FrameRateViewer.h needs to be patched before building. Add a new line to Build-Ubuntu.sh before “make -j$NUM_CPUS INSTALLDIR=$VRUI_INSTALLDIR” (line 65). The added line should contain “patch -p1 < ../../Fix-missing-size_t.patch”.
Create a new text file in the same directory as Build-Ubuntu.sh. This file should be named Fix-missing-size_t.patch and contain the following text.
--- a/Vrui/Vislets/FrameRateViewer.h 2019-07-17 13:48:41.000000000 -0700 +++ b/Vrui/Vislets/FrameRateViewer.h 2022-08-24 09:05:57.472284693 -0700 @@ -27,6 +27,8 @@ #include <GL/GLNumberRenderer.h> #include <Vrui/Vislet.h> +#include <cstddef> + namespace Vrui { namespace Vislets {Remove the old src directory (if still around) and run the new Build-Ubuntu.sh. Let me know if this works or not.
