Is Point Cloud Library compatible with other drivers than OpenNI? - point-cloud-library

Is point cloud library compatible with other drivers than OpenNI?

In principle it is compatible with any source of points - you just need a way of finding the 3D points coming from the camera data; most "grabbers" are just wrappers around the sensor's own driver/SDK.
You can find a list of grabbers in the main PCL repository here (including stereo):
http://docs.pointclouds.org/trunk/classpcl_1_1_image_grabber_base.html
Other sensors often have grabbers made available separately by those who use the sensors. E.g. for DepthSense:
https://github.com/taketwo/ds
https://github.com/ph4m/DepthSenseGrabber

Yes, several other drivers offer access to different sensors; as of PCL latest release (1.7.2) these are the following sensors available:
OpenNI (Kinect, Xtion, Carmine cameras)
Velodyne grabber
Dinast grabbert
In addition to the drivers mentioned before the next release (1.8.0) adds new sensors:
IDS-Imaging Ensenso cameras
David SLS-2 scanners
DepthSense cameras
You can find more information about these sensors in the tutorials section of the website and in the documentation.
It is also possible to add any other sensor by adding a grabber in the IO module of the library.

Related

ERRORS while building asterisk using meta-telephony layer

I am trying to build asterisk , I am using meta-telephony layer provided from oe-layers.
I have faced few issued while building the application "asterisk" for raspberry pi 3 b.
Initially I have build core-image-minimal for Rpi and it worked successfully.
Tried to build few applications like lighttpd, SQLite3 and they worked successfully.
Now i am trying to build an application called "asterisk" whose recipe is in meta-telephony -> recipe-asterisk-asterisk-asterisk_13.5.0.bb , but I have encountered few errors.
Need guidance for below Error i have faced
WARNING: Layer telephony should set LAYERSERIES_COMPAT_telephony in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer telephony should set LAYERSERIES_COMPAT_telephony in its conf/layer.conf file to list the core layer names it is compatible with.
Loading cache: 100% |###########################################################################################################| Time: 0:00:00
Loaded 1370 entries from dependency cache.
ERROR: ParseError at /home/bhavya/dialtronics/yocto/poky-dunfell/meta-telephony/classes/waf-samba.bbclass:4: Could not inherit file classes/pythonnative.bbclass
Please kindly help me to solve the issue.
Thanks in advance
bhavya
As far as I see, the last commit on meta-telephony was from 2017. This is long before the Yocto release Dunfell you would like to use.
Mixing meta-layers in different Yocto releases isn't something you do to have fun.
Or you try to find out what release they where using, and go back to these old days. Or you pick up the work and try to maintain a more up to date meta layer.
And to start it, I thing the pythonnative.bbclass is now python3native.bbclass. Note in Dunfell the Python2 support stopped (as in almost all distro?).
BTW: the version in the meta layer is also quite old (13.5.0). Latest version seems to be 17.5.1.

Running Ada on the Zynq using a Digilent Zybo development board

I've been successfully using Vivado and the SDK to develop VHDL and C for the Zynq XC7Z010 on a Digilent Zybo board. I've also been using the GNAT GPS IDE to learn Ada targeted to an STM32F4 processor (using one of the supported development boards).
GPS also ships with a set of zynq7000 run-times targeted to the XC7Z020 (as far as I can tell). Having looked through the BSPs for these target I believe that the code generated should also run on the XC7Z010 as the ARM cores appear to be the same. It may turn out that there are differences, in which case I will have a go at building a specific run-time based on the existing zynq7000 BSP (Adacore have documented this process and give an example for generating a new STM32F4 BSP).
My main problem is I'm not sure how to load and run the generated Ada elf file on my Zybo. I have tried to generate a BOOT.ini file containing a FSBL (built with the SDK and using my exported hardware from Vivado), a bit-stream and the Ada elf file (The the Zybo has an MicroSD interface that can be configured as a boot device, this works perfectly with a bit-stream and C elf produced via Vivado / SDK).
Anyway, this didn't work... I'm guessing that it might be a linking issue, or a boot loader issue, or similar. With my current level of knowledge I'm just not sure at this stage.
Any advice or pointers would be greatly appreciated!
It turns out that my BOOT.ini was fine, the problem was related to accessing custom AXI registers defined in my bit-stream. If I remove these references from the Ada the generated ELF file works perfectly. For example, printing over the Zybo's VCP using Text_IO.Put_Line(), using Ada run-time delay and Clock operations etc.
For some reason the AXI interface isn't working when I boot an Ada ELF file. If I substitute this for the equivalent C, then all is well.
This particular problem is currently unresolved, but not related to my original question!
(It might be that the Ada run-time is relying on the FSBL or u-Boot to have initialised this, not sure. Feel free to comment if you know, I'll also add a comment when I resolve this)
**** Update ****
Here is some additional background and a description of what I had to do to get my custom AXI IPs to work.
The provided AdaCore BSP (Board Support Package used to build the run-time) is targeted at the Xilinx XC702 development board. I'm using a Digilent Zybo (the older version). The two boards use different Zynq parts, the XC702 is based on a XC7Z020 and the Zybo uses a XC7Z010 (there is a new version with a XC7Z020 option).
I followed the AdaCore instructions (available on their web site) and built a BSP specifically for the Zybo. Initially I just updated the clock details as the Zybo runs at a different speed and then verified that the Ada delay function worked correctly (provided as part of the Ravenscar run-time built from the updated BSP). However, my custom AXI IPs still didn't work...
To cut a long story short, the Ada run-time contains as assembly file called start-ram.S that amongst other things sets up the MMU. There is an include file called memmap.inc that contains the actual MMU page definitions as a series of .long directives. I had to update the AXI_GP0 address entry by editing the particular directive to,
.long 0x43c10c16 # for 0x43c00000, axi_gp0
Previously it was set to 0x00000000 # for 0x43c00000, *none*. These entries are decoded within start-ram.S and then used to configure the MMU (the top 12 bits set the page and the remaining bits are chopped up and used as page config).
So, once I edited this file in my Zybo BSP and re-built the run-time, the IPs became accessible from the PS and worked as expected. This all took a while to figure out, but was worth it as I learn loads whilst exploring the dead ends!
I hope this helps someone in the future, I also highly recommend Ada for Zynq development especially if you ultimately need DO-178 certification, or similar.

Can we use mapcreator.here.com data with android sdk?

The area where our customers are using our application made with the here sdk contains mapping errors. We are using the mapcreator web application to fix the errors but the changes do not appear immediatelly in the application as they need to be reviewed before being integrated on the real map server.
Is there a way to export the mapcreator (unreviewed) maps in the map format the sdk is using so that changes would be reflected immediately ?
If not, how long does it take for changes in mapcreator to be reflected in the maps downloaded with MapLoader ?
Thank you
It will take sometime before the map creator data is propagated to our commercial maps.
However, you can use our MapRasterTile APIs to replace just the areas you are interested in with data from MapCreator. Please let us know if you require additional information or a sample.

Error Message: ARC is required to compile Pushwoosh SDK

I am new in xcode.
I got recurring message error when building for testing:
*PWRequest.m
User defined issues
"ARC is required to compile Pushwoosh SDK"*
In code it shows:
#if ! __has_feature(objc_arc)
#error "ARC is required to compile Pushwoosh SDK"
#endif
I don't understand. I added a new pushwoosh sdk.
I thank you very much for your help.
You can set ARC on a file basis. Go to the BuildPhases->CompileSources. You can select sources there and pass ARC flag.
Same as here:
How can I disable ARC for a single file in a project?
but with -fobjc-arc flag
You can use XCode project that comes with the SDK. In this case you'll be linking to the output (library) that is produced by this project.
Hope it helps!
So if you want to use Pushwoosh in your app, you're going to need to turn on ARC in your project settings.
And then you'll be using ARC in your app.
Which is somewhat nicer than doing good old fashioned Manual Retain / Release memory management, yes?
If you are determined to use MRC (manual retain count), then follow the steps in this related question.

Writing a Direct Show Source Filter

I should have to write a Direct Show Filter which
takes input(video,audio) from live source.
And it should give the data(video,audio : which are encoded) to a decoder Filter
MyCustomDirectShowSourceFilter --->
Decoder
Any real working examples which i can build my own source filter and any suggestion for implementation?
Best Wishes
Update:
Basically i want a source filter which takes streams from network and let to handle the parsing and decoding of video stream by another filter.
So when i modify Microsoft sample Push Source Filter and connect to a decoder it does not call FilllBuffer method. The graph simply does not work. I need a source filter example which the output is connected to a decoder not a video renderer or Mux.
The Windows SDK (7.1) contains DirectShow sample filter code, including a source filter, which I've successfully used to build source filters for live devices.
If you have the latest Windows SDK installed, it should be here:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\filters\pushsource
Also, MSDN has great reference material on this topic:
http://msdn.microsoft.com/en-us/library/dd757807(v=vs.85).aspx
If you are still stuck, the March Hare also provides great samples to get peopel started:
http://tmhare.mvps.org/downloads.htm
You can see sample push source mentioned at
https://learn.microsoft.com/en-us/windows/win32/directshow/push-source-filters-sample
Source code for sample push source filter is at
https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/multimedia/directshow/filters/pushsource

Resources