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 <[email protected]> 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_______________________________________________
sumo-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-dev
