I am trying to initialize the Primesense Carmine 1.09 using Labview. So far when trying to use OpenNi drivers but they appear to be broken...(I think the problem is with the openni.net.dll). Does anyone know if there is a driver that fits Labview? Or any other solution?
The error I get: "You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes."
Related
I try to convert from pcl::PointCloud<pcl::PointXYZ> to pcl::PCLPointCloud2
But the conversion returns an empty point cloud.
This is my code:
pcl::PCLPointCloud2 cloud_inliers_pcl2;
pcl::toPCLPointCloud2(cloud_inliers, cloud_inliers_pcl2);
I can print out the cloud "cloud_inliers" which is in the
pcl::PointCloud<pcl::PointXYZ>
But the pcl::PCLPointCloud2 returns empty fields
This is a bit late but others searching the same topic may find this useful.
To convert between PCLPointCloud2 and PointT types you can use:
//Convert from PCLPointCloud2 to PointT
pcl::fromPCLPointCloud2(*pc2_cloud_ptr, *xyzrgb_cloud_ptr);
and
///Convert from PointT to PCLPointCloud2
pcl::toPCLPointCloud2(*xyzrgb_cloud_ptr, *pc2_cloud_ptr);
where my pointers to the point cloud are defined as:
pcl::PCLPointCloud2::Ptr pc2_cloud_ptr (new pcl::PCLPointCloud2);
and
pcl::PointCloudpcl::PointXYZRGB::Ptr xyzrgb_cloud_ptr (new pcl::PointCloudpcl::PointXYZRGB);
remember to include:
#include <pcl/conversions.h>
Note however that if you're using the Point Cloud Library (PCL) instead of the Robotics Operating System (ROS) library you don't need to convert but rather just use PointT types (e.g. pcl::PointCloudpcl::PointXYZRGB::Ptr). Some examples in PCL tutorials use PCLPointCloud2 types but I find that PointT types work just as well without needing to convert between the types. I guess that the tutorials are for older versions of the PCL. the downsampling tutorial is a good example: https://pcl.readthedocs.io/projects/tutorials/en/latest/voxel_grid.html
I used a PointT type instead of the PCLPointCloud2 type used in the tutorial and it works fine in PCL 1.11.
Note: I've recently started learning to use the Point Cloud Library for my master dissertation. Happy to learn more about converting between data structures in PCL. The documentation seems insufficient and needs trial and error to understand the data structures.
Is it possible to annotate generated properties/fields with custom units of measure? I noticed that ProvidedTypes.fs provides helper methods for annotating with the built-in F# units of measure, as in the following example:
ProvidedMeasureBuilder.AnnotateType(typedefof<int>, [ProvidedMeasureBuilder.SI "kilogram"])
However, I do not see any clear way to annotate with a custom unit of measure that's referenced in another assembly. Is this even possible? Thanks in advance!
https://github.com/fsprojects/FSharp.TypeProviders.SDK/blob/master/src/ProvidedTypes.fs
UPDATE:
The issues that I was running into apparently had nothing to do with the fact that my units of measure were custom, rather, it was because the types were generated types. By switching to erased types, custom units were simple to implement:
ProvidedMeasureBuilder.AnnotateType(typedefof<int>, [typedefof<SomeObjectInMyAssembly>.Assembly.GetType("Namespace.UnitOfMeasure"))
Does the concept of "arity" solve this problem?
I had a quick look at http://www.erlang.org/doc/man/global.html, but it mostly seems to involve node registration, not resolution by name for functions or atoms.
Does CosNaming (http://www.erlang.org/doc/man/CosNaming_NamingContext.html) deal with this?
If by "name mangling" you mean the concept from C++ then no I don't think they do.
There's no function overloading in Erlang or Elixir. (I tried to find a source to point you to but trust me--it's just not there.) Functions are picked by arity alone and the same function name with two different arities is two different functions. f/0 is different than f/1 which is different from f/2. As #zxq9 pointed out in the comments, due to this property there's no variable arity in Erlang or Elixir either although that can be simulated by passing lists as parameters.
This portion of the Erlang docs discusses how Erlang figures out which function to resolve to. While the mechanism underneath is the same for Elixir the syntax is different.
It just occurred to me, that F# generics do not seem to accept constant values as "template parameters".
Suppose one wanted to create a type RangedInt such, that it behaves like an int but is guaranteed to only contain a sub-range of integer values.
A possible approach could be a discriminated union, similar to:
type RangedInt = | Valid of int | Invalid
But this is not working either, as there is no "type specific storage of the range information". And 2 RangedInt instances should be of different type, if the range differs, too.
Being still a bit C++ infested it would look similar to:
template<int low,int high>
class RangedInteger { ... };
Now the question, arising is two fold:
Did I miss something and constant values for F# generics exist?
If I did not miss that, what would be the idiomatic way to accomplish such a RangedInt<int,int> in F#?
Having found Tomas Petricek's blog about custom numeric types, the equivalent to my question for that blog article would be: What if he did not an IntegerZ5 but an IntegerZn<int> custom type family?
The language feature you're requesting is called Dependent Types, and F# doesn't have that feature.
It's not a particularly common language feature, and even Haskell (which most other Functional programming languages 'look up to') doesn't really have it.
There are languages with Dependent Types out there, but none of them I would consider mainstream. Probably the one I hear about the most is Idris.
Did I miss something and constant values for F# generics exist?
While F# has much strong type inference than other .NET languages, at its heart it is built on .NET.
And .NET generics only support a small subset of what is possible with C++ templates. All type arguments to generic types must be types, and there is no defaulting of type arguments either.
If I did not miss that, what would be the idiomatic way to accomplish such a RangedInt in F#?
It would depend on the details. Setting the limits at runtime is one possibility – this would be the usual approach in .NET. Another would be units of measure (this seems less likely to be a fit).
What if he did not an IntegerZ5 but an IntegerZn<int> custom type family?
I see two reasons:
It is an example, and avoiding generics keeps things simpler allowing focus on the point of the example.
What other underlying type would one use anyway? On contemporary systems smaller types (byte, Int16 etc.) are less efficient (unless space at runtime is the overwhelming concern); long would add size without benefit (it is only going to hold 5 possible values).
I am kind of new to F# so maybe my question is dumb. I wrote a program in F# that used generic types. Compiler determined the types not the way that I desired because I had a bug in the deepest function call that I had instantiated the type to a wrong type. This obviously resulted in type mismatch elsewhere that I had used the type as I had expected. I have to mention to find the root of problem I tried to explicitly enforce the higher level functions to use the types that I desired for the generic type. However the type mismatch was shown in those high-level functions not for the low level function were the type was instantiated. I think it's not very convenient way of determining types because usually it is much easier for programmers to determine the type on higher level functions and this explicit type assignment should result in type error in lower level function were the type has been determined. In my experience it seems automatic type determination of the compiler overrides the explicit type declaration. Am I understanding something wrong here?
Something like the code below:
type test<'a,'b>={Func:'a->'b; Arg:'a}
let C(a)=
a.Func(2)|>ignore
let B(a)=
C(a)
let A(a:test<int64,int64>)=
B(a) //<-----------------------the type mismatch is detected here
Having the error detected on such high level function call makes it difficult to find the root of the problem because now not only I have to look for the bugs regarding the value of variables but also the type determination bugs.
F#'s type inference is (fairly) strict top-to-bottom, left-to-right. See here for a discussion: Why is F#'s type inference so fickle?
You can check this by rearranging your code like this (just for demonstration):
type test<'a,'b>={Func:'a->'b; Arg:'a}
let rec B(a)=
C(a)
and A(a:test<int64,int64>)=
B(a)
and C(a)=
a.Func(2)|>ignore // type mismatch now here
The convenience level depends mostly on the concrete code, in my experience. But I have to admit that I too have sometimes been surprised by type mismatch error messages. It takes some time getting used to.