rock-core / base-types Goto Github PK

I've noticed that the pressure type uses float internally, while Angle and Temperature use double. Is there a reason for this?

Eigen.h provides typedefs for common Eigen types like Matrix3d etc.
However it does not provide typedefs for mapping those types.
E.g. right now I have to write something like

Eigen::Map<base::Matrix3d>(arr);

to map an existing array to base::Matrix3d. Using Eigen::Map directly in the code defeats the purpose of hiding the Eigen types. I.e. the code will break if the underlying type of base::Matrix3d is later changed to something else.
Therefore I propose to add typedefs for mapping to Eigen.h.

The RigidBodyState's documentation says the RBS represents the state of the sourceFrame expressed in the targetFrame.
But the angular velocity is expressed in body fixed frame (I'd assume it's the sourceFrame).
Why it's not represented in targetFrame, like the velocity?

Since we use ROS REP 103 as convention, we use x forward, y left and z up for body fixed frames. But then our documentation is talking about world-fixed frames, that should be aligned to North-East-Up.

That seems to be a mistake, and I have never heard of such a NEU convention (which would also switch from right-handed-rule to left-handed-rule).

In accordance with ROS REP 103 we should use either ENU or NED for world fixed frames.

Hi!,

Im using Ubuntu18.04 with ruby version 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]

Base/types build process fails saying:

[ 46%] Generating moc_DistanceImageVisualization.cxx
cd /home/esrocos/ROCK_INSTALL/base/types/build/viz && /usr/lib/x86_64-linux-gnu/qt4/bin/moc @/home/esrocos/ROCK_INSTALL/base/types/build/viz/moc_DistanceImageVisualization.cxx_parameters
/usr/include/boost/predef/language/stdc.h:52: Parse error at "defined"
viz/CMakeFiles/base-viz.dir/build.make:62: recipe for target 'viz/moc_DistanceImageVisualization.cxx' failed
make[2]: *** [viz/moc_DistanceImageVisualization.cxx] Error 1
make[2]: Leaving directory '/home/esrocos/ROCK_INSTALL/base/types/build'
CMakeFiles/Makefile2:140: recipe for target 'viz/CMakeFiles/base-viz.dir/all' failed
make[1]: *** [viz/CMakeFiles/base-viz.dir/all] Error 2
make[1]: Leaving directory '/home/esrocos/ROCK_INSTALL/base/types/build'
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

As a workarround I have change base/types/viz/CMakelist.txt to avoid using moc tool to that file, but is it compiled. Patch applied:

--- CMakeLists.txt_old	2019-02-25 10:37:15.390005000 +0100
+++ CMakeLists.txt	2019-02-25 10:37:31.282005000 +0100
@@ -1,7 +1,7 @@
 rock_vizkit_plugin(base-viz
     PluginLoader.cpp Uncertainty.cpp Vizkit3DHelper.cpp
+    DistanceImageVisualization.cpp 
     MOC 
-        DistanceImageVisualization.cpp 
         LaserScanVisualization.cpp 
         MotionCommandVisualization.cpp 
         RigidBodyStateVisualization.cpp

There are also many, like the one below, warnings but those ones do not affect to the build process.

....ruby.hpp:73:29: warning: ‘template<class'> class std::auto_ptr is deprecated

Josemi.

9cb2df6 added a check for qt4, which breaks the build on systems that only use Qt5, and not vizkit. Could we just move that check into viz/CMakelists.txt?

When running the tests for base::Time::fromString, I get the following error:

test.cpp(426): fatal error in "time_fromString": critical check formatNow.toMicroseconds() == 1339668306001001 failed [1339686306001001 != 1339668306001001]

It looks like a misplaced 8 (686 vs 668), but I really am not sure what the right value should be. Does it run for you @2maz ?

Test application:

#include <vizkit3d/Vizkit3DWidget.hpp>
#include <vizkit3d/PointcloudVisualization.hpp>
QApplication *qapp;
vizkit3d::PointcloudVisualization *plugin;
vizkit3d::Vizkit3DWidget *widget;
base::samples::Pointcloud *pc; 

int main(int argc, char **argv){
    qapp = new QApplication(argc,argv);
    plugin = new vizkit3d::PointcloudVisualization();
    widget = new vizkit3d::Vizkit3DWidget();
    pc  = new base::samples::Pointcloud();
    widget->addPlugin(plugin);
    widget->show();

    Eigen::Vector3d p(1,1,1);
    pc->points.push_back(p);

    if(argc == 2){ 
        Eigen::Vector3d p2(1,1,1);
        pc->points.push_back(p2);
    }else if (argc == 3){ 
        Eigen::Vector3d p2(2,2,2);
        pc->points.push_back(p2);
    }   


    plugin->updateData(*pc);
    qapp->exec();
}

Needed cmake snip:

rock_testsuite(foo test.cpp 
    LIBS ${Boost_THREAD_LIBRARY} ${Boost_SYSTEM_LIBRARY}
    DEPS_PKGCONFIG base-types base-viz vizkit3d
    )

Working with ../build/test/foo 1 2 but not with ../build/test/foo and the strange part not working with ../build/test/foo 1

In base/Pose.hpp our getEuler() method decomposes a base::Orientation into a sequence of rotations using 3 distinct axes (x,y,z).
In that case, one usually speeks of "Tait-Bryan" angles, instead of (proper, classic) Euler angles.

Also, there is a convention (in Germany even a "DIN-NORM" to use a z,y',x'' sequence for yaw-pitch-roll. The documentation's naming scheme is a little bit confusing here, using a2, a1 and a0 names.

see also http://de.wikipedia.org/wiki/Eulersche_Winkel#.E2.80.9Ez.2C_y.E2.80.B2.2C_x.E2.80.B3-Konvention.E2.80.9C_in_der_Fahrzeugtechnik

The documentation of this function says "Checks that the provided JointState is within limits for the values that are valid\n@throw OutOfBoundsException if limits are exceeded."

The actual behavior is: the OutOfBoundsException is thrown if the limits are not exceeded, no exception is thrown if the limits are exceeded:

void JointLimitRange::validate(const JointState& state) const
{
    std::pair<bool, OutOfBounds> check = verifyValidity(state);
    if (check.first)
        throw check.second;
}

JointLimitRange::verifyValidity() returns a std::pair<bool, OutOfBounds> where pair.first indicates whether the joint state is valid.

Please cherypick this patch for master :
maltewi@a7b13cc

See
#13

Is there a particular reason to circumvent the standard library's functions for this allocation?

This could be colliding with the implementation of the clear method, which sets all values to NaN.
Actually this line should pass as a second argument NaN values as well, right?

Couple of weeks ago we discussed to have a timestamp information not only in samples types but in each type introduced and used in the rock.

There was similar discussion a long time ago, but it was related only to command: https://www.dfki.de/pipermail/rock-dev/2013-November/003703.html

The idea is to introduce a header class, which will be inherited by base types and will contain timestamp. Also the header class may contain any other fundamental information.

@doudou @planthaber @moooeeeep @chhtz @skasperski @maltewi @malter @Priyanka328 @m0rsch1 @pierrewillenbrockdfki @haider8645 @0Nel @brean