Feature request: Triton sensor

[Timple]

Is your feature request related to a problem? Please describe.
We currently use a Triton sensor in real-life: https://accerion.tech/solutions/triton/
This sensor recognizes learned floor-patches and gives an absolute pose upon recognition.

Describe the solution you'd like
Triton plugin for webots

Describe alternatives you've considered
Maybe implemented as a generic absolute position sensor. But it should only update on certain patches.

[omichel]

How would you model patches in Webots?

[Timple]

That's a good question. One could simply overlay some kind of 'floor' patch in the world file? A simple (2d?) object that's flat on the floor and detectable by the sensor.

[omichel]

That seems to be tricky... I would rather implement this kind of sensor using a supervisor process:

1. Setup a Robot with supervisor field set to TRUE and add an Emitter in its children.
2. Add a Receiver to your robot.
3. Make the supervisor send the position to the robot (via Emitter/Receiver) only if this position corresponds to a patch stored in a map inside the supervisor controller.

[Timple]

The downside of the above is that it is a lot of configuration per-robot right?
Not just adding a sensor with a map.

[omichel]

The downside of the above is that it is a lot of configuration per-robot right?

I wouldn't say a lot. Each robot has to be equipped with one Receiver sensor from which it will read its location. That seems reasonable, isn't it? The complexity will be in the supervisor only where a map of the patches has to be stored and the supervisor should send a specific message to each robot indicating its location. So the supervisor has to parse the world to list all the robots equipped with a Receiver which are supposed to receive a location message.

[ShuffleWire]

If I understand your issue correctly, could the following be a solution ? :
Use a GPS to get the position of the robot, and than on the controller side make a custom processing to output a data which look like the output of your sensor. this processing would indeed not be part of the real robot, but the data produced by this processing could be used by your real algorithm down the road.
For instance, the so called processing could be to read a black-white image representing the floor (black pixel where there is a patch, white where is none), and update the output data only when the input data match a black pixel. Otherwise, return whatever your sensor would return in that case..
It avoid the usage of a Supervisor and Emitter/Receiver.

[Timple]

I'm affraid the GPS doesn't have orientation data right?

[omichel]

I'm affraid the GPS doesn't have orientation data right?

No, it hasn't. This information is provided by the InertialUnit sensor. So, either you add a InertialUnit sensor in addition to the GPS or you go for the supervisor option to provide orientation data as well.

[Timple]

Regardless of the path we take. Would it make sense to have an absolute position sensor? So much like the GPS sensor but with orientation information?

[omichel]

Regardless of the path we take. Would it make sense to have an absolute position sensor? So much like the GPS sensor but with orientation information?

Does such a sensor exist in the real world? I believe what you are looking for is a combination of GPS and InertialUnit... Not sure if a real counterpart of this is available. We would like to avoid introducing sensors in Webots that do not exist in the real world. If you want to simulate these, a supervisor approach is probably better.

[ShuffleWire]

Considering that GPS and INS work well together to give the 6D information for location and rotation, I don't think that adding a new object will be very useful. Additionally, Webots sensors tends to match behaviour of real world sensors, and I don't know one which give this 6D info, without being an GPS coupled to an INS. However, I not aware of everything done in the sensor world :)

Edit: you just got ahead of me @omichel !

[Thomas-Feldmeier]

That's a good question. One could simply overlay some kind of 'floor' patch in the world file? A simple (2d?) object that's flat on the floor and detectable by the sensor.

This can be done. We need a very high resolution image, pixel size maybe 0.0001m? Still the image must be large enough for big rooms, say 100m. Image size would be too large: 100m / 0.0001m = 1000000 pixels in both x ANY y direction => 1 billion pixels. to solve this, you can

• use small high resolution images, repeat them in x and y direction over and over again
• use several half-transparent images of different size and scale

One image would repeat itself, different places would have same image. But the overlay of images of different scale repeat much less often. Try random floating point numbers for both x and y size of the images.

ImageTexture {
MFString url [ ]
SFBool repeatS TRUE # {TRUE, FALSE}
SFBool repeatT TRUE # {TRUE, FALSE}
SFInt32 filtering 4 # [0, 5]
}

repeatS and repeatT are both default set to true, so you don't have to change them yourself. filtering 4 is good too, it makes the pixels blurry and not rectangular.

TextureTransform {
SFVec2f center 0 0 # any vector
SFFloat rotation 0 # (-inf, inf)
SFVec2f scale 1 1 # any vector
SFVec2f translation 0 0 # any vector
}

scale must be changed to some useful values.

note that images must not be at exactly same height level, or "z-buffer fighting" would appear. so place the half-transparent images at different height levels, e.g. at +0.001m height. e.g.

floor at height 0.000
image 1 at height 0.001
image 2 at height 0.002
image 3 at height 0.003

if you don't want to let your blurry image be visible to users, you could place the half-transparent images 1m below the floor, and move the coordinate of the camera device of the robot 1m below too (the physical part of the camera can still be on the right position). Maybe you need to add some source of light, i don't know.

If this solution is too complicated, you can cheat by using a supervisor like suggested before.
Supervisor can directly read x/y coordinate and heading of robot, no need for devices.
node could be getSelf() or getFromDef("...") for other robots

struct Pose2D{
    double x, y, heading;
};

// the webots node must have coordinate system x=front, y=left, z=up.
// webots WorldInfo.coordinateSystem must be ENU. (todo: handle all coordinate systems correct)
Pose2D getNodePose(webots::Node *node) {
  const double *position = node->getPosition();
  const double *orientation = node->getOrientation();
// NUE:
//  Pose2D pose = { position[0], -position[2], atan2(-orientation[6], orientation[0]) };
// ENU:
  Pose2D pose = { position[0], position[1], atan2(orientation[3], orientation[0]) };
  return pose;
}