I am currently looking at using the CUDA supported codebase within PCL 1.9.1 , in an attempt to improve the performance of a 3D SLAM algorithm which I am testing, via CUDA.
I am facing issues compiling and noticed that the header files for the pcl_cuda namespace was not installed via "make install". Further search brought me to this issue opened two years back where the development of the CUDA implementations have been dropped (https://github.com/PointCloudLibrary/pcl/issues/2021)
Are anyone aware on the current status on the CUDA support for PCL?
Thanks
CUDA support in PCL was and is highly experimental and is currently under maintenance mode only i.e., no new features are expected to be added in the near future. As mentioned in the issue you linked, the original developers are no longer active in the project.
That being said, you can still compile and install both cuda and gpu modules. So the fact that they are not being installed is a whole different topic. Did you enable
cmake .. -DBUILD_CUDA=ON
when invoking cmake the first time? These modules are not enabled by default, so you need to compile pcl from source to enable them.
Related
I'm trying to understand how to cross-compile for a Raspberry PI3.
First, let me check if I understood correctly the meaning of the cross-compiling: is it to compile for a hardware that is different from the machine I'm building my application? This means, building for example a linux application from a windows system?
Second, all the tutorials I found required the building of QT for the target platform. Is this because to build a QT application I need the target-hardware-specific-built-version of QT libraries? Why there are no pre-built versions?
Third, I don't understand why a raspberry image is required in all the tutorials I could find.
Those are some of the tutorials I found, I found really strange that such a long setup is needed to cross-compile an application and I'm just wondering if what I'm trying to do (compile from a Linux machine a raspberry-pi3 QT application) is what those articles are really describing.
Tutorial 1, Tutorial 2, QT official embedded device page
You are correct, cross-compiling is building on one type of hardware (Host) to run on a different type of hardware (Target).
If you are willing to go for a commercial version of Qt, Qt will provided a turnkey solution (Boot to Qt) for developing on a specific Raspberry Pi. By turn-key, I mean they have all the target tools for cross compiling and the correctly built libraries for the target, etc. It's not cheap, and probably not the way to go for the hobbyist.
If you go with the open source (free) version of Qt, you will need to do most of the setup work yourself. The reason you are having a hard time finding everything built for you are mostly related to two things: The size of the distribution, and what you are building for what (i.e. which Qt version for which Raspberry Pi and which Raspberry Pi Linux version and which drivers, etc.).
The Raspberry Pi image is needed as you need the correct libraries to build Qt against. The cross-compilation tools need to link against the target (Raspberry Pi) images.
Yes, it is a long process to setup a Qt cross compilation environment, but it only needs to be done when once for each Qt version. Once you have setup the environment, building and deploying a Qt application on the target Raspberry Pi is really quite fast and easy.
I recently learned about JavaFX not being included in Java 11, and have a question about how this will work.
Right now, I maintain an application that targets Java 8, uses mostly Swing but some JavaFX, and has a non-developer user base. Some of those users are on older operating systems, so I'd like to continue targeting Java 8.
However, Java 11 comes out next month, and I'm concerned that some of the users on newer operating systems will upgrade to Java 11, and the JavaFX components of the application will cease to work.
So what is the best path forward if you wish to continue targeting Java 8, but have JavaFX work for those who install JRE 11? I see several options, none of which are perfect:
Require installing JavaFX separately. If so, I'll need to know which edition - most likely the OS-specific SDK from https://gluonhq.com/products/javafx/? Not ideal since it's another install, but I already have instructions for installing Java for those who don't have it.
Bundle a JRE and JavaFX, and have startup scripts that force the use of that JRE. Not ideal because the download size would drastically increase, and it would require separate downloads per OS, but I've made distributions that bundle a JRE before.
Fall back on Swing instead of JavaFX if Java 11+ is detected. I could potentially do this, since my application started out as Swing and only a fraction has migrated, but it's also not attractive since the newer, JavaFX-specific functionality I've added would be lost.
Try including the JavaFX runtime as a .jar file and loading it on the classpath manually, perhaps only if Java 11+ is detected?
I'm curious what your thoughts are, and if there's a better option I've overlooked. I didn't anticipate JavaFX being removed from the JRE someday when I adopted it!
To my opinion the days where you asked your users to install Java on their client machines is over. The better solution is to create an operating system dependent installer which bundles everything with the application. I am also wondering if the size of such a bundle still really matters. A single video downloaded from YouTube is probably much bigger. Instead, by bundling you save yourself a lot of headaches.
I have been working with QML for a couple of weeks now. But now a new requirement has risen where I have to check whether I can run QT5 in an embedded device for my project. I need this for my GUI related operations. The device has an ARM processor (Intel ARM920T-PXA27x processor to be exact) with 64 MB RAM. 32 MB will be taken up for the OS and the rest will be available for application and QT.
I have to check whether this is possible. I have googled for some references and unable to find a suitable answer to my requirement with QT5. I need the GUI libraries but my project does not have advanced graphical requirements like swiping or animations. It contains basic controls like texts, buttons and lists/grids. Since I am new to QT especially to this part, I would like to hear whether
1) Is this a viable option and should I keep digging more into this? Any feedback would be welcome to know if it's worthy to spend time to attempt this or if it's a lost cause.
2) If there are options, could you point me in the right direction to look more into this?
It depends on the OS you are running on your SOC.
It's definitely possible when running Linux. You can e.g. use Qt Lite for configuring a minimal static build of Qt. Then you deploy your statically linked application to the device. You can check this blog post for experiences with Qt Lite.
One possibility is to go with Qt for Device Creation for the whole embedded Linux based software stack which boots to a UI implemented with Qt technologies.
I have installed Qt5 libraries in windows but there is no document about Qt3D in Qt assistant.
Is Qt3D a part of Qt5 or it has been removed from release version 5?
Yes. Qt 3D became a standard Qt library in the Qt 5.7 release.
With Qt 5.7, we are bringing in the Qt 3D module. This module has been
available as a Technology Preview for two releases now, and I’m happy
to announce that it has now reached the state where it is becoming a
fully supported member of the Qt family!
This addition was a long time coming. Roughly 4.5 years ago, they announced they were dropping it from the Qt 5.0 release. Since then, it's undergone significant rework. Now, seven minor versions later, it's finally made it back in.
The other answer & comments were correct at the time, but the situation has now changed.
As of Qt5.5, Qt3D is now included as a "technology preview" (I interpret this phrase as an indication that it's not deployment-ready, so there could be some bugs and the API could change).
It's very important to note that the Qt3D that was available for previous versions of Qt has been Qt3D 1.0, while the version included with Qt5.5 is v2.0, which has been developed by a different software team and has a very different API.
More info from the new developers available here.
Note also that Qt3D v1.0 was never actually included 'properly' with Qt in any version, though was (apparently) reasonably easy to build along with Qt if checked out from git from v5.0 through 5.4.
I know it is weird but I need to execute a Qt GUI application that supports X11 protocol on MS Windows platform.
It is obvious that if I build my Qt source code in Unix environment it automatically becomes an X11 application and this application can be run only on Unix Operating Systems, not MS Windows.
I tried to use MXE (MinGW cross environment) to compile my application in Unix for Windows, but it does not help for X11 issue. It creates an application for Windows but the application is not an XWindow application.
There is also a XPortMinGW project for minGW. But I do not know if it works for Qt applications.
Is there any way to build my Qt application with X11 support that can run in Windows OS?
I don't think that there's any need for cross-compilation. There are two problems:
Getting Xlib compiled for Windows. I don't know offhand of any maintained Xlib implementations that are ported to Windows. You will definitely need to find one, or make one. Hopefully Xlib depends only on a handful of posix APIs and they may be easy to translate to win32. Forget about Cygwin.
You may have luck porting Xlib yourself to Qt's network backend and making it cross-platform in the process, too. Xlib would simply use the core and network modules of Qt. No problem with that.
The good news here are that Qt 5 comes with a bundled Xlib implementation. It would be presumably much easier to get that to compile on Windows than some other implementation.
Configuring Qt to build using said Xlib on Windows. To do it right, you'll probably want to mess a bit with and rebuild the configure tool that comes with Qt, and add a makespec that will link with the Xlib.
This should be much easier to do with Qt 5.
It's not an entirely trivial thing to do, but should be possible. Give yourself a month and expect to get very intimate with some details of Qt's configuration and Xlib.
Notes About Cygwin
If your application is closed-source and distributed outside of your organization, you need to buy a commercial license in order to redistribute cygwin.dll. Otherwise, Cygwin is GPL and merely linking to cygwin.dll makes your application a derived work.
Cygwin becomes problematic when you mix posix- and non-posix code in the same application, especially if the non-posix code is a large framework like Qt. You can of course use the Posix platform code in Qt and make it all run on Cygwin, but that way you lose performance and expose yourself to shortcoming of Cygwin's emulation of POSIX APIs.
Using Cygwin for Xlib / windowing system but having Qt otherwise use Windows APIs may require a lot of tweaking for Qt code. So may using Qt with Xlib on Windows of course, but at least you don't have to debug/work around Cygwin's quirks.