Skip to content
This repository has been archived by the owner on May 27, 2020. It is now read-only.

Allow frame_id to be configurable. Modify the topic names to use rela… #17

Merged
merged 3 commits into from
Feb 20, 2016

Conversation

bigcmos
Copy link
Contributor

@bigcmos bigcmos commented Feb 19, 2016

…tive namespacing instead of the global namespace to allow flexibility when launching multiple cameras without defining the ns arg. Previous defaults are conserved.

This change is recommended to facilitate multi camera setups. For more details on why topics should be created in the relative namespace rather than the global namespace see ROS REP 0135 and Section 5.2 Relative Names of A Gentle Introduction to ROS by O’Kane.

…tive namespacing instead of the global namespace to allow flexibility when launching multiple cameras without defining the ns arg. Previous defaults are conserved.
@tpanzarella
Copy link

@bigcmos thanks for the patch. Sounds rational and looks good upon quick review. I will try to test it later today. In the meantime, do you mind, updating the version number in package.xml. Updating the the software compatibility matrix in README.md. And, adding a ChangeLog.md entry. Assuming it all checks out when I test it, it will make applying the patch easier.

Thanks again.

@tpanzarella
Copy link

I should mention the version number should bump to 0.2.1.

@tpanzarella
Copy link

Also may want to check test/test_camera.py and test/camera.test to follow these naming conventions. Add running the unit tests to build procedure like:

$ catkin_make
$ cd build
$ make run_tests
$ cd ..
$ catkin_make -DCMAKE_INSTALL_PREFIX=${LPR_ROS}/o3d3xx install

@bigcmos
Copy link
Contributor Author

bigcmos commented Feb 19, 2016

Will do that this morning and update the patch request.

@bigcmos
Copy link
Contributor Author

bigcmos commented Feb 19, 2016

Having an issue running the tests. I tried checking out HEAD to origin/master for o3d3xx-ros. See the error below. The test appears to connect to my o3d303 sensor when running. I have non default configurations running on the sensor. Could that be the issue? I haven't dug too deep into the error yet, and would love some feedback on how to fix this. I was also planning on upgrading the firmware on the sensors today. Let me know if you need more info to diagnose.

o3d3xx.rosunit-test_camera/test_camera][FAILURE]-------------------------------
False is not true
  File "/usr/lib/python2.7/unittest/case.py", line 331, in run
    testMethod()
  File "/home/acme/dev/gob/catkin_ws/src/acme_ros/third_party/o3d3xx-ros/test/test_camera.py", line 73, in test_camera
    self.success = self.compute_cartesian()
  File "/home/acme/dev/gob/catkin_ws/src/acme_ros/third_party/o3d3xx-ros/test/test_camera.py", line 172, in compute_cartesian
    self.assertTrue(x_mask.sum() == 0)
  File "/usr/lib/python2.7/unittest/case.py", line 424, in assertTrue
    raise self.failureException(msg)

@tpanzarella
Copy link

Do you have an extrinsic calibration applied on the camera itself (i.e., stored via the XML-RPC interface)? That would definitely cause this test to fail.

Otherwise, I would try to get all of the versions aligned: firmware, libo3d3xx, o3d3xx-ros and then run again. This test is basically using the off-board computation of the Cartesian data vs. ground truth (i.e., Cartesian data computed by the sensor) as a proxy for testing all sorts of things:

  • Getting data from camera
  • Dynamically switching PCIC schemas
  • Various image buffers (xyz, radial distance, extrinsics, unit vectors, etc.)
  • tf transform
    etc....

@tpanzarella
Copy link

IIRC, there was a bug in the firmware with the unit vectors prior to some recent version. @graugans would know which version for sure. So, updating the firmware may do the trick. libo3d3xx should be up to date to the latest released firmware now. It is available in the firmware directory.

@tpanzarella
Copy link

BTW, o3d3xx-reboot (in the latest version) supports a -r switch to reboot into recovery mode. Using this, you can then hit the camera's internal http server (port 8080) to update the firmware w/o having to boot Windows and use Vision Assistant.

@bigcmos
Copy link
Contributor Author

bigcmos commented Feb 19, 2016

Thanks for the tips. Firmware upgrade did the trick and o3d3xx-reboot -r is convenient. On a side note, Is there a command line way to push new firmware to a sensor? As I grow the fleet this is going to be important to automate.

Here are the commands I ran for testing:

$ catkin_make --only-pkg-with-deps o3d3xx
$ catkin_make run_tests --only-pkg-with-deps o3d3xx
...
[o3d3xx.rosunit-test_camera/test_camera][passed]

SUMMARY
 * RESULT: SUCCESS
 * TESTS: 1
 * ERRORS: 0
 * FAILURES: 0
...
$ catkin_make install --only-pkg-with-deps o3d3xx

@tpanzarella
Copy link

Cool. Glad that was the fix.

Currently there is no command line flashing utility. But, I believe @graugans is working on one though: ifm/libo3d3xx#34

Yeah, one of the goals of the cmdline utils is to make managing fleets of cameras as easy as possible.

tpanzarella added a commit that referenced this pull request Feb 20, 2016
Allow frame_id to be configurable. Modify the topic names to use rela…
@tpanzarella tpanzarella merged commit 9791912 into ifm:master Feb 20, 2016
@graugans
Copy link
Member

@bigcmos at the Moment I am very busy so it will take some time before I can finish this. But I'll post some demo code. It is pretty easy.

@tpanzarella
Copy link

As mentioned in my last comment at ifm/libo3d3xx#34 best to wait on integrating this script until libo3d3xx 0.4.0. Reorganization / modularization to the code base likely to be released next week.

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

Successfully merging this pull request may close these issues.

3 participants