modelica / vehicleinterfaces Goto Github PK
View Code? Open in Web Editor NEWFree (standard conforming) library for interface definitions and architectures for vehicle system modeling
License: Other
Free (standard conforming) library for interface definitions and architectures for vehicle system modeling
License: Other
Models contained inside Roads.Internal suggest that something is not working properly.
Any Check_____ function report the following error:
[1] 11:08:04 Translation Warning
[VehicleInterfaces.Roads: 479:7-479:57]: No corresponding 'inner' declaration found for component .VehicleInterfaces.Roads.Interfaces.Base road.roadShape.road declared as 'outer '.
The existing 'inner' components are:
.Modelica.Mechanics.MultiBody.World$world world; defined in scope: VehicleInterfaces.Roads.Internal.CheckContactCalculation. Referenced by 'outer' components: {road.world}
Check if you have not misspelled the 'outer' component name.
Please declare an 'inner' component with the same name in the top scope.
Continuing flattening by only considering the 'outer' component declaration.
[2] 11:08:04 Translation Error
[VehicleInterfaces.Roads: 173:5-231:13]: Illegal to instantiate partial class Base.
[3] 11:08:04 Translation Error
Error occurred while flattening model VehicleInterfaces.Roads.Internal.CheckContactCalculation
It seems that those components (such as DummyTyre) that require an inner declaration of road are not connecting to the inner declaration that is actually found in Check______ models.
But here is the thing: I suppose that probably the error is in Internal.VisualizeSimpleRoads @480 at the line outer VehicleInterfaces.Roads.Interfaces.Base road;
.
Commenting it, everything works fine.
I didn't make a Pull Request, because I'm not sure of the solution.
Based on the comment of christiankral in Modelica Standard Library issue 340, the electric drive connector motorFlange
in VehicleInterfaces.Transmissions.Interfaces.BaseTwoInputTransmission
should be better renamed to machineFlange or electricDriveFlange.
The usingMultiBodyXXX
parameters are always used in combination in an OR statement with their close friends includeXXXBearing
.
Because of this, if the developer sets includeXXXBearing
(that is protected) to true
, automatically the user choice on usingMultiBodyXXX
will make no difference: because of the OR statement the logical results will always be true
.
Because of this, leaving usingMultiBodyXXX
exposed to the user might mislead him to think that he can still disable the Bearings by setting usingMultiBodyXXX=false
while he actually cannot.
Wouldn't be better to hide usingMultiBodyXXX
using annotation(Dialog(enable=not includeXXXBearing))
?
The examples collected in Roads.Internal
(CheckContactCalculation, etc.) shall be moved into a particular package Roads.Examples
. As a consequence, model Roads.Internal.DummyTyre
has to be moved into Roads.Examples.Utilities
.
I'm a new user of Modelica and the VehicleInterfaces package.
I'm using OpenModelica v1.18.0 (64bit) and VehicleInterfaces v2.0.0 on Windows 10.
When trying to simulate the VehicleInterfaces\Examples\SeriesHybrid.mo model, there is an error related to the "r/min" displayUnit (line 10).
I edited the file manually and changed this to "1/min" and it now works for me.
I've no idea whether this is a typo or whether it's a version incompatibility, but hopefully it'll help someone else even if the latter.
The VehicleInterfaces.Roads.Interfaces.Base is used as the base for many roads. These roads add in many other parameters and replaceable functions so it would be good to group the road functions in Base into a Tab to tidy up the layout of these functions. The description strings could also be improved and I think adding choicesAllMatching makes modifying these replaceable functions easier.
So I would like to propose that the road functions in Base be replaced with the following code.
replaceable function position = VehicleInterfaces.Roads.Interfaces.positionBase
"Function to get position at a road position" annotation (
choicesAllMatching=true,
Dialog(tab="Functions"),
Documentation(info="<html>
<p>
The road position function returns the world location of the road location (s,w).
</p>
</html>"));
replaceable function trackOffset = VehicleInterfaces.Roads.Interfaces.trackOffsetBase
"Function to get position at a driving line position" annotation (
choicesAllMatching=true,
Dialog(tab="Functions"),
Documentation(info="<html>
<p>
The track offset function returns the location of the driving line location (s,w). This location can either be relative to the road centre line or in world coordinates.
</p>
</html>"));
replaceable function normal = VehicleInterfaces.Roads.Interfaces.normalBase
"Function to get road normal at a road position" annotation (
choicesAllMatching=true,
Dialog(tab="Functions"),
Documentation(info="<html>
<p>
The normal function returns the normal of the road surface at (s,w).
</p>
</html>"));
replaceable function headingDirection = VehicleInterfaces.Roads.Interfaces.headingDirectionBase
"Function to get heading direction at a road position" annotation (
choicesAllMatching=true,
Dialog(tab="Functions"),
Documentation(info="<html>
<p>
The heading direction function returns the direction in which the road is going at (s,w).
</p>
</html>"));
replaceable function frictionCoefficient = VehicleInterfaces.Roads.Interfaces.frictionCoefficientBase
"Function to get friction coefficient at road position" annotation (
choicesAllMatching=true,
Dialog(tab="Functions"),
Documentation(info="<html>
<p>
The frictionCoefficient function returns the friction coefficient of the road at (s,w).
</p>
</html>"));
I would like to understand why MultiBodyEnd blocks are needed (for example, in the chassis of the FrontWheelDriveManualVehicle) since they just add zero force and torque... Were they intended to allow simulation of isolated components of models?
I am new to OpenModelica and was looking for OpenModelica car models and found this site.
I would like to simulate getting the following data, is it possible?
・Speed of a car
・Acceleration performance of a car
・Deceleration performance of a car
・Fuel consumption of a car,etc.
I could not find an appropriate place to ask this question, so I asked it here.
If there is another appropriate place, please let me know and I will move it.
I have a doubt that, if you confirm, can be an issue.
Look at Roads.Interfaces.Base. There are 5 variables (position, trackOffset, etc...).
These 5 variables are of type replaceable function
thus can be replaced by any class that extends function
.
The question is: is this the intended behaviour? Shouldn't these variable be constrained to be of type Roads.Interfaces.positionBase
instead of the more general function
?
Shouldn't they be declared as
replaceable VehicleInterfaces.Roads.Interfaces.positionBase position;
for example?
Similar to PR #46, protected parameter includeAccessoriesBearing
in Accessories.Interfaces.Base
shall be renamed to includeEngineBearing
.
The tool-specific annotation __Dymola_choicesFromPackage
is used in the classes VehicleInterfaces.DriverEnvironments.DriveByWireAutomatic
and VehicleInterfaces.Drivers.MinimalDriver
As discussed in #17, the integer variable currentGear should be deleted from VehicleInterfaces.Interfaces.TransmissionControlBus
in the next major version. It is defined in VehicleInterfaces.Transmissions.Interfaces.StandardControlBus
as well which is actually the right place according to the library standards.
VI is currently under the Modelica License 1.1 with the MA as copyright holder. The MSL switched its license since 3.2.3 to BSD 3-Clause which is almost identical with the not so well known and outdated Modelica License 1.1.
I think it would be a clean solution to have the next major version be published under the same BSD 3-Clause license as the MSL.
In the UsersGuide.DriverInteractionBus's naming convention table the measurement units for engineSpeed and vehicleSpeed have ambiguous descriptions.
engineSpeed | rad/s | Engine speed in rpm
vehicleSpeed | m/s | Vehicle speed in km/h
in both Drivers.Internal.StandardDriverInterfaceFor<Manual|Automatic>Transmission and Engines.MinimalEngine the engine angular speed is considered as rad/s.
Anyway, I think it's worth to make things to match. And probably, to the user interface rpm is actually the preferred choice.
Hi, in vehicle interfaces there is a model with path: VehicleInterfaces.Accessories.MinimalAccessories
The parameter
parameter Modelica.SIunits.Torque accessoriesLoad=2
"Total effective torque load due to the accessories (constant)
implies that you should provide a positive torque for the load. Within the model the torque sign should be made negative when used in the torque actuator otherwise this model actually converts a torque load to a torque gain.
It is my suggestion that the torque actuator should reference -accessoriesLoad rather than accessoriesLoad.
Many thanks,
Alex
The current approach with replaceable bus instances in models counteract the idea of expandable connectors.
Currently, signal bus connectors from VehicleInterfaces.<assembly>.Interfaces
are always instantiated as replaceable in particular assembly models. This was introduced years ago. But actually this contradicts the idea of expandable connectors. Moreover, it makes problems in more complex vehicle architectures because then all bus connectors of an assembly should be of the same definition. This means to replace a plenty of connectors for a particular architecture.
The proper solution is to use "empty" bus connectors from VehicleInterfaces.Interfaces
across the library as was the case in the early versions.
Following the decission done in modelica/ModelicaStandardLibrary#2975, packages in VI shall be splitted into single files for each model.
The Modelica.Mechanics.MultiBody.Interfaces.FlangeWithBearingAdaptor
should be used if possible to connect Modelica.Mechanics.MultiBody.Interfaces.FlangeWithBearing
with 1D flange or multi-body frames.
Following models are possible candidates:
Spell Greek letter for m (µ) correctly: mu instead of mue. See similar issue modelica/ModelicaStandardLibrary#194.
From documentation check:
Error: The class Modelica.Mechanics.Translational.Interfaces.flange_a is referenced in the URL modelica://Modelica.Mechanics.Translational.Interfaces.flange_a but could not be found
As proposed by @tobolar, add milestones and labels for VehicleInterfaces issues
The classes VehicleInterfaces.Types.GearMode
and VehicleInterfaces.Types.IgnitionSetting
use Integer constants and a choices annotation in order to behave like an enumeration. This is due to enumerations not being fully supported at the time of original development.
Enumerations are now generally supported in tools so these should be updated (at a major release).
Instantiating the VehicleInterfaces.Drivers.MinimalDriver
should be possible, right?
Instead I get:
[VehicleInterfaces.Drivers: 183:5-188:31]: Failed to instantiate equation
connect(brakePosition.flange_b, driverInterface.brakePedal) annotation(Text(string = "%second", index = 1, extent = {{6, 3}, {6, 3}}));.
The same happens also while running one of the examples with the VehicleInterfaces.Drivers.MinimalDriver
e.g. VehicleInterfaces.Examples.ConventionalAutomaticVehicleExternalDriver
The issue arises both with OpenModelica v1.13.0 version of VehicleInterfaces and the GitHub VehicleInterfaces at commit be62651
In my opinion, a backward compatibility is only given if there are no classes removed from a library.
But since Version 1.2.2, "...removal of Dymola specific visualization" applies and, thus, the backward compatibility is no more given.
I think a more user-friendly solution were to mark deleted classes as obsolete and delete them at the earliest in a non backward compatible version, i.e. 2.0.0.
Solution for now:
In order to simplify the maintenance of the library, I would suggest to delete the years range from the copyright information contained in 'Revisions' of VehicleInterfaces.UsersGuide.Contact. Or even better to delete that Revisions completely since the relevant piece of information is already given on the main page of the library, e.g. VehicleInterfaces.
Any suggestions?
The Modelica class of VehicleInterfaces.Icons.VariantLibrary (class) and its base class Modelica.Icons.VariantsPackage (package) are not compatible.
The Modelica class of VehicleInterfaces.Icons.BaseClassPackage (class) and its base class Modelica.Icons.BasesPackage (package) are not compatible.
See, e.g., MarekMatejak/Physiolibrary#8 for how to fix this issue.
Classes being marked obsolete in v1.2.5 can be removed now:
Modify conversion script accordingly.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.