ENU/FLU Conversion Plan #3073

lukicdarkoo · 2021-05-17T13:25:33Z

This PR includes ENU/FLU conversion changes.

Plan

1. Fix geometries orientation (#3510)

2. Fix sensor orientation

Some sensors don't respect the ENU/FLU convention, so we have to fix it first. Otherwise, the conversion has to be done twice (this will break MANY things).

3. Improve the conversion script

4. Convert device and object PROTOs

All PROTOs are converted and therefore commented out.

5. Convert robots

6. Convert worlds

8. Convert test worlds and test controllers

8. Merge to develop

merge to the develop branch
invite users to test nightly builds (Discord, maybe LinkedIn, Twitter, and ROS Discourse)

7. Fix tools and other simulations

Statistics

Number of NUE worlds: 487/567

/projects: 269/287
/tests: 217/266

A number of PROTO files: 972

BenjaminDeleze · 2021-07-20T12:08:16Z

With this conversion, we are going to break the backward compatibility.
For example, the pen will no longer write along the y axis but along the z axis. This is not a very big issue as the pen is not a very used node. However, we will also modify cameras and other sensors.

It will not break the compatibility with the webots worlds as we are going to convert them, but it will break the user's worlds.
I do not think this is something we want to happen.

Here is some reflexions we had with @ad-daniel and @mael25

Sensors
An idea would be to get the information in the WorldInfo about the coordinateSystem (ENU or NUE) and then adapt the behavior according to that. But is not perfect:

Old NUE world with a pen: it will work
New ENU world with a pen: it will work.
New NUE world with a pen: it will work but it is not a good idea, because it will use the legacy version and we should not support it forever.
Old ENU world with a pen: it will not work as we will use the new version of the pen even so the world was build to support the old one.

Another idea could be to check the webots version in the header of the .wbt file to determine if we should use the old or the new version of sensors.
Problem: the version is overridden if the world is saved again.

Protos
We have the same problems with webots protos used in user's world
I think that the behavior that we want for protos (and for sensors as well) is the following:

A proto is in an old world (<= R2021b): it should work as before.
A proto is in a new world (> R2021b): it should follow FLU orientation
A proto is inserted in a new world: it should follow FLU orientation such that, if the user still want to create a NUE world, he will have to rotate the proto, but we will be able to remove support for old proto orientation after some time without breaking his new world.
A proto is inserted in an old world: I am not sure. I would say that it would be better to proceed as in 1, stay consistent with the world.

Some possible hints could be to:

Maintain two version of each protos
Have some JS in all protos to define two behaviors.
Have only one proto version and add a transform as a parent of the Proto to rotate it if needed.

We do not have an idea of a working solution for now and we think that it is better not to begin the conversion before having a solution about these problem, otherwise, we risk to have to start all over again.

lukicdarkoo · 2021-07-20T12:27:08Z

An idea would be to get the information in the WorldInfo about the coordinateSystem (ENU or NUE) and then adapt the behavior according to that.

Note that the world (ENU/NUE...) and body (FLU/RUB...) are independent (see https://www.ros.org/reps/rep-0103.html#axis-orientation). Most users will use ENU and FLU together, but that is not a general rule.

Another idea could be to check the webots version in the header of the .wbt file to determine if we should use the old or the new version of sensors.
Problem: the version is overridden if the world is saved again.

Yes, I have just implemented it here and I have the same problem.

What about adding a field to the WorldInfo called deviceCoordinateSystem (or deviceAxisOrientation) that can be either FLU or legacy? That way we would be more explicit.

BenjaminDeleze · 2021-07-20T12:35:00Z

A problem would also arise if a user has defined his own proto that uses some webots protos (such as Sick S300 for example)
or some webots sensors. We need to serve it the old or the new version of this protos/sensors according to when was created the proto.

BenjaminDeleze · 2021-07-20T12:41:10Z

Note that the world (ENU/NUE...) and body (FLU/RUB...) are independent (see https://www.ros.org/reps/rep-0103.html#axis-orientation). Most users will use ENU and FLU together, but that is not a general rule.

Yes :/

What about adding a field to the WorldInfo called deviceCoordinateSystem (or deviceAxisOrientation) that can be either FLU or legacy? That way we would be more explicit.

Could be an idea. I do not really like the idea to add a new field, but I do not see a better solution. And if there is no deviceCoordinateSystem tag, it would be legacy by default.

BenjaminDeleze · 2021-07-20T12:51:36Z

Problem: the version is overridden if the world is saved again.

Would it be a solution to make the version in the .wbt persistent?

lukicdarkoo · 2021-07-20T12:58:24Z

Problem: the version is overridden if the world is saved again.

Would it be a solution to make the version in the .wbt persistent?

I am not sure whether it is possible. I guess in 99% of cases it will work fine, but I am afraid there will be some uncovered edge cases.

The PROTO issue you mentioned is a good point. What happens if the user adds an R2021b PROTO in an R2021c world? That will be a common case and non of the suggestions will work :/

BenjaminDeleze · 2021-07-20T13:02:57Z

I am not sure whether it is possible. I guess in 99% of cases it will work fine, but I am afraid there will be some uncovered edge cases

One thing would be that we will have a warning everytime we open an old world. Otherwise I do not see an issue but I share your concerns about uncovered edge

BenjaminDeleze · 2021-07-20T13:08:30Z

What happens if the user adds an R2021b PROTO in an R2021c world? That will be a common case and non of the suggestions will work :/

That is a tricky point indeed! if the user want to insert his R2021b proto inside a R2021c webots world, the world will be fine but not the proto. And if he changed the world to legacy mode, the proto will be fine, but not the world

lukicdarkoo · 2021-07-20T14:22:03Z

We can implement a coordinateSystem field at a device level that can be legacy or FLU. If the field is not defined then:

if <=R2021b the value would be legacy and
if >R2021b the value would be FLU.

Once the world file is saved in R2021c+ Webots would append the coordinateSystem property to each device (the value would be legacy).

That way we ease the transition and users can save world files.

BenjaminDeleze · 2021-07-20T14:35:06Z

We can implement a coordinateSystem field at a device level that can be legacy or FLU. If the field is not defined then

Does it mean that it would be possible to have both legacy and FLU devices inside the same proto?

I think we should agree on a kind of tag to put as comment where we defined different behavior in the sensors, so it will ease the cleanup when we drop the legacy version.

BenjaminDeleze · 2021-07-20T15:00:28Z

Also how do we handle the docs?
we modify it such that it supports only FLU or do we need to keep the specificity of each version (always for the pen: along which axis we draw)

lukicdarkoo · 2021-07-20T15:03:10Z

Does it mean that it would be possible to have both legacy and FLU devices inside the same proto?

Yes, we could mix them. Eventually, we can deprecate the coordinateSystem field. We don't need any special tag.

we modify it such that it supports only FLU

I think it is a way to go as we want to discourage people from using the legacy axis orientation.

BenjaminDeleze · 2021-07-20T15:06:30Z

We don't need any special tag.

I meant in the .cpp files of Webots such that once we want to remove the legacy behavior it is easy to find every lines in the code where there is such a thing to remove

I think it is a way to go as we want to discourage people from using the legacy axis orientation.

I agree

BenjaminDeleze · 2021-07-21T06:24:32Z

Concerning the test suite, if we support sensors for both legacy and FLU, I think we will need to have two test suites in order to be sure that we do not break legacy or FLU :/

stefaniapedrazzi · 2021-07-21T07:34:31Z

The main objectives are:

new worlds should use the new coordinate system (worlds, PROTOs, sensors, etc.)
old worlds should still run correctly to guarantee the backward compatibility
we should strongly encourage users to convert their worlds to the new coordinate system (ideally Webots should be able to convert them on save) to get rid of old code as soon as possible

Would it be a solution to make the version in the .wbt persistent?

This is bad and we should avoid it because then old worlds will never be updated.
Ideally if a world is modified and saved it should be converted internally and automatically so that it uses the latest device coordinate system.

We can implement a coordinateSystem field at a device level that can be legacy or FLU.

I would try to avoid adding a new field specifying the coordinate system for device (legacy or FLU) and keep it as last solution if we should not really be able to handle it properly internally in Webots.
Supporting different coordinate system is more complicated, users worlds will never be updated and we will never get rid of the old ones.

Instead I think we should focus on implementing some functionality inside Webots that automatically converts the old devices (based on Webots version) at load into the new ones, so that when saving the worlds they will already follow the new standard.
I didn't check the specific issues, but for example this could be achieved by adding additional Transform nodes in the children field or maybe there are even better solutions.
Then on save we will print / show a message warning users of the changes.

Additionally, we should provide a script to upgrade PROTO models to R2021c and the new coordinate system.
PROTO files are not saved manually and if users decide to just change the version without updating the PROTO to the new standard it's a wrong manipulation that we should not support.

Concerning the test suite, if we support sensors for both legacy and FLU, I think we will need to have two test suites in order to be sure that we do not break legacy or FLU :/

This won't be necessary if Webots can convert internally the old device coordinate system into the new ones.
We will just need a couple of test to check that the conversion works correctly.

lukicdarkoo · 2021-07-21T09:15:11Z

I like the idea of converting worlds automatically. It is probably the most efficient way to force users to use the new conventions. However, there are a few challenges with that approach.

Instead I think we should focus on implementing some functionality inside Webots that automatically converts the old devices (based on Webots version) at load into the new ones, so that when saving the worlds they will already follow the new standard.
I didn't check the specific issues, but for example this could be achieved by adding additional Transform nodes in the children field or maybe there are even better solutions.
Then on save we will print / show a message warning users of the changes

Let's consider a use-case in which a user uses a point cloud from a LiDAR. It's likely the user uses getPosition/getOrientation/getPose of the LiDAR node to transform the point cloud to another coordinate frame. Adding an additional transform will break the behavior. Not terrible, but we should be aware we cannot provide full backward compatibility.

Additionally, we should provide a script to upgrade PROTO models to R2021c and the new coordinate system.
PROTO files are not saved manually and if users decide to just change the version without updating the PROTO to the new standard it's a wrong manipulation that we should not support.

We cannot make such a script, at least not if there is JavaScript/Lua inside.

I would try to avoid adding a new field specifying the coordinate system for device (legacy or FLU) and keep it as last solution if we should not really be able to handle it properly internally in Webots.

The field can be hidden.

BenjaminDeleze · 2021-07-21T09:23:29Z

If we convert automatically the world of a user when it is open, we should put an additional warning when he tries to save as it will heavily modify his .wbt and make it incompatible with previous version of webots.

Another question concerns cylinders (also capsules and cones by extension). Cylinders are currently built along the Y axis. If we follow the ROS convention, and it is what we are trying to do with this PR, cylinders should be oriented along the Z-axis (http://wiki.ros.org/urdf/XML/link at <cylinder>) , we should change the default orientation of the cylinders/cone/capsule in webots as well.

stefaniapedrazzi · 2021-07-21T09:31:45Z

The field can be hidden.

Yes. But users will continue to use the old coordinate system and won't update their worlds.
Automatically converting is for sure more complicated to implement than a new field.
But it will be easier for users to update their worlds and this should have a high priority too.

If for some devices it would be useful to be able to specify the coordinate system (at least to guarantee the backward compatibility for some time), for others I really don't see the advantage, for example for the Pen and Camera.

Where it is not strictly needed, I would automatically convert them.
For devices that will cause more problems we can find a different method to handle them-

We cannot make such a script, at least not if there is JavaScript/Lua inside.

We should at least provide a script for simple PROTO structures not using JavaScript/Lua.

If we convert automatically the world of a user when it is open, we should put an additional warning when he tries to save as it will heavily modify his .wbt and make it incompatible with previous version of webots.

Yes, of course we should print/ show a warning.
But it is normal that a file saved with a newer version may not work with older version.
We try to guarantee backward compatibility but it is impossible to guarantee forward compatibility.

Another question concerns cylinders (also capsules and cones by extension). Cylinders are currently built along the Y axis. If we follow the ROS convention, and it is what we are trying to do with this PR, cylinders should be oriented along the Z-axis (http://wiki.ros.org/urdf/XML/link at ) , we should change the default orientation of the cylinders/cone/capsule in webots as well.

Yes, we should probably update the geometries too.

mael25 · 2021-07-28T09:29:02Z

I have checked the conventions for the sensors that have a specific axis measurements.

LightSensor: is already correct, light measured on x-axis according to sensor_msgs/Illuminance ROS message.

The TouchSensor with type=force seems not to have an equivalent. Indeed, the force/torque controller in ROS, the Contact Sensor plugin and the Force/Torque Sensor in Gazebo all measure in 3D.

As for the Connector, no equivalent has been found.

I would propose to use the x-axis for both of them, as the Shape of these devices in the Guided Tour suggests that the measurement is done on the forwards axis, which should be x (instead of z currently) if we use FLU:

Connector

TouchSensor, type=force

mael25 · 2021-07-29T07:57:30Z

For infra-red Emitter and Receiver, I would suggest to switch the emission/reception cone axis from z to x, as it makes sense to have them oriented like a DistanceSensor. The other types of Emitter and Receiver are omnidirectional.

lukicdarkoo · 2021-08-23T14:06:31Z

I added a list of all PROTOs. I propose the following procedure:

Pick a batch of PROTOs to convert (e.g. 10, 20, 30... PROTOs).
Create a PR and copy the sublist to your PR (to have a TODO list).
Check them in this PR so others know which PROTOs are WIP (or finished).

…enu-plan Merge `develop` into `feature-enu-plan`

* fix animation initialization * merge webots-streaming and webots-animation * correct fullscreen and buttons * docs and sync * Update docs/guide/web-scene.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-scene.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-scene.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * rename x3d and json attributes * Update docs/guide/web-scene.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-simulation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-simulation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-simulation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-animation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * hasActiveAnimation to hasAnimation Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com>

* Remove additional rendering call after world is destroyed * reduce max number of lights * typo * add automatic close * update limitation example * typo * Update docs/guide/web-animation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-simulation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/reference/light.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com>

* remove skybox rendering in orthographic mode * disable shadow

* first commit * Begin of humanoid_marathon * convert sumo world * Fix pillar * convert highways * clean + convert boomer * convert highway * convert cities + fix forest * fix crossroad * fix forest * fix forest + convert village * convert villages winter+realistic * convert village center + fix stripBuilding * fix forests + add script to convert them * fix fastFoodRestaurant * convert CH_Vens * convert ch_morges * convert humanoid marathon * fix robotis proto translation * fix humanoid marathon * clean + convert forst highway * swap y/z + protos fixes * fix forest * clean+ sumo update * convert sumo exporter * convert vehicle sensors * fix ibeoLux proto * pep8 compliance * fix highway_overtake * convert highway overtake * convert city net * convert city night * convert city traffic net * convert village net * convert village center net * convert village realistic net * fix sumo_interface_example traffic lights * convert radar target tracker controller * convert highway controller * highway * restore radar.c * fix robotbenchmark/highway_driving * fix humanoid_marathon.wbt * correct CH_Morges * fix buildings in CH_Morges * fix highway_overtake * fix building and route village_realistic * fix village_center route * convert webots vehicle * compliance * delete edges and nodes. * replace trip by flow for highway * Apply suggestions from code review Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * remove useless crossroad on highway.wbt * remove crossroads shape * correct roll and pitch * fix truck and tank simple * fixes from daniel reviews * add edge and node for sumo example * small fix ch_morges * fixes village_center * fix strange behaviour vehicle * fix turn and changeline SUMO * fix darwin * fix sumo center of rotation * pep8 * Update sumo (#3876) * update makefile * adapt sumo webots for 1.10.0 * add windows md5 * add linux md5 * add mac md5 * update docs * update docs * add SUMO dependencies * update tarball installation * add SUMO dependencies to linux compilation * update Makefile for ubuntu18.04 * fix change lane function * fix default translation * Update docs/automobile/sumo-exporter.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update projects/vehicles/protos/generic/TruckTrailerSimple.proto Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update projects/objects/road/protos/RoadPillars.proto Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * fix car_node + comment Co-authored-by: joachimhgg <joachim.honegger@gmail.com> Co-authored-by: Benjamin Deleze <benjamin.deleze@cyberbotics.com> Co-authored-by: Benjamin Délèze <benjamin.deleze@cyberbotics.ch> Co-authored-by: joachimhgg <48200998+joachimhgg@users.noreply.github.com> Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com>

* Converted web_component_studio to ENU * Aibo * Altino * Atlas * bb8 * bioloid * blimp * All robots * IRB * irb * irb * atlas * better viewpoint for altino and atlas * bb8 * khr2 * khr3 * ned * Fixed view for BB8, KHR2, KHR3 and NED * Fixed viewpoint for some robots

* first commit * Begin of humanoid_marathon * convert sumo world * Fix pillar * convert highways * clean + convert boomer * convert highway * convert cities + fix forest * fix crossroad * fix forest * fix forest + convert village * convert villages winter+realistic * convert village center + fix stripBuilding * fix forests + add script to convert them * fix fastFoodRestaurant * convert CH_Vens * convert ch_morges * convert humanoid marathon * fix robotis proto translation * fix humanoid marathon * clean + convert forst highway * swap y/z + protos fixes * fix forest * osm_importer * fix crosswalk and wall * clean+ sumo update * fix bug * correct elevation * convert sumo exporter * convert vehicle sensors * fix ibeoLux proto * pep8 compliance * fix highway_overtake * convert highway overtake * convert city net * convert city night * convert city traffic net * convert village net * convert village center net * convert village realistic net * fix sumo_interface_example traffic lights * convert radar target tracker controller * convert highway controller * highway * restore radar.c * fix robotbenchmark/highway_driving * fix humanoid_marathon.wbt * correct CH_Morges * fix buildings in CH_Morges * fix highway_overtake * fix building and route village_realistic * fix village_center route * convert webots vehicle * compliance * delete edges and nodes. * replace trip by flow for highway * Apply suggestions from code review Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * remove useless crossroad on highway.wbt * remove crossroads shape * correct roll and pitch * fix truck and tank simple * fixes from daniel reviews * add edge and node for sumo example * small fix ch_morges * fixes village_center * fix strange behaviour vehicle * fix turn and changeline SUMO * fix darwin * fix sumo center of rotation * pep8 * Update sumo (#3876) * update makefile * adapt sumo webots for 1.10.0 * add windows md5 * add linux md5 * add mac md5 * update docs * update docs * add SUMO dependencies * update tarball installation * add SUMO dependencies to linux compilation * update Makefile for ubuntu18.04 * fix change lane function * fix default translation * Update docs/automobile/sumo-exporter.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update projects/vehicles/protos/generic/TruckTrailerSimple.proto Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update projects/objects/road/protos/RoadPillars.proto Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * fix car_node + comment * pep8 Co-authored-by: ad-daniel <daniel.dias@epfl.ch> Co-authored-by: joachimhgg <joachim.honegger@gmail.com> Co-authored-by: Benjamin Délèze <benjamin.deleze@cyberbotics.ch> Co-authored-by: joachimhgg <48200998+joachimhgg@users.noreply.github.com> Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com>

* loadModel, closeModel * update docs for scene * update for scene * correct closing * model to scene * typo * Update docs/guide/web-animation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-scene.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> * Update docs/guide/web-simulation.md Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com> Co-authored-by: Olivier Michel <Olivier.Michel@cyberbotics.com>

* Update viewer.js * Update webots.js

* Disable css when not needed * cascading

…ta… (#3950) * Fix crash when changing a world after the backward compability adaptation * better * Update WbNodeUtilities.cpp

* Fix extrusion * fix CrashBarrier bo * orientation * switch Y and Z to meet the VRML2 norm * fix extrusion protos * update script * pep8 * Update Morges wrong walls * pep8 * Update projects/objects/geometries/protos/Extrusion.proto Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> * Update projects/objects/geometries/protos/Extrusion.proto Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> * Update projects/objects/geometries/protos/Extrusion.proto Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> * Update projects/objects/geometries/protos/Extrusion.proto Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> * Update scripts/converter/convert_nue_to_enu_rub.py Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> * Update projects/objects/geometries/protos/Extrusion.proto Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com> Co-authored-by: joachimhgg <joachim.honegger@gmail.com> Co-authored-by: ad-daniel <44834743+ad-daniel@users.noreply.github.com>

…enu-plan Merge develop into `feature-enu-plan`

omichel

🥳

lukicdarkoo added the bug Something isn't working label May 17, 2021

lukicdarkoo added this to the R2021b milestone May 17, 2021

lukicdarkoo self-assigned this May 17, 2021

lukicdarkoo added feature Implementation of a major feature cleanup Any design, code, file or folder cleanup and removed bug Something isn't working labels May 17, 2021

lukicdarkoo modified the milestones: R2021b, R2021c May 28, 2021

stefaniapedrazzi mentioned this pull request Aug 23, 2021

Release Skin node #3566

Merged

11 tasks

ad-daniel and others added 22 commits November 19, 2021 09:26

Replace image

4a1f5ee

Merge pull request #3937 from cyberbotics/merge-develop-into-feature-…

f83330e

…enu-plan Merge `develop` into `feature-enu-plan`

Fix typo webotsview (#3940)

6db723b

FLU: fix nao (#3949)

02a368c

FLU: fix orthographic mode (#3948)

cd6fc78

* remove skybox rendering in orthographic mode * disable shadow

default to FALSE for useNetconvert (#3954)

e227d7e

fix test (#3961)

c74153a

Fix webots.js texture path (#3965)

daab083

* Update viewer.js * Update webots.js

Disable css when not needed (#3966)

f583aa9

* Disable css when not needed * cascading

Fix crash when changing a world after the backward compatibility adap…

5b44474

…ta… (#3950) * Fix crash when changing a world after the backward compability adaptation * better * Update WbNodeUtilities.cpp

Merge branch 'develop' into merge-develop-into-feature-enu-plan

d16474a

Merge branch 'develop' into merge-develop-into-feature-enu-plan

ff08993

Fix sources

b315030

Re-do merge

dc93d7b

Merge pull request #3974 from cyberbotics/merge-develop-into-feature-…

258fd87

…enu-plan Merge develop into `feature-enu-plan`

ad-daniel added test ros Start the ros test test sources Start the sources test on all platforms labels Dec 3, 2021

ad-daniel marked this pull request as ready for review December 3, 2021 16:01

ad-daniel requested review from a team and omichel December 3, 2021 16:01

omichel approved these changes Dec 3, 2021

View reviewed changes

ad-daniel merged commit bf4a17b into develop Dec 3, 2021

BenjaminDeleze deleted the feature-enu-plan branch July 7, 2022 06:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ENU/FLU Conversion Plan #3073

ENU/FLU Conversion Plan #3073

lukicdarkoo commented May 17, 2021 •

edited by joachimhgg

Loading

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

lukicdarkoo commented Jul 20, 2021 •

edited

Loading

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

BenjaminDeleze commented Jul 20, 2021

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 21, 2021

stefaniapedrazzi commented Jul 21, 2021 •

edited

Loading

lukicdarkoo commented Jul 21, 2021

BenjaminDeleze commented Jul 21, 2021

stefaniapedrazzi commented Jul 21, 2021 •

edited

Loading

mael25 commented Jul 28, 2021 •

edited

Loading

mael25 commented Jul 29, 2021 •

edited

Loading

lukicdarkoo commented Aug 23, 2021

omichel left a comment

ENU/FLU Conversion Plan #3073

ENU/FLU Conversion Plan #3073

Conversation

lukicdarkoo commented May 17, 2021 • edited by joachimhgg Loading

Plan

1. Fix geometries orientation (#3510)

2. Fix sensor orientation

3. Improve the conversion script

4. Convert device and object PROTOs

5. Convert robots

6. Convert worlds

8. Convert test worlds and test controllers

8. Merge to develop

7. Fix tools and other simulations

Statistics

BenjaminDeleze commented Jul 20, 2021 • edited Loading

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021 • edited Loading

lukicdarkoo commented Jul 20, 2021 • edited Loading

BenjaminDeleze commented Jul 20, 2021 • edited Loading

BenjaminDeleze commented Jul 20, 2021

lukicdarkoo commented Jul 20, 2021

BenjaminDeleze commented Jul 20, 2021

BenjaminDeleze commented Jul 21, 2021

stefaniapedrazzi commented Jul 21, 2021 • edited Loading

lukicdarkoo commented Jul 21, 2021

BenjaminDeleze commented Jul 21, 2021

stefaniapedrazzi commented Jul 21, 2021 • edited Loading

mael25 commented Jul 28, 2021 • edited Loading

mael25 commented Jul 29, 2021 • edited Loading

lukicdarkoo commented Aug 23, 2021

omichel left a comment

Choose a reason for hiding this comment

lukicdarkoo commented May 17, 2021 •

edited by joachimhgg

Loading

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

lukicdarkoo commented Jul 20, 2021 •

edited

Loading

BenjaminDeleze commented Jul 20, 2021 •

edited

Loading

stefaniapedrazzi commented Jul 21, 2021 •

edited

Loading

stefaniapedrazzi commented Jul 21, 2021 •

edited

Loading

mael25 commented Jul 28, 2021 •

edited

Loading

mael25 commented Jul 29, 2021 •

edited

Loading