sisl/automotivedrivingmodels.jl

Driving simulation architecture for Julia

automotivedrivingmodels.jl's Issues

Replace functions named `get_`

A lot of functions are named get_..., I think we could remove the get in most of the cases to match julia style guides.

Examples:
get_lane -> lane
get_center -> center (arguable, center is a bit too general, we might want to change it to centerpoint)
get_rear -> rear (or rearpoint)
get_frenet_realative_position -> frenet_relative_position
...

Useful Type Info

Could the great comments in this type definition:

struct Frenet
roadind::RoadIndex
s::Float64 # distance along lane
t::Float64 # lane offset, positive is to left
ϕ::Float64 # lane relative heading
end

Be made available when one types ?Frenet at the REPL/jupyter notebook? Instead of 'No documentation found':

LoadError with LinearAlgebra Package

I am relatively new to Julia so I apologize if this is a trivial question. When I am trying to load the AutomotiveDrivingModels with the command "using AutomotiveDrivingModels", I am getting a LoadError where it says:

ArgumentError: Module LinearAlgebra not found in current path. Run 'Pkg.add("LinearAlgebra") to install the LinearAlgebra package.

Is there some LinearAlgebra package that is required to install this package? If so, is there a link that you can provide for me to install it?

Extract a barebones BasicRoadways.jl package

Just a thought I had: while @kylejbrown17 is working on the big Roadways.jl package, would it make sense to make a really simple BasicRoadways.jl package that can just draw basic straight and curved roads. That way AutoViz would not have to depend on AutomotiveDrivingModels

IDM leading to negative velocities

Currently, in the case where the distance to the lead vehicle is smaller than s_min a full break with maximum deceleration is returned. At this maximum deceleration, the resulting velocity may become negative (e.g. at dt=1s, initial state with v=2m/s, deceleration=9m/s -> v_new=-7m/s).
It is probably safe to say that negative velocities (i.e. backward driving, against the flow of traffic) are usually not desired.
I suggest changing the model such that it does not reach negative velocities, as this seems out of the scope of an IDM.

Move the `observe!` method for IDM

It is currently here:
https://github.com/sisl/AutomotiveDrivingModels.jl/blob/master/src/behaviors/lat_lon_separable_driver.jl#L8

It is not a very intuitive place, we should put it in lane_following_drivers.jl

proposed name change

This package has a long name.
I propose changing it to Automotive
Other options are:

• Auto
• AutoCore - as the other packages are called Auto<Something>
• AutoSim

Deprecate get_name(::DriverModel)

Is this really useful?

Bug in neighbor feature functions

Hi there,

In the function Base.get(::Feature_Dist_Front) and Base.get(::Feature_Dist_Rear)here, you can pass censor_hi as argument. But it is not used insided the function. Instead hard code values are used. Is that a bug?

Get rid of documentation warnings - make documentation work for interfaces

Using julia --project make.jl prints several warnings for missing docstrings, for example for the get_name function. get_name is documented in the interface, but without argument signature. The documentation (such as in docs/src/behaviors.md) currently lists get_name(::DriverModel for documentation which creates a warning.

More generally, the goal should be to make the documentation-generation warning-free

driving off roadway

In the current implementation, when a vehicle drives off the beginning or the end of a roadway, it is projected to the beginning / end of it. (roadways.jl line 676). I don't think this is the best default behavior, and also it is inconsistent with situations where the vehicle leaves the road on the side (which is currently allowed afaik).
It may be worth discussing the alternatives:
Option A: always clipping vehicles to stay on the road (longitudinally and laterally)
Option B: throwing an error when a vehicle leaves the road, since the environment there is not defined
Option C: allowing vehicles to leave the road (longitudinally and laterally) by also allowing Frenet coordinates that lie off the roadway

The current clipping behavior (option A) gave me some unexpected results from the simulator and it took me a while to find the source of the error, which is why I'm opening this issue. Also, I can't think of a use-case where such clipping could actually be useful (especially in longitudinal direction).

Throwing an error (option B) may be a little strict but would encourage to design driving models which avoid such driving behavior in the first place.

Allowing off-road coordinates (option C, which is the status-quo in the lateral direction) is the least intrusive solution but it raises the question what vehicles are doing off the road in the first place. Also, a projection of Frenet coordinates outside of the road is not well defined.

Would be interested in other people's views on this or additional options I have not considered yet.

Tim2DDriver relies on QueueRecord

Tim2DDriver makes use of QueueRecord structure for scenes
see tim_2d_driver.jl, line 47

This makes it incompatible with the new simulation interface

How to simulate lane change and lateral traverse behaviors?

I modified AMD/docs/2DStadium.ipynb and tempted to simulate some lane change and lateral traverse behaviors. Here is my configuration of vehicles and driver models:
push!(scene,Vehicle(VehicleState(VecSE2(10.0,-DEFAULT_LANE_WIDTH,0.0), roadway, 29.0), VehicleDef(), 1))
push!(scene,Vehicle(VehicleState(VecSE2(20.0,-DEFAULT_LANE_WIDTH,0.0), roadway, 22.0), VehicleDef(), 2))
push!(scene,Vehicle(VehicleState(VecSE2(30.0,-DEFAULT_LANE_WIDTH,0.0), roadway, 27.0), VehicleDef(), 3))
...
models[1] = LatLonSeparableDriver( # produces LatLonAccels ProportionalLaneTracker(), # lateral model IntelligentDriverModel(), # longitudinal model )
models[2] = Tim2DDriver(timestep, mlane = MOBIL(timestep), )
models[3] = Tim2DDriver(timestep, mlane = MOBIL(timestep), )
...
set_desired_speed!(models[1], 10.0)
set_desired_speed!(models[2], 20.0)
set_desired_speed!(models[3], 30.0)

I've studied the parameters of MOBIL, but whatever parameters I input to MOBIL, for an example, politeness=0, advantage_threshold=0. Lane change and lateral traverse behaviors just simply did not happen. Every vehicle follow the front one tightly. And I log some outputs of MOBIL, namely accel_M_test and accel_M_orig. They are zero.
Is MOBIL working under some circumstances that I haven't know yet? Or, just something wrongs with my input parameters.
Thank you for your time.

Move the feature extraction functionalities to NGSIM or another package

An significant part of the code base is dedicated to extract features from pre-existing trajectories.
I am wondering if this is the right place for these functions or if they should be in a module on their own or part of the NGSIM.jl package.

The main advantage is that it would make it easier to decouple AutomotiveDrivingModels and Records.jl.

@raunakbh92 any thoughts?

Register in General

It might be worth registering this package to julia General Registry.

I think the main limitation is the dependencies in Vec.jl and Records.jl.

Here are my suggestions:
option 1:
Register Vec to General (under another name), make Records.jl a submodule of AutomotiveDrivingModels.jl, register AutomotiveDrivingModels

• Vec has a lot of overlapping functionalities with existing julia package (unsure if that is a real issue, if we have appropriate naming)
• Vec is not really used outside of AutomotiveDrivingModels

option 2:
Make both Vec and Records submodules of AutomotiveDrivingModels.

• Requires a bit less effort
• Might be easier to maintain

I prefer option 2, as Vec and Records are not used anywhere else, and it might lead to less confusion for users about where datastructures like Frame, Entity or VecSE2 are defined.

Thoughts?

No documentation in docs/Crosswalk.ipynb

The Crosswalk tutorial has code but lacks the explanatory text of the other two notebooks.

How to add a new car-following model?

Thank you for creating this package. I am new to julia and just stumbled upon this awesome package.

I can see in the documentation that a few car-following models e.g., IDM is included. Can I contribute by adding more models, e.g., Wiedemann car-following model? I can't seem to find the documentation where I can contribute.

Thanks!

The difference between NGSIMTrajdata and Trajdata

Could you tell me where could I find the definition of Trajdata? Because based on the hints below, we could find the explicit definitions of Trajdata. But I could not find it in AutomotiveDrivingModels.jl/src/simulation/.

The resulting files can then be loaded into a Julia program as Trajdata, a type defined in AutomotiveDrivingModels.jl. See jnotebooks/Demo.ipynb for example usage.

In the file https://github.com/sisl/NGSIM.jl/blob/83378b59f8f766ad30be87a9ddba0ead1de9562a/src/trajdata.jl#L201
The NGSIMTrajdata is converted to Trajdata. Could you tell me why should we do that? BTW, could you tell me what is the difference between NGSIMTrajdata and Trajdata? I could find the definition of NGSIMTrajdata.

get_neighbor_rear_along_lane returns neighbor fore when neighbor rear is in a different road segment

When finding the rear neighbor using get_neighbor_rear_along_lane, the fore neighbor is selected rather than the rear in situations where the rear is in a different road segments. And more specifically, it primarily, and perhaps only, happens in the specific road segment considered in the attached notebook.

I think the bug is in the distance calculations, but I haven't figured it out yet. Included in the notebook is a copy of get_neighbor_rear_along_lane with a change that prevents the bug from occurring, but does so indirectly and so is not a great solution. The notebook also contains a minimal example demonstrating the bug.

get_neighbor_rear_along_lane.zip

Get up to date with Vec.jl

Vec.jl now supports julia 0.7 since sisl/Vec.jl@e0fb7a5.
It seems to cause AutomotiveDrivingModels.jl build to fail.

Use of BicycleModel and VehicleDef

The Scene and Vehicle alias could be parameterized with the vehicle definition.

Modernize Base.write overloads in records/common.jl

These write functions are used by Base.write overload for writing listrecords. These are tested by writing trajdata under test_states.jl line 166. We should replace by better way to write.

The sisl/AutomotiveDrivingModels.jl doesn't contain any definition to type IntegratedContinuous

Hi, I've download sisl/latent_driver and try running through it. Type IntegratedContinuous has been used in several files in sisl/lantent_driver. Such as:
sisl/latentdriver/pull_traces/passive_aggressive.jl row:89 sisl/latentdriver/pull_traces/pull_2d_traces_passive_aggressive.jl row:59 sisl/latentdriver/validation/AutoViz.jl row25 ...
I can't find this type's definition in sisl/AutomotiveDrivingModels.jl. But I can find the definition in maxiaoba/LofiSimu/AutomotiveDrivingModels.jl. I have searched the whole github with the key word: IntegratedContinuous and I found that only the latter contains a definition to IntegratedContinuous. And the latter seem raise much less concern in github. Now that these two repositories are in a same
organization, why the sisl/AutomotiveDrivingModels.jl cannot support sisl/lantent_driver.
Thank you for your time and best wishes.

Feature extraction functionality

The current functionality does not support easy logging of features.
Instead we suggest to use DataFrames.

the package would export a feature extraction function:

extract_features(list_of_features, scenes, ids) 

that would return a namedtuple with IDs as keys and a dataframe as values. The column names are automatically determined from the list_of_features given by the user, as symbols.

A feature consist of a type and an extract_features function describing its behavior on a single scene.

Deprecate 1D state and 1D roadway

Is there a benefit from having those?

'Vehicle' name change

Since the Vehicle type is used to represent pedestrian models as well, I suggest changing the names with 'Vehicle' to Agent (i.e. Vehicle --> Agent, VehicleDef --> AgentDef, VehicleState --> AgentState).

Recording model states

It would be nice to have a mechanism to log model states in the simulation.

Stochasticity in IDM and similar models

The intelligent driver model is traditionally free of stochasticity.
The implementation in AutomotveDrivingModels includes a value for a Gaussian variance to add stochasticity. I propose that we decouple these concepts.

• We remove the variance from IDM and have it be deterministic
• We introduce a GaussianDriver that can include a submodel which produces the mean prediction. Thus one can include the IDM or any other driver model and introduce stochasticity on top of it.

Thoughts?

Redesign get_neighbor_... functions

the functions get_neighbor_fore_along_lane, get_neighbor_fore_along_left_lane ... contain a lot of repeated code.

It could be nice to redesign this part to have one function find_neighbor that would accept as argument the specification: fore, rear, left lane, right lane ...
The signature could be find_neighbor(scene, roadway, ego, lane; rear=False). This function would find the front neighbor of ego in lane. It would find the rear neihbor if rear is set to true.

is_colliding() MethodError

I am getting an error when calling the following method : is_colliding(::Vec.VecSE2, ::AutomotiveDrivingModels.ConvexPolygon)

This is on julia 0.6:

julia> ray
VecSE2({5.000, 0.000}, -0.503)

julia> poly
ConvexPolygon: len 4 (max 4 pts)
	VecE2(15.000, -1.500)
	VecE2(15.000, -4.500)
	VecE2(22.000, -4.500)
	VecE2(22.000, -1.500)


julia> is_colliding(ray, poly)
ERROR: MethodError: no method matching is_colliding(::Vec.VecSE2, ::Vec.LineSegment)
Closest candidates are:
  is_colliding(::Vec.VecSE2, ::AutomotiveDrivingModels.ConvexPolygon) at /home/boutonm/.julia/v0.6/AutomotiveDrivingModels/src/2d/utils/minkowski.jl:298
Stacktrace:
 [1] is_colliding(::Vec.VecSE2, ::AutomotiveDrivingModels.ConvexPolygon) at /home/boutonm/.julia/v0.6/AutomotiveDrivingModels/src/2d/utils/minkowski.jl:300

State1D needs posf, posg, velf, velg

State1D needs posf, posg, velf, velg to be compatible with new interface.
Partially implemented in #64 but needs further review

`observe!` default is too specific

I don't think we should provide a default for the observe! method and let it throw a method error when it is not implemented for a custom model.

https://github.com/sisl/AutomotiveDrivingModels.jl/blob/master/src/behaviors/interface.jl#L41

@mattuntergassmair

Documentation

Some functions have docstrings associated with it.
It might be worth setting up Documenter.jl for this package. Of course more documentation effort is needed but it would still be better than nothing.

version 0.8

As AutoViz is moving towards a version 0.8 maybe this package should move on as well.
Here is a description of stuff to do:

• merge #64
• make Vec.jl a submodule #76
• incoroporate Records.jl #78
• new feature extraction mechanism #72
• use literate to run tutorials in the test suite #77
• rename Frame to Scene
• rename get_... functions #74 (some of them)
• Rename to AutomotiveSimulator.jl
• Register AutomotiveSimulator.jl to sisl Registry with documentation tests commented
• Fix AutoViz, rename AutoViz
• Register to general lose #56
• Register AutomotiveVisualization.jl to general
• Restore doc tests in AutomotiveSimulator.jl

Drop support for deprecated functions:

• simulate
• state1D
• get_name
• Scene and Vehicle aliases

update simulation doc

What are the units of 'longitude accelerate' and 'turning_rate values'?

What are the units of 'longitude accelerate' and 'turning_rate values' that the simulator receive?
For the second one, should the turn rate be global or ego?

Data structure for scene representation

What is the real benefit of using EntityFrame to represent a scene?
It seems like the only benefit is pre-allocation.

Alternative data structures:

• Vector: would still allow pre-allocation, very simple to work with, retrieving a vehicle by its id would not be as straightforward (although it can be done with a one liner findfirst(x ->x.id == egoid, scene), but not very efficient)
• Dict (or OrderedDict), mapping id to Entity, would be trivial to retrieve vehicles by their id, not as straightforward to pre-allocate.

Why would we change?

• Using data structure from the standard library is easier to understand.
• Potentially allows to use any AbstractArray type

My personal opinion is that using AbstractArray as a default is the easiest solution.

Ideally we want the flexibility to use either representation. Dictionary optimizes for accessing vehicle by id, one might want more complex data structures to e.g. find neighbors easily.

IDM's δ param should be Int?

δ is typically 4.
If δ is allowed to be floating point you can end up with values like 0.5, which produces complex results for negative v_ratio.
Will probably change this soon in the typewise branch unless someone objects.

Installation instructions missing