How to check the numeric array types in the message received from ROS

[Chi]

I am trying to implement the rosbridge protocol in Nodejs, but I am stuck at implementing the CBOR encoding part.
I have looked at the source code of rosbridge_suite, and it checks the corresponding data type before encoding.
The data received from subscribe callback is just a built-in array, not a typed array(TAGGED_ARRAY_FORMATS in the source code). I think I need to check the array type just like what the source code does before encoding into a buffer, and send it to roslibjs for example.

[Christian Fritz]

I've noticed that the two links you provided both point to the ros2 versions of the protocol, however rosnodejs is for ROS1 only so far. Just to check: you still want to implement the rosbridge protocol for ROS1, right?

[Chi]

I've noticed that the two links you provided both point to the ros2 versions of the protocol, however rosnodejs is for ROS1 only so far. Just to check: you still want to implement the rosbridge protocol for ROS1, right?

sorry, forgot to change the branch, and Yes, I want to implement the protocol for ROS1, this is the ros1 source code

[Christian Fritz]

Could you use the ros message type of the subscribed topic to figure out what type of values are in the array?

[Chi]

Could you use the ros message type of the subscribed topic to figure out what type of values are in the array?

You mean using like this

const a = Rosnodejs.require("nav_msgs");
const b = new a.msg.OccupancyGrid();
console.log(a.msg);
console.log(b);

but this output:

{
  Path: [class Path],
  Odometry: [class Odometry],
  MapMetaData: [class MapMetaData],
  GridCells: [class GridCells],
  OccupancyGrid: [class OccupancyGrid],
  GetMapFeedback: [class GetMapFeedback],
  GetMapActionGoal: [class GetMapActionGoal],
  GetMapAction: [class GetMapAction],
  GetMapActionFeedback: [class GetMapActionFeedback],
  GetMapGoal: [class GetMapGoal],
  GetMapActionResult: [class GetMapActionResult],
  GetMapResult: [class GetMapResult]
}
OccupancyGrid {
  header: Header { seq: 0, stamp: { secs: 0, nsecs: 0 }, frame_id: '' },
  info: MapMetaData {
    map_load_time: { secs: 0, nsecs: 0 },
    resolution: 0,
    width: 0,
    height: 0,
    origin: Pose { position: [Point], orientation: [Quaternion] }
  },
  data: []
}

It's not the same as rosmsg show nav_msgs/OccupancyGrid

std_msgs/Header header
  uint32 seq
  time stamp
  string frame_id
nav_msgs/MapMetaData info
  time map_load_time
  float32 resolution
  uint32 width
  uint32 height
  geometry_msgs/Pose origin
    geometry_msgs/Point position
      float64 x
      float64 y
      float64 z
    geometry_msgs/Quaternion orientation
      float64 x
      float64 y
      float64 z
      float64 w
int8[] data

[Chi]

Never mind, I'm aware that NodeJs is not suitable of CPU intensive tasks. I'm not going to implement this feature

[Christian Fritz]

I wouldn't say that. Node.js has higher performance than python (because it is compiled, not interpreted) and the current rosbridge is implemented in python I believe.

[Chi]

I wouldn't say that. Node.js has higher performance than python (because it is compiled, not interpreted) and the current rosbridge is implemented in python I believe.

Yes, the python version consumes too much CPU, so I would need to implement my own rosbridge in NodeJs (I think NodeJs is good for IO intensive tasks) for my frontend application. However, I'm not quite sure that compressing is the main cause of high CPU usage.

[Christian Fritz]

If the goal was to help with front-end development then I would stay away from rosbridge. The reason why I got involved with rosnodejs in first place was exactly that: to natively connect from node.js to ROS and only send to the front-end what I needed in in a format and modality that is more appropriate for that task, rather than building on ROS messages. The main issue I saw was actually duplication. In ROS it is assumes that network bandwidth is plentiful and virtually unlimited, which is a fine assumption when communicating within a host only. So sending the same message at 100Hz is not a problem. Talking across devices, however, that very much is a problem. So de-duplication, and only selectively sending data is the name of the game.

This is all part of the reason why I started Transitive Robotics, to make it easy to build front-end features for robots, even when they are not on the same network. Happy to chat more and happy to share notes if you like.

[Chi]

If the goal was to help with front-end development then I would stay away from rosbridge. The reason why I got involved with rosnodejs in first place was exactly that: to natively connect from node.js to ROS and only send to the front-end what I needed in in a format and modality that is more appropriate for that task, rather than building on ROS messages. The main issue I saw was actually duplication. In ROS it is assumes that network bandwidth is plentiful and virtually unlimited, which is a fine assumption when communicating within a host only. So sending the same message at 100Hz is not a problem. Talking across devices, however, that very much is a problem. So de-duplication, and only selectively sending data is the name of the game.

This is all part of the reason why I started Transitive Robotics, to make it easy to build front-end features for robots, even when they are not on the same network. Happy to chat more and happy to share notes if you like.

Thanks for the advice.