Re: [sumo-dev] Modelling parking

[The div <div@xxxxxxxx>]

Hi,

I started this to model school car park behaviour at pickup time and have been really impressed with how (subjectively) the core simulation matches my perception with relatively minor additions to parking behaviour - very entertaining to watch!

I've been focussed on lot based off-road parking so the sort of changes i've made are:

a) updated MSParkingArea::addLotEntry to use a more representative value for  myEndPos  - so the vehicle moves adjacent to the space to manoeuver.

b) added an MSVehicle::Manoeuvre class to encapsulate this parking behavior.

c) added an "entryManoeuvreIsComplete" check in MSVehicle::processNextStop  (~line 1975, before setting stop.reached true ) and an "exitManoeuvreIsComplete" check in MSVehicle::planMove.

       (Exit manoever enabled in MSVehicleTransfer::checkInsertions - but checked for completion in planMove because i needed the vehicle to be in the lane 'blocking' traffic)

These changes work well and the visualisation is better than i expected because the vehicle brake lights and indicator are on during the 'manoeuvre' - a couple of queries, to help tidying this up please, if you have the time:

1.  I've created  MSGlobals::gModelParkingManoeuvre  to enable/disable the changes - is that what you'd expect?

2. My manoeuvre exit check in MSVehicle::planMove  is  basically an abortive return after the driver state update and action step check - ca line 2169  - is this likely to have any evil side effects that I won't know about?

        if (MSGlobals::gModelParkingManoeuvre && !myManoeuvre.exitManoeuvreIsComplete(t)) return;

3. In modelling a parking site with ~150 lots as 12 parking areas, I have configured several "parkingAreaReroute"s  but at peak I'm noticing that there are often 2-3 vehicles that are rerouted to a 'full' area immediately after an area fills, whether or not the area is 'visible' - is this expected behaviour? If not please can you give me a pointer to where i might trace the cause of this? At what point on a lane is the reroute triggered - does it stay constant after lane entry?

4. The visual representation of the vehicle in the lot, relative to the parking manoeuver, can be matched by rotating the lot angle by 180 degrees where necessary - ideally i'd manage the display by reference to the manoeuver - but i suspect this is too convoluted - any thoughts?  (Relevant to lots at ~90 degrees to the lane where the vehicle may be parked nose in/nose out on some probability basis so is not constant)

4. I've hardwired some basic parameters for initial testing - what is your preferred approach to getting these configurable - specifically things like the angle and time values in the sort of code below: 

      (The lot angle computation is part of the updates in addLotEntry, to ensure that the manoeuver angle reflects the correct manoeuver for the side of the road where the lot is placed)

bool

MSVehicle::Manoeuvre::configureEntryManoeuvre( MSVehicle* veh, SUMOTime currentTime )

{

    if (veh->getMyStops().empty()) return false;  // should never happen - checked before call

   

    const Stop& stop = veh->getMyStops().front();

    myManoeuvreStop = stop.parkingarea->getID();

    myManoeuvreType = MSVehicle::MANOEUVRE_ENTRY;

    myManoeuvreStartTime = currentTime;

// todo - get these times/parameters into a configuration file

//     potentially adjust for vehicle type/driver experience

//     where parking is optionally reverse we need to implement optionality!

   const int angle = stop.parkingarea->getLastFreeLotAngle();

   SUMOTime manoeuvreTime;

    if (angle < 10) {

        myParkingApproach = MSVehicle::PARKING_LOT_PARALLEL;

        manoeuvreTime = 3000;   // straight in but potentially needing parallel parking

    } else if (angle < 80) {

        myParkingApproach = MSVehicle::PARKING_LOT_FORWARDS;

        manoeuvreTime = 1000;   // straight in

    } else if (angle < 110) {

        myParkingApproach = MSVehicle::PARKING_LOT_REVERSE90;

        manoeuvreTime = 11000;  // optional forwards/backwards

    } else if (angle < 170) {

        myParkingApproach = MSVehicle::PARKING_LOT_REVERSEOBTUSE;

        manoeuvreTime = 8000;   // backwards into obtuse space

    } else {

        myParkingApproach = MSVehicle::PARKING_LOT_PARALLEL;

        manoeuvreTime = 3000;   // straight in but potentially needing parallel parking

    }

    myManoeuvreAngle = angle;

    myManoeuvreCompleteTime = currentTime + manoeuvreTime;

Because I'm configuring the manoeuvre time for the 'lastFreeLot' there is a corner case where the 'lastFreeLot' changes during the manoeuver (a vehicle exits)  which means the vehicle ends up in a lot different to where it is manoeuvering

 i think this is a cosmetic issue as the overall impact on disruption/emissions is minimal - I don't see a way round this.

cheers and thanks for any response

Div

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, 17 June 2019 14:40, The div <div@xxxxxxxx> wrote:

Many thanks Jakob, that makes perfect sense

The abstract approach is sensible -

  I wouldn't expect the effort to display manouevres visually to be worthwhile - it feels like the important model features are whether the lane is blocked and the extended engine running time.

Occupancy matters for on-road parking as it would determine whether parallel parking was necessary - i suspect there are far more complex determinations in the off-road case.

we shall see.

thanks again

Div