Ask Your Question
1

ROS compatibility for accurate UWB positioning sensor [discussion]

asked 2015-06-19 10:15:29 -0600

Samuel gravatar image

updated 2015-06-21 10:45:12 -0600

Hello,

my name is Samuel and I am one of the creators of Pozyx, an indoor positioning system that I would like to make ROS compatible. Our system is currently running on kickstarter. We are using ultra-wideband (UWB) radio signals to accurately measure the distances to some anchors for positioning (the signals can pass through walls or objects). This allows us to accurately estimate the position indoor. We have recently achieved our funding goal and as a stretch goal we are going to make sure the system is ROS compatible. By means of this post I would like to know what kind of functionalities should be supported by the Pozyx platform to make it compatible for ROS?

Some more information about the platform: The tag is equipped with an UWB transceiver, a gyroscope, accelerometer, magnetometer and pressure sensor. The onboard microcontroller (STM32F4) is in charge of the ranging protocol, messaging protocol, the tracking algorithm, sensor fusion, anchor calibration and all the other stuff to make the board act like a sensor: communication, configuration, etc.

Any input would be much appreciated. Thanks

edit retag flag offensive close merge delete

Comments

Hi Samuel, I am very interested in your Pozyx project, can I have your Email for more details, my email is "nozeroxue@gmail.com" .

NicoNie gravatar imageNicoNie ( 2017-09-18 04:21:44 -0600 )edit

2 Answers

Sort by » oldest newest most voted
2

answered 2015-06-19 10:59:58 -0600

gvdhoorn gravatar image

updated 2015-06-19 12:35:32 -0600

Have you thought about how you actually want to integrate with a ROS node graph (ie: communicate with the master and other nodes)? rosserial or any of the other minimal bridging approaches come to mind. Two options you might want to look at are cROS and the work Bosch is doing for the STM32F4. The former is a 'full' ROS client library implementation in C, while the latter is more rosserial inspired.


Edit: An alternative to running a full Node on your device (either through bridging, or a client lib) could be to provide a ROS driver for your device. If you have a byte stream or something that you can make available to the 'other end' of a serial (or other easy to establish) connection, a ROS Node dedicated to de-serialising that stream, interacting with your device and publishing msgs to appropriate topics (like the ones suggested by @dornhege) could also work. Examples of this approach are the nmea_navsat_driver, urg_node, velodyne or any of the IMU drivers (um7, razor_imu_9dof fi).

Having said that, your sensor as a node is both sexier and has a higher degree of plug-and-play than any bridging or driver approach. It is also technically more challenging though.

edit flag offensive delete link more

Comments

Because our system is Arduino compatible, rosserial_arduino looks like a very straightforward approach. However, directly implementing it on the board would be more elegant. We are using FreeRTOS already so the last library looks very interesting, thank you.

Samuel gravatar imageSamuel ( 2015-06-19 11:28:11 -0600 )edit

Just wondering though, we are using I2C now for communication. Is it possible to connect this directly to a ROS platform?

Samuel gravatar imageSamuel ( 2015-06-19 11:31:29 -0600 )edit

I'm not sure I completely understand you: most ROS systems are run on normal desktop PCs. I'd say that there are very few that have i2c capability out-of-the-box. Perhaps you should clarify what you mean with "make it ROS compatible": should it be a standalone node, or depend on an additional PC?

gvdhoorn gravatar imagegvdhoorn ( 2015-06-19 11:54:37 -0600 )edit

Ok :) I thought ROS was primarily used on robots. So people could add sensors (like Pozyx) to the robot, connected by means of I2C, SPI, USB .. and then get all the measurements centrally and organized within the ROS framework to make intelligent decisions and steer the robot.

Samuel gravatar imageSamuel ( 2015-06-19 12:04:35 -0600 )edit

It is used on robots, but those robots still need computers :). And those computers (could be desktop PC hw) don't necessarily have I2C or SPI. USB, serial, ethernet: yes. Bridging is an accepted strategy for connecting embedded devices to a device running a full ROS (node).

gvdhoorn gravatar imagegvdhoorn ( 2015-06-19 12:20:47 -0600 )edit

Oké thanks. Love it by the way that you are using the word sexier :)

Samuel gravatar imageSamuel ( 2015-06-21 10:44:35 -0600 )edit
1

When you're thinking about rosserial, test the Imu message before. I have not yet seen someone getting that size of message to work with rosserial directly, so you might need an extra driver-node anyways. Maybe that is fixed by now, it's been a while since I tested it.

dornhege gravatar imagedornhege ( 2015-06-22 04:18:40 -0600 )edit
1

answered 2015-06-19 10:47:17 -0600

dornhege gravatar image

For the pose I'd probably prefer TF and/or just sending geometry_msgs/PoseStamped. For the IMU data, there is sensor_msgs/Imu that you can just send normally. There seems to be a FluidPressure message in sensor_msgs, too.

TF sending should imo be optional and configurable, i.e., TF is only sent when enabled, parent/child frames should be parameters, and ideally one can switch between sending the pose or inverse pose.

edit flag offensive delete link more

Comments

Ok thank you. And what about the raw distance measurements to the anchors? Is there something for that? (my apologies I am rather new to ROS)

Samuel gravatar imageSamuel ( 2015-06-19 10:54:27 -0600 )edit

Not that I know of. There are the general messages that are just arrays of double in std_msgs.

dornhege gravatar imagedornhege ( 2015-06-19 11:05:53 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2015-06-19 10:15:29 -0600

Seen: 2,158 times

Last updated: Jun 21 '15