Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add VREP conversion methods for MRPT class objects #13

Open
wants to merge 12 commits into
base: vrep_convert
Choose a base branch
from

Conversation

shubham-kumar1410
Copy link
Collaborator

Added methods (Issue #3)

  • Add conversion method and gtest for CObservation2DRangeScan class
  • Add conversion method and gtest for CPose3D class
  • Add conversion method and gtest for CObservationOdometry class

Copy link
Collaborator

@bergercookie bergercookie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments in various parts of the code.
As general comments, also note the following:

  1. Add some instructions in this PR of how are we supposed to test the functionality of this code.
  2. Please, please, don't ignore compiler warnings! This time you could have caught the bug if you had dealt with it

As general comments, with regards to the style of this PR, obviously its not a major thing as we'll be adding automatic formatting using clang-format, but still I think the following is useful to know:

  • Don't add trailing spaces at the end of lines. You might not even be aware of that as they may not be visible in your editor, but when using tools like git-diff they are irritating to see. Also, modifiying them also marks the line as modified and thus it appears as part of the commit.

  • Watch your indentation.

Depending on the editor that you use I'm pretty sure there are options for both showing the trailing white spaces (or even automatically trimming them) and handling the indentation correctly. See MRPT CONTRIBUTING.md for the indentation rules. 

set(test_sources "test/runTests.cpp")
add_executable(${PROJECT_TEST_NAME}
${test_sources})
set(test_sources
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The V-REP related files should be compiled in a library of their own. Also do that in the main CMakeLists file so that all the MRPT algorithms can make use of it.

Also watch the indentation here, seems to be one space off.

@@ -29,15 +35,17 @@ if (EXISTS "$ENV{VREP}")

set (VREP_PATH "$ENV{VREP}/programming" CACHE "The VREP build path" STRING)

set (SOURCES
set (SOURCES
include/mrpt_bridge/vrep_conversion.h
${VREP_PATH}/remoteApi/extApi.h
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Watch the indentation here again.
Isn't there a setting in your editor for adding the correct number of spaces/tabs automatically?


include_directories (${VREP_PATH}/remoteApi ${VREP_PATH}/include)
include_directories (${VREP_PATH}/remoteApi ${VREP_PATH}/include include)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The V-REP related sources/libraries.. should be handled in the main CMakeLists.txt file

}
}
namespace vrep_bridge
{ bool convert(const float _range[], const simxFloat& _maxScanDistance,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Document these methods with doxygen.

Add method, parameters [in, out] and return type descriptions to them etc.

@@ -0,0 +1,36 @@
#ifndef VREP_CONVERSION_H
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • MRPT <-> V-REP conversions should be added to the conversions subdirectory instead of the mrpt_graphslam_2d/include/mrpt_bridge. Remember that they may be by other MRPT libraries other than mrpt_graphslam_2d. Same goes for the vrep_conversions.cpp. Why is the latter under mrpt_graphslam_2d/remoteApi/?

CObservation2DRangeScan obj;
EXPECT_TRUE(convert(range,maxScanDistance,scanningAngle,sensor_pose,obj));
EXPECT_TRUE(obj.rightToLeft);
EXPECT_EQ(obj.aperture, scanningAngle);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As pointed out by @maxchaos comparing float/double values with EXPECT_EQ is strongly discouraged. googletest also points this out in their Advanced Guide


TEST(ConvertTest,CPose3DTest){
simxFloat position[3] ={1.00,1.00,1.00};
simxFloat quaternion[4] = {0.5,0.5,0.5,0.5};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not enough data to be sure about this functionality. Have at least ... 3 different cases. Also you aren't actually testing the expected results in the CPose3D but only its pitch value!

simxFloat position[3] ={1.00,1.00,1.00};
simxFloat quaternion[4] = {0.5,0.5,0.5,0.5};
CPose3D pose;
EXPECT_TRUE(convert(position,quaternion,pose));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't a helpful asserrtion; your convert methods always return true anyway.

EXPECT_EQ((double)pitch,pose.pitch());
}

TEST(ConvertTest,CObservationOdometryTest){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor style thing, but be consistent of where to place the bracket ... is it going to be at the end of the line or the beginning of the next?

EXPECT_EQ(obj.sensorPose,sensor_pose);
}

TEST(ConvertTest,CPose3DTest){
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add simple docstrings of what these tests do

namespace mrpt
{
namespace obs
{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the C++17 PR you can now use nested namespaces to cleanup such parts of code

CPose3D pose;
EXPECT_TRUE(convert(position,quaternion,pose));
float pitch = asin(-2*((quaternion[0]*quaternion[2])-(quaternion[1]*quaternion[3])));
EXPECT_EQ((double)pitch,pose.pitch());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXPECT_EQ() should not be used with floating numbers...
Please, take a look at: https://github.com/google/googletest/blob/master/googletest/docs/AdvancedGuide.md#floating-point-comparison

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have taken care of that in my new commit

using namespace vrep_bridge;

/**
*This unit test tests the CObservation2DRangeScan conversion method. It tests the following parameters of the object created with the functions parameters.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

namespace vrep_bridge
{ /**
*This method converts VREP laser scans into a CObservation2DRangeScan class object. It has the following arguments:
*- <b>_range[]</b> -> This array contains all the laser scan measurements(distances).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for bold there..

Use @param [in] or @param[out] here instead

https://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdparam

return true;
}
/**
*This method converts pose,velocity and angular velocity value of an object into a CObservationOdometry class object. It has the following arguments:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very very minor but.. no need to repeat the This method .... Start with the verb instead..

Convert sensor position...

@@ -0,0 +1,26 @@
#ifndef VREP_CONVERSION_H
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have an mrpt_bridge subdirectory?
Why not put the vrep_conversions directly under include?

#ifndef VREP_CONVERSION_H
#define VREP_CONVERSION_H

#include <stdint.h>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use C++ style includes

*
*/
TEST(ConvertTest, CObservation2DRangeScanTest)
{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should be checking the actual data of the laser scan.

Grab an actual simulated laser scan from V-REP..

Write its contents to an e.g., textfile (or just dump them in the cpp file for now. Then in this test function read them back, convert them to a CObservation2DRangeScan and check that the data of the latter object is still there as it should be...

This may require some tinkering with capturing the data and reading /writing that text file but it is the most definitive way moving forward to make sure that the convert method produces the expected results...

Refer to this as an example: https://github.com/MRPT/mrpt/blob/master/samples/slam_icp_simple_example/test.cpp

Let me know if you need a more detailed explanation on this

#include <mrpt/obs/CObservationOdometry.h>
#include <mrpt/poses/CPose3D.h>
#include "../../conversions/include/mrpt_bridge/vrep_conversion.h"
#include "mrpt/obs/CObservation2DRangeScan.h"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason you switch from <...> to "..."?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was following google style guidelines. Let me know if I need to revert back.

0.446379f ,0.446323f ,0.446342f ,0.443543f ,0.444175f ,0.444877f ,0.442981f ,0.444239f ,0.445565f ,0.444401f ,
0.446282f ,0.446131f ,0.448157f ,0.44866f ,0.451289f ,0.452373f ,0.455437f ,0.457836f ,0.460719f ,0.465214f ,
0.471546f ,0.485626f ,
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you tested that these values are written correctly or are you still working on this?

Copy link
Collaborator Author

@shubham-kumar1410 shubham-kumar1410 Jun 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes these values were received from vrep and they have been tested

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that's not what I mean. I want to have the values, one by one checked whether they are written correctly in the CObservation2DRangeScan object.

Loop through that array and check each value, one by one.

*- <b>_position[]</b> -> This array contains x,y,z coordinates of the sensor.
*- <b>_quaternion</b> -> Contains the quaternion vector of the sensor.
*
*Converts sensor position,quaternion into a CPose3D class object. It has the following arguments:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor but don't stick the letters next docstring asterisks

0.446379f ,0.446323f ,0.446342f ,0.443543f ,0.444175f ,0.444877f ,0.442981f ,0.444239f ,0.445565f ,0.444401f ,
0.446282f ,0.446131f ,0.448157f ,0.44866f ,0.451289f ,0.452373f ,0.455437f ,0.457836f ,0.460719f ,0.465214f ,
0.471546f ,0.485626f ,
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, that's not what I mean. I want to have the values, one by one checked whether they are written correctly in the CObservation2DRangeScan object.

Loop through that array and check each value, one by one.


namespace vrep_bridge
{ /**
*Converts VREP laser scans into a CObservation2DRangeScan class object. It has the following arguments:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed this.

The doxygen comments should be put in the declaration of the methods i.e., in the .h file

@bergercookie
Copy link
Collaborator

Hey @shubham-kumar1410 you still haven't addressed some comments of mine..
Check the outdated (as marked by github) comments as some of them are still relevant.

@shubham-kumar1410
Copy link
Collaborator Author

Hi @bergercookie , I have pushed a commit with what I believe are all the issues addressed by you. Kindly let me know if I missed something.

@bergercookie
Copy link
Collaborator

Hi @bergercookie , I have pushed a commit with what I believe are all the issues addressed by you. Kindly let me know if I missed something.

  1. You have added the vrep shared library in the main CMakeLists.txt file. Now link against it in the conversions and graphslam_2d CMakeLists.txt files as well instead of readding the SOURCES files

  2. Don't do this: #include <stdio.h>. Instead do this #include <cstdio>.

And that is for every one of the includes not just stdio.

  1. include_directories (${VREP_PATH}/remoteApi ${VREP_PATH}/include include)

You just have to do this once in the main CMakeLists.txt file

@shubham-kumar1410
Copy link
Collaborator Author

I have linked the vrep shared lib with the graphslam_2d CMakeLists.txt. And also have changed the header styles. Kindly have a look

@shubham-kumar1410
Copy link
Collaborator Author

Let me know if there are any other changes. @bergercookie

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants