I would like to inquire specifically about the reliability of the data generated and sent via the OutGauge UDP Protocol. Is there any article or documentation that explains how this data is emulated or that demonstrates its reliability? Ensuring the accuracy of this data is important for my research.
outgauge.lua currently offers a limited set of data fields, which may not fully align with the rigorous reliability criteria you’re seeking. For instance, in cases where “speed” is used, are fallback methods like substituting airspeed when wheelspeed is unavailable acceptable within your reliability standards? Additionally, wheelspeed calculations involve complex estimations, such as using tire beam compression in real-time, which may affect the field’s reliability according to your standards.
To better support your research objectives, it would be invaluable to understand which specific fields or signals you prioritize for demonstrating reliability. Beyond speed, are there other fields you aim to assess for reliability? For example, does your project include indicators like the left-turn signal?
Having a clear list of fields and verification expectations will help us align better with your project goals and provide more precise support.
I am developing a digital twins system and would like to ask a few questions. For example, you have 2 registered vehicles whose fuel type is electric. How do they simulate battery consumption?
Would it be possible to implement my own battery consumption system through mod implementation?
Hello matheus,
thank you for your insights. The implementation of electrical powertrains is rather simplistic for now and focuses more on driveability than efficiency. Nevertheless, mechanical losses in the powertrain are considered by a constant and dynamic friction dependent on motor speed. The electrical losses are currently considered by an efficiency value. The battery is integrating the power demand and recuperated power from the electric motor to calculate the current battery SOC.
You can absolutely advance the current implementation of the electrical powertrain. Have a look at the \lua\vehicle\powertrain\electricMotor.lua. The parameters for the electric powertrain are defined in the jbeam files e.g. \vehicles\vivace\vivace_electric_motor.jbeam.
I hope this helps you to get started.
Hi matheus!
First, I would recommend using the outgage only for data, where high update rates are priority one. If you want to have more datachannels, you could try reading the vehicle stats logger, while it writes its log file.
We found it the best way to use the python API to feed our faster matlab vehicle model in realtime.
Also we developed a conversion efficiency based powertrain improvement and a more realistic regeneration through a different shifting logic. If you are interested, I put up a linklist to our assets in my forum profile.
In short I would say, that the current powertrain modeling in BeamNG hits the sweetspot of least complexity while beeing most generic. But it will be more efficient than any real car will be in any situation.
Thanks for sharing your insights—especially about using OutGauge and vehicle stats logging. These suggestions are very helpful for the community.
I also wanted to mention that the Co-simulation Editor in BeamNG could be an excellent solution for tightly-coupled simulations with Simulink. It supports integrating Simulink models using an S-function over the UDP protocol, which could help achieve better synchronization for real-time interactions between BeamNG and Simulink.