BeamNG.tech new tools for roads generation and sensors placement, impovements on existing interfaces and sensors, new features and more documentation.

The BeamNG.tech v0.32 release introduces a range of new GUI-based tools to conveniently access some core BeamNG features without requiring the need for any coding. The Road architect tool generates road networks, which are spline-based.

Two new tools on sensors configuration are available now, one tool for sensors attached to vehicles and the other one for sensors attached to the infrastructure.

The v0.32 software release brings improvements to the ROS1 bridge and to ROS2 bridge. The Simulink interface, becomes easier to access and use, thanks to the co-simulation editor. From now on, BeamNG.tech is compatible with FMI standard, supporting FMI2 and FMI3.

Important to note that, BeamNG.tech v0.32 includes all updates from the BeamNG.drive 0.32 release and hotfixes; the interested user can access the detailed reports on BeamNG.drive v0.32 here.


And this is the changelog for BeamNG.tech v0.32:

New features

  • Road architect tool for road networks generation :
    • it supports cubic spline roads and line -> spiral -> arc -> spiral -> line roads;
    • it is broadly compatible with ASAM OpenDRIVE standard (See list of unsupported features in documentation.),
    • with .xodr file import and export option,
    • which can serve as the intermediate step to import/export from BeamNG.tech to other OpenDRIVE-compatible software;
    • it offers road profile templates and the user can design their own road profile too;
    • it allows for road tunnels design and editing
    • and supports terraforming;
    • it comes with pre-made content (prefab groups) to accelerate the user on roads design;
    • the user can create their own prefab group and save it;
    • and also link prefab groups together;
    • user-friendly tool, accessible from the World Editor;
    • documented with a detailed tutorial;
    • the tool is WIP.
  • The tech_ground map, a new map,
    • which contains a terrain and some terrain materials
    • and has the necessary assets to allow for experimentation.
  • ADAS sensors configuration editor, on vehicles :
    • it lets the user position and save configurations of multiple sensors across the range of loaded vehicles;
    • it allows edit the properties of each sensor;
    • Compatible with BeamNGpy, that is a sensors configuration file is possible to use in Python scenarios;
  • ADAS sensors configuration editor, on the infrastructure :
    • it allows to place Camera, RADAR, LiDAR and ultrasonic sensors on the map;
    • the sensors configuration can be saved and reloaded later;
    • compatible with Python API.
  • The Co-simulation tool
    • allows the user to design cosimulation protocols between BeamNG.tech and a third party (eg Simulink, FMI, Python, etc);
    • offers a comprehensive range of signals to choose from, available for each vehicle, so that one can use these to build a message-based protocol, through which tightly-coupled cosimulation can be executed with the 3rd party;
    • the GUI tool allows starting/stopping of the cosimulation directly from the main window.
  • FMI integration :
    • a new co-simulation option for vehicle coupling;
    • FMU files for FMI 2.0 CS and FMI 3.0 CS are included in the BeamNG.tech zip file, in the BeamNG-FMU repository and in the BeamNG-MATLAB-Simulink-integration repository;
    • source code in the BeamNG-FMU repository;
    • tested with Simulink R2023b onwards;
    • static list of inputs and outputs → to be improved in the future .
  • Troubleshooter wizard for BeamNG.tech software to guide the user how to resolve an issue or report it, or where to adress a request.

Changes / improvements

  • AI mode added on ROS1;
  • on ROS2 :
    • new API for the bridge,
    • sensor publishers for certain classical sensors i.e., electrics, damage, and state, and certain automation sensors i.e., ultrasonic, IMU, camera,
    • sensor publisher with visualization in rqt visualizer;
  • Deprecated the old IMU sensor (from now on only the advanced IMU is available);
  • The LiDAR has been updated to fix various reported bugs and now supports three modes of operation :
    • I. Full 360 Mode: This is similar to what was there before, but with the bug fixes. There is no ‘rotation’, although it pretends to mimic that. This is what the user would choose if they want fast-updating 360 coverage.
    • II. LFO Mode: Low-frequency rotation in the range of around 1Hz - 10Hz. Visually more intuitive as to how the LiDAR works (real LiDARs will rotate at around 50Hz - 100Hz). We cannot rotate and update at these speeds though - what happens if you try, is that certain sectors will be ‘hit’ more than others due to undersampling (limited by our graphics step), and this can get quite random due to the variable step size. For users who want the fast LiDAR, they can use mode I. If its that fast, one could barely see it rotate anyway, so its fine. This is probably the mode which is best for demonstrations. The horizontal aperture (angle) can be made wider or thinner, as one likes.
    • III. Static Mode: This is also a new mode, where the LiDAR is fixed and points in a direction given by the user. There is no rotation. The readings should thus always correspond to the same rays. The horizontal angle can be set between 1 degrees and 179 degrees in this mode, so can do (practically) a full hemisphere.

Bug fixes

  • On LiDAR, the horizontal angle was unusable. It is now useable and in fact meaningful, especially for modes II and III.
  • On LiDAR, the ‘dir’ and ‘up’ vectors did not behave correctly, preventing users from setting the local frame of reference of the sensor. This has now been resolved.

BeamNGpy-related changes

  • Added terrain/heightmap importer;
  • RADAR sensor now works without shared memory;
  • fixed find_objects_class when getting data from the simulator;
  • added postprocess_depth flag to the Camera sensor, which makes the distinction of the depth image clearer, but is computationally intensive (off by default);
  • added time as a field of the State sensor, which represents the current simulation time;
  • examples changed to use the Tech Ground level (tech_ground) instead of the Smallgrid (smallgrid) (We encourage the users to use the Tech Ground level as the default flat level in BeamNG.tech);
  • removed LidarVisualizer and the pyopengl dependency;
  • added new flag to automated sensors: is_dir_world_space
    • False by default; if True, then the dir argument of the sensors represents the world space direction instead of the vehicle space direction vector
  • fixed IdealRADAR with is_send_immediately=True ;
  • BeamNGpy.scenario.load does not resume the physics anymore
    • to pause the physics (BeamNGpy.control.pause()) and allow stepping (BeamNGpy.control.step()), it is preferred to call BeamNGpy.control.pause() before BeamNGpy.scenario.load() ;
  • fixed BeamNGpy.scenario.delete not deleting the prefab file;
  • BeamNGpy functions using the cling=True argument should behave more reasonably when finding the ground level
    • the cling=True argument still does not work for Scenario.add_vehicle ;
  • added documentation on the sensors output signals;
  • removed examples which used the deprecated old IMU sensor;
  • BeamNGpy changelog.