How to check the numeric array types in the message received from ROS about rosnodejs HOT 9 CLOSED

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?

from rosnodejs.

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

from rosnodejs.

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

from rosnodejs.

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);

{
  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: []
}

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

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

from rosnodejs.

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.

from rosnodejs.

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.

from rosnodejs.

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.

from rosnodejs.

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.

from rosnodejs.