Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-dev] Discussion on EV Rerouting with Stationfinder Device

Hi,

 

there are some problems with your scenario.

  • Please be sure that the vehicles actually have the devices assigned (in the routes file there is no vehicle with the ID "EV", but one called "reroute")
  • Then you need to set "device.stationfinder.rescueAction" parameter to value "none" if you want the vehicle to continue traveling with empty battery

There was a small problem with the current stationfinder logic. Vehicles waited until the state of charge had dropped by 10% of battery capacity before checking again. I have changed it such that the vehicle will immediately look for charging stations when it is inserted with very low charge. You'd need either to rebuild from Github source or wait until tomorrow for the compiled binaries.

Regarding the parkingArea: If you mention the parkingAreaID explicitly in the chargingStation definition as explained in the docs, it is assumed the charging points are on the parking spaces. The vehicles will leave the road for the charging process. You just need to load / define the charging station after the parkingArea because one refers to the other.

 

Best regards,
Mirko

 

 

-----Original-Nachricht-----

Betreff: Re: [sumo-dev] Discussion on EV Rerouting with Stationfinder Device

Datum: 2024-09-30T09:22:31+0200

Von: "Haotian Li" <haotian.li@xxxxxxxxxxxxx>

An: "Mirko Barthauer" <m.barthauer@xxxxxxxxxxx>

 

 

 

Hi,
 
The project is attached. The test cases are in the routes.rou.xml. You can locate them by searching "Test". I think my problem is the enabling of stationfinder and battery devices. It should disappear as default if stationfinder is set correctly.
 
Best,
Haotian

On Mon, 30 Sept 2024 at 14:49, Mirko Barthauer <m.barthauer@xxxxxxxxxxx> wrote:

Hi,

 

could you please check what the result you get without the rerouting device (if possible)? Did you set other stationfinder parameters (because by default vehicles with empty battery AND stationfinder device should be removed from the network)? If the scenario is not too heavy, you may provide it as well to let me check it directly...

 

Best regards,

Mirko

 

 

 

 

-----Original-Nachricht-----

Betreff: [sumo-dev] Discussion on EV Rerouting with Stationfinder Device

Datum: 2024-09-28T04:57:40+0200

Von: "Haotian Li via sumo-dev" <sumo-dev@xxxxxxxxxxx>

An: "sumo developer discussions" <sumo-dev@xxxxxxxxxxx>

 

 

 

Hi,
 
I am trying the EV rerouting with the stationfinder device. The stationfinder device works on some EVs while the charging station with parking area is originally on their route. I don't need to predefine STOP events. Whereas, the other EVs, which don't have any charging station on the original route, could not reroute to any charging station. 
 
I checked the accessibility and capacity issues of charging stations. To avoid that, I chose a very similar route to that working route, but the similar route takes another edge right before the junction leading to the edge contains a charging station and parking area. In that case, the accessibility is granted. I also made sure that the two EVs don't exist together at any timestep, which means that the first-joined EV finished the trip and disappeared from the network before the later EV joined. What's more, I only set two EVs in the traffic network, others don't have battery devices. And, there is no re-router for road closure during a specific time period.
 
I predefined the hyper-parameter for stationfinder and rerouting devices: 
 
1. .stationfinder.enabled true
2. .stationfinder.needToChargeLevel 0.2
3. .stationfinder.radius 3600
 
1. .rerouting.period 30
 
However, the battery.out and TraCI all showed that the EV with similar route can't reroute to that route to charge and the vehicle kept driving while battery is 0 (default). Would you please give me any suggestions about this? I will provide more detailed information if you need. Looking forward to your reply.
 
Best,
Haotian Li
 
 
 
 

 

 



Back to the top