Re: [sumo-user] Calculating charging time of a ev vehicle at a charging station
Vendors are tweaking their Battery Management Systems all the time but I'm not aware of any vendors that publish a curve for their vehicles. Generically the claimed charge rates are only achieveable when the battery charge level is below ~50% and the battery temperature is above ~12c. Various interest groups/online magazines are the sources for most of the available curve data eg: https://conormclaughlin.net/img/ev_charge_curves/ev_charge_curves.png https://cdn.motor1.com/images/custom/img-tesla-model-3-sr-mic-lfp-2021-dcfc-power-comparison-20210618.png generic curves associated with particular battery technology ought to be possible - otherwise an assumption of an average charge rate at 50% of that claimed will get you into the right ball park! cheers div On Thursday, 16 May 2024 at 08:38, Jakob Erdmann via sumo-user wrote: > @Div, from a technical point of view, it wouldn't be to hard to let the user > define a charging-rate-curve parameter for the vehicle. Are you aware of > available data on such curves? > > Am Di., 14. Mai 2024 um 12:32 Uhr schrieb The div via sumo-user > : > >> You can get the chargingBegin/End and totalEnergyCharged values for each >> vehicle from chargingstations-output. >> >> In your calculation the charging station has an efficiency factor that >> reduces the effective power - you need to apply that. >> >> Yes your calculation will give you a time, however that will be shorter than >> real world times for any effective power over ~7kW >> >> If you want to look at real world times you have to consider the charging >> rate supported by the vehicle and the charge curve of the vehicle. The >> latter varies non-linearly depending on the battery level, with higher >> charge rates being supported at lower levels of charge. It's non-linear >> because most vehicle BMS step change the charge levels during charging. Sumo >> doesn't attempt to model this at the moment. >> >> You could do something with traci and override charge levels but this would >> negate the utility of the charging station output files. >> >> Temperature also has a significant impact on charging rate and ev battery >> usage - summer/winter variations of 30% are not uncommon - that could mostly >> be handled with different parameters for ev/chargestation in separate runs >> for each 'temperature' (some subtleties of battery temperature/conditioning >> vs external temperature would be missed) >> >> Basically I don't think modelling real world charging is feasible with SUMO >> at the moment* - I'd just qualify any results by saying you're >> underestimating ev charge times. >> >> *if chargingstations supported/honoured a 'chargeRate' for each vehicle then >> with traci get/set methods for this it would be feasible to better model >> actual behaviour of charge stations. >> >> Cheers >> Div >> >> Original Message >> On 14 May 2024, 10:51, TIPPANA RAJESH via sumo-user < sumo-user@eclipse.org> >> wrote: >> >>> How to get the charging time(t in secs) required by a ev vehicle at a >>> particular charging station to get it fully charged? >>> >>> Suppose, >>> maxBatteryCapacity = M Wh >>> actualBatteryCapacity = x Wh >>> Power of charging station = P Watt >>> >>> t = (M-x)/P * 3600 secs. Will this work. >>> >>> ___ >>> sumo-user mailing list >>> sumo-user@eclipse.org >>> To unsubscribe from this list, visit >>> https://www.eclipse.org/mailman/listinfo/sumo-user___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Calculating charging time of a ev vehicle at a charging station
You can get the chargingBegin/End and totalEnergyCharged values for each vehicle from chargingstations-output. In your calculation the charging station has an efficiency factor that reduces the effective power - you need to apply that. Yes your calculation will give you a time, however that will be shorter than real world times for any effective power over ~7kW If you want to look at real world times you have to consider the charging rate supported by the vehicle and the charge curve of the vehicle. The latter varies non-linearly depending on the battery level, with higher charge rates being supported at lower levels of charge. It's non-linear because most vehicle BMS step change the charge levels during charging. Sumo doesn't attempt to model this at the moment. You could do something with traci and override charge levels but this would negate the utility of the charging station output files. Temperature also has a significant impact on charging rate and ev battery usage - summer/winter variations of 30% are not uncommon - that could mostly be handled with different parameters for ev/chargestation in separate runs for each 'temperature' (some subtleties of battery temperature/conditioning vs external temperature would be missed) Basically I don't think modelling real world charging is feasible with SUMO at the moment* - I'd just qualify any results by saying you're underestimating ev charge times. *if chargingstations supported/honoured a 'chargeRate' for each vehicle then with traci get/set methods for this it would be feasible to better model actual behaviour of charge stations. Cheers Div Original Message On 14 May 2024, 10:51, TIPPANA RAJESH via sumo-user wrote: > How to get the charging time(t in secs) required by a ev vehicle at a > particular charging station to get it fully charged? > > Suppose, > maxBatteryCapacity = M Wh > actualBatteryCapacity = x Wh > Power of charging station = P Watt > > t = (M-x)/P * 3600 secs. Will this work.___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Air traffic
If you use the 'real' runway/taxiway layout eg as obtained from OSM then you have several 'fast' exits and other more right angle turns from a given runway. With a minimal route for the aircraft - a "from" runway, stop at stand, then a "to" runway, I find you need a couple of specific "via" edges to get realistic routing. However with this and an 'aircraft' landing at ~110kt sumo is quite happy to slam on the brakes to meet an exit closer to the target terminal - I found you needed to set taxiway 'priorities' to ensure the aircraft didn't do this and didn't zigzag across what is really a one way system. Having set those for one landing/takeoff direction I found they just didn't work when you changed direction. Doubtless much fiddling might get it to work but I didn't think it worth the effort, given that in reality different traffic rules come into play when the runway reverses. ie a different net file seemed fine. (all you're doing is amending priorities and closing/opening a couple of connections) Obviously if you use traci to act as 'ground control' and 'tower' then you don't need different files. Cherrs Div Original Message On 13 May 2024, 18:24, wrote: > Dear Div, > > do you have an idea why this is not possible? I have always thought that > reversing the direction of a runway is just a matter of different routing of > my airplanes. I have never tried that in practice, though. > > Jan > > On Mon, 13 May 2024, at 12:00 PM, The div via sumo-user wrote: > >> One more caveat wrt change of runway direction: >> Heathrow for example uses one runway for landing, one for takeoff and >> switches these round in the middle of the day. This can be handled easily by >> using different routes. However I found that change of direction from eg 27R >> to 09L, because the wind direction has changed, could only be modelled by >> use of different network files. This is because different exits/entries/ >> taxiways come into play. Whilst being very specific about routes could >> handle this it offers no real 'modelling' >> >> Original Message >> On 13 May 2024, 10:39, The div via sumo-user < sumo-user@eclipse.org> wrote: >> >>>> Hi, I have question about the new vClasses "aircraft". >>> Are there plans to add air traffic? Or what it is generally good for? >>> >>> I've used sumo to model airports and some drone activities (just out of >>> interest) - my observations: >>> a) Modelling airport ground movements and multi-modal traffic (passenger, >>> bus, rail, cargo, catering, etc) works well today, with the caveat that >>> aircraft tug/pushback behaviour isn't really practical - you can do it at >>> airports with small numbers of stands but at larger airports it's just too >>> messy. >>> >>> b) if you're not using traci to behave as ground control/tower control >>> modelling spaced takeoff/landing needs some fudging and won't be correct. >>> >>> c)it works because in larger airfields ground movements of all traffic, >>> including aircraft, follow strict routes, even across the apron - so you >>> can set up roads/railways mapping these routes. Modelling smaller fields >>> with free movement across the apron won't work. >>> >>> d) passenger loading/unloading times on transit buses/tube lines/aircraft >>> has to be set to unrealistic values because load/unload is at a single >>> point. I haven't yet tried the doors features of v20 that may fix this. >>> >>> e) I looked at airway modelling and decided it wasn't really sensible/could >>> not envisage a use case that would model anything that excel wouldn't: >>> i) distances are huge relative to road distances - meaning you have a long >>> duration simulation for a single vehicle travelling hundreds of miles >>> ii) airway transit is about changing flight level - you need to handle this >>> to get climb/descent timings right >>> iii) using the gui, even just to check behaviour, simply doesn't work on >>> this scale. >>> >>> f) if you assume that eventually drones will be subject to similar airway >>> restrictions as aircraft to avoid collisions then it should be feasible to >>> model them using sumo vehicles - because the range of 'flight levels' >>> available and distances travelled will be relatively small. >>> >>&
Re: [sumo-user] Air traffic
One more caveat wrt change of runway direction: Heathrow for example uses one runway for landing, one for takeoff and switches these round in the middle of the day. This can be handled easily by using different routes. However I found that change of direction from eg 27R to 09L, because the wind direction has changed, could only be modelled by use of different network files. This is because different exits/entries/ taxiways come into play. Whilst being very specific about routes could handle this it offers no real 'modelling' Original Message On 13 May 2024, 10:39, The div via sumo-user wrote: >> Hi, I have question about the new vClasses "aircraft". > Are there plans to add air traffic? Or what it is generally good for? > > I've used sumo to model airports and some drone activities (just out of > interest) - my observations: > a) Modelling airport ground movements and multi-modal traffic (passenger, > bus, rail, cargo, catering, etc) works well today, with the caveat that > aircraft tug/pushback behaviour isn't really practical - you can do it at > airports with small numbers of stands but at larger airports it's just too > messy. > > b) if you're not using traci to behave as ground control/tower control > modelling spaced takeoff/landing needs some fudging and won't be correct. > > c)it works because in larger airfields ground movements of all traffic, > including aircraft, follow strict routes, even across the apron - so you can > set up roads/railways mapping these routes. Modelling smaller fields with > free movement across the apron won't work. > > d) passenger loading/unloading times on transit buses/tube lines/aircraft has > to be set to unrealistic values because load/unload is at a single point. I > haven't yet tried the doors features of v20 that may fix this. > > e) I looked at airway modelling and decided it wasn't really sensible/could > not envisage a use case that would model anything that excel wouldn't: > i) distances are huge relative to road distances - meaning you have a long > duration simulation for a single vehicle travelling hundreds of miles > ii) airway transit is about changing flight level - you need to handle this > to get climb/descent timings right > iii) using the gui, even just to check behaviour, simply doesn't work on this > scale. > > f) if you assume that eventually drones will be subject to similar airway > restrictions as aircraft to avoid collisions then it should be feasible to > model them using sumo vehicles - because the range of 'flight levels' > available and distances travelled will be relatively small. > > g) if you assume that drone traffic will be uncontrolled and reliant on > collision avoidance, then using sumo vehicles won't be practical because > drones will try to travel in straight lines between launch and destination. > (ie there won't be a road network) > > h) I have had reasonable success modelling this latter style of drone > behaviour using a sumo poi to model a drone and traci to manage flight. > > Cheers > Div___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Air traffic
> Hi, I have question about the new vClasses "aircraft". Are there plans to add air traffic? Or what it is generally good for? I've used sumo to model airports and some drone activities (just out of interest) - my observations: a) Modelling airport ground movements and multi-modal traffic (passenger, bus, rail, cargo, catering, etc) works well today, with the caveat that aircraft tug/pushback behaviour isn't really practical - you can do it at airports with small numbers of stands but at larger airports it's just too messy. b) if you're not using traci to behave as ground control/tower control modelling spaced takeoff/landing needs some fudging and won't be correct. c)it works because in larger airfields ground movements of all traffic, including aircraft, follow strict routes, even across the apron - so you can set up roads/railways mapping these routes. Modelling smaller fields with free movement across the apron won't work. d) passenger loading/unloading times on transit buses/tube lines/aircraft has to be set to unrealistic values because load/unload is at a single point. I haven't yet tried the doors features of v20 that may fix this. e) I looked at airway modelling and decided it wasn't really sensible/could not envisage a use case that would model anything that excel wouldn't: i) distances are huge relative to road distances - meaning you have a long duration simulation for a single vehicle travelling hundreds of miles ii) airway transit is about changing flight level - you need to handle this to get climb/descent timings right iii) using the gui, even just to check behaviour, simply doesn't work on this scale. f) if you assume that eventually drones will be subject to similar airway restrictions as aircraft to avoid collisions then it should be feasible to model them using sumo vehicles - because the range of 'flight levels' available and distances travelled will be relatively small. g) if you assume that drone traffic will be uncontrolled and reliant on collision avoidance, then using sumo vehicles won't be practical because drones will try to travel in straight lines between launch and destination. (ie there won't be a road network) h) I have had reasonable success modelling this latter style of drone behaviour using a sumo poi to model a drone and traci to manage flight. Cheers Div___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Get and Set methods of attributes like power, chargeDelay for charging stations
I wanted the same values - as they are not yet available I simply added parameters to the definition of each charging station in the add.xml to match the definition. These are then available to traci via the generic parameter retrieval calls. Obviously you can't set the real parameters from traci but get was enough for me. Div Original Message On 12 May 2024, 19:39, Jakob Erdmann via sumo-user wrote: > This functionality isn't yet implemented in TraCI: > https://github.com/eclipse-sumo/sumo/issues/12772 > The easiest workaround is probably a python script that generates/modifies > the chargingStation file before starting the simulation. > > Am Sa., 11. Mai 2024 um 12:24 Uhr schrieb TIPPANA RAJESH via sumo-user > : > >> Hi, >> I am working on a project which needs to set a random power and chargeDelay >> for all the charging stations at the start of each episode. Unfortunately, I >> am not able find any get/set methods for these attributes. Kindly, let me >> know if there are any ways I can achieve the above objective. >> >> Thank you >> >> Warm regards >> Rajesh >> ___ >> sumo-user mailing list >> sumo-user@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Assistance Request: Building Visual Studio Solution with libsumo Library
As mirko says. Visual studio releases keep moving things around so it's virtually impossible to give generally useful guidelines. You need to find out how to add include directories, library directories and libraries for the specific visual studio version you have. Once you know that, the basic information you need is - The include directory to add is the sumo/include directory in your installation, the library directory to add is the sumo/bin directory and the library is sumolibcpp.lib In your code it's #include and I usually add using namespace libsumo; because I'm lazy. Visual studio will usually guide you to the members but it's useful to remember that the first letter of the domain will be capitalised - ie Simulation, Lane, Vehicle etc. Cheers Div Original Message On 11 Mar 2024, 07:58, Mirko Barthauer via sumo-user wrote: > Dear Milad, > > at that point I would advise you to do some Visual Studio C++ tutorial to get > accustomed to linking libraries. There are plenty help pages on the internet > when searching for c++ linking libraries in Visual Studio. Configuring the > settings for libsumo isn't any way different than any other library you want > to link. > > Best regards > > Mirko > > -Original-Nachricht- > > Betreff: Assistance Request: Building Visual Studio Solution with libsumo > Library > > Datum: 2024-03-10T22:05:02+0100 > > Von: "Milad Sasha" > > An: "Mirko Barthauer" > > Dear SUMO Support Team, > > I hope this message finds you well. > > I am reaching out to request assistance with building a working solution in > Visual Studio for a C++ project that utilizes the "libsumo" library. Despite > my efforts for weeks, I have encountered challenges in configuring the > project and integrating the libsumo library correctly. > > Would it be possible for you to provide a Git repository containing an > already-built solution, along with the simplest example demonstrating the > usage of the libsumo library in a C++ project? Additionally, I would greatly > appreciate it if the repository could include detailed instructions or a > README file explaining how to build the solution. This should encompass any > necessary steps for configuring the project and linking against the libsumo > library. > > Your support in this matter would be immensely valuable in helping me > understand and effectively utilize the libsumo library in my projects. > > Thank you for considering my request. I eagerly await your response and > guidance. > > Best regards, > > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] [EXT] AW: SUMO-gui background options
To get an OSM map - use the share button and you should see a download option - the download size/map scale are coupled so you need to experiment or alternatively pull tiles for a detailed large area and load each separately in sumo-gui - easy enough to get teh overlap exact with the UI___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Variable traffic flows, density and arrival times
Hi, - p.s: If you are providing a similar solution, could you please explain in a readme file what you did? I am not really great at this so a readme file would be much appreciated. No - I am not providing any solution - I used SUMO to look at a specific problem some time ago, was very impressed with it and just maintain an interest in how it develops. - In the config file, I saw that the drone is charging vehicles after stopping at certain points. I am trying to simulate the charging action on the fly, meaning vehicles are not going to stop but rather continue driving towards their destinations without rerouting. Is that possible? ok - I generated those files in response to your request for a script etc - to try and illustrate what I meant in my initial response. I had not understood your use case - from your description, given that you only want to calculate drone flying path, then it feels like you don't actually need to model a drone in sumo at all? ie just use Traci to monitor vehicle charge and position then compute the distance between hub/drone and position, recalculating position once the charge is complete as the start point for the next flight leg. The complication is surely that drones are slower than EV's so it is entirely possible that a drone will never be able to catch the vehicle unless the vehicle is travelling towards a charge hub? It then risks being carried too far from it's home by the time the charge is complete! (The best energy densities currently available/predicted are less than 200 Wh/Kg. I might posit that a minimum usable charge would be 10KWh ie a nominal 50kg payload - the Ehang 184 can carry 100Kg with a maximum speed of 100km/h and a flight time of 23 minutes.) Anyway - using Traci you might do something like: get position of charge hub for each simulation step monitor vehicle charge state until it reaches the level that you deem a drone topup is needed: ( traci.vehicle.getParameter(vehID, "device.battery.actualBatteryCapacity") ) Obtain vehicle position and compute the vector (distance, angle) between charge hub and vehicle for each subsequent simulation step: Compute distance travelled by drone in the step interval - along the vector (add this to total drone path) Compute new drone position Obtain new vehicle position and compute a new vector between drone and vehicle if this is less than a 'charging' distance then charge the vehicle (ie decrement drone charge capacity and increase the actual battery capacity by your charge rate ) if the capacity reaches your threshold or a 'charge time' is reached then you have the current drone position and need to compute the vector to the next vehicle/return charge hub If the thesis is that the drone does not fly while charging - ie is coupled to the vehicle - then don't increment the total drone path while charging. cheers div___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
Re: [sumo-user] Variable traffic flows, density and arrival times
attached zip is a quick and dirty example using containers and specific trips - run it in sumo-gui On Saturday, 6 January 2024 at 15:57, Sadi M Jawad Ahsan wrote: > @The div: Can you please write a pseudocode or a sample script to implement > what you said? > > Sadi M Jawad Ahsan > Graduate Teaching Assistant > Department of Computer Science & Electrical Engineering > mail to: wh11...@umbc.edu > mob: (240)7565564 > > On Sat, Jan 6, 2024 at 9:31 AM The div via sumo-user > wrote: > >> Vehicles( pedestrians, bikes, cars, trucks, rickshaws, trains, planes etc) >> in Sumo can only traverse paths/roads/tracks defined in the net file. >> >> If your EV's are only going to be charged in specific 'lay-by' locations on >> the road network then I guess you could create a secondary set of >> roads/rails, restricted to 'drones', overlaying the road network as >> 'airways' - not necessarily following the roads but visiting each charge >> lay-by. >> >> It's also easy enough to neutralise the colours of specific road classes to >> make them disappear or merge into a background image - ie allowing the gui >> representation to have invisible routes. >> >> The issue being that you cannot model ad-hoc point to point routes for the >> drones - there has to be an 'airway' for sumo to model against. >> >> ( Not necessarily a "gotcha" - I think it is likely that drone traffic will >> end up being mandated to airway equivalents simply to avoid collisions - 3d >> collision avoidance and responsive enough drone manoeuverability to make >> that work is just not practical or even on the drawing board - the >> consequences of flying energy packs colliding and dropping onto a school, >> hospital etc are unpleasant.) >> >> I had some success modelling airports using an 'aircraft' shape and rail >> lines as taxiways/runways etc. I did look at modelling real airways but the >> huge distances involved relative to vehicle sizes and the variation in >> flight levels meant the gui representation was just a bunch of lines - I >> concluded that the only bit worthy of modelling was probably the terminal >> area zones. >> >> good luck >> div >> On Saturday, 6 January 2024 at 13:25, Sadi M Jawad Ahsan via sumo-user >> wrote: >> >>> Hello, >>> I have a research project for which I need to use SUMO and its APIs. I will >>> describe the scenario of what I am trying to do. >>> >>> I am trying to simulate the emergency charge scheduling of multiple >>> electric vehicles via a drone or a mobile charging device. The drone >>> reports to a Global Charging Station (reports means taking instructions to >>> go and charge, reporting termination of operation in case of failure to >>> charge or even if the drone itself needs to be charged). When N number of >>> vehicles request different units of charge from the drone, the drone >>> compiles the requests and based on different algorithms, prepares a >>> priority list of charge requesting vehicles. The drone then flies from its >>> docking station and charges all the vehicles (the vehicles are all inside >>> the drone's charging radius) according to the priority list. I need to >>> output the total flying distance of the drone. >>> >>> What I have done so far is, I have generated the net, route and trip files >>> for the vehicles, but I don't know how to declare a drone in SUMO. I also >>> don't understand how to make a flying path for the drone, since the >>> vehicle's at the moment are moving from one edge to the other in a 10x10 >>> Manhattan Grid. >>> >>> I need to know if I can simulate a drone in SUMO and declare its path. If >>> so, then how? I also need to understand how the priority algorithms can be >>> used in the python script where I am using SUMO and TracI. >>> >>> Please let me know if you have any questions. >>> >>> Thanks >>> Jawad >>> >>> On Sat, Jan 6, 2024 at 7:13 AM Hriday Sanghvi via sumo-user >>> wrote: >>> >>>> Hello, >>>> >>>> I was trying to implement dynamic flows where I wanted to change the >>>> vehsPerHour mid-simulation. >>>> >>>> Example flow: >>>> >>> departLane="random" departPosLat="center" departSpeed="max" id="flow_btt" >>>> number="100" rout
Re: [sumo-user] Variable traffic flows, density and arrival times
Vehicles( pedestrians, bikes, cars, trucks, rickshaws, trains, planes etc) in Sumo can only traverse paths/roads/tracks defined in the net file. If your EV's are only going to be charged in specific 'lay-by' locations on the road network then I guess you could create a secondary set of roads/rails, restricted to 'drones', overlaying the road network as 'airways' - not necessarily following the roads but visiting each charge lay-by. It's also easy enough to neutralise the colours of specific road classes to make them disappear or merge into a background image - ie allowing the gui representation to have invisible routes. The issue being that you cannot model ad-hoc point to point routes for the drones - there has to be an 'airway' for sumo to model against. ( Not necessarily a "gotcha" - I think it is likely that drone traffic will end up being mandated to airway equivalents simply to avoid collisions - 3d collision avoidance and responsive enough drone manoeuverability to make that work is just not practical or even on the drawing board - the consequences of flying energy packs colliding and dropping onto a school, hospital etc are unpleasant.) I had some success modelling airports using an 'aircraft' shape and rail lines as taxiways/runways etc. I did look at modelling real airways but the huge distances involved relative to vehicle sizes and the variation in flight levels meant the gui representation was just a bunch of lines - I concluded that the only bit worthy of modelling was probably the terminal area zones. good luck div On Saturday, 6 January 2024 at 13:25, Sadi M Jawad Ahsan via sumo-user wrote: > Hello, > I have a research project for which I need to use SUMO and its APIs. I will > describe the scenario of what I am trying to do. > > I am trying to simulate the emergency charge scheduling of multiple electric > vehicles via a drone or a mobile charging device. The drone reports to a > Global Charging Station (reports means taking instructions to go and charge, > reporting termination of operation in case of failure to charge or even if > the drone itself needs to be charged). When N number of vehicles request > different units of charge from the drone, the drone compiles the requests and > based on different algorithms, prepares a priority list of charge requesting > vehicles. The drone then flies from its docking station and charges all the > vehicles (the vehicles are all inside the drone's charging radius) according > to the priority list. I need to output the total flying distance of the drone. > > What I have done so far is, I have generated the net, route and trip files > for the vehicles, but I don't know how to declare a drone in SUMO. I also > don't understand how to make a flying path for the drone, since the vehicle's > at the moment are moving from one edge to the other in a 10x10 Manhattan Grid. > > I need to know if I can simulate a drone in SUMO and declare its path. If so, > then how? I also need to understand how the priority algorithms can be used > in the python script where I am using SUMO and TracI. > > Please let me know if you have any questions. > > Thanks > Jawad > > On Sat, Jan 6, 2024 at 7:13 AM Hriday Sanghvi via sumo-user > wrote: > >> Hello, >> >> I was trying to implement dynamic flows where I wanted to change the >> vehsPerHour mid-simulation. >> >> Example flow: >> > departLane="random" departPosLat="center" departSpeed="max" id="flow_btt" >> number="100" route="bottom_to_top" type="veh" vehsPerHour="6000" /> >> >> I couldn't find a way to dynamically set/update flows using TraCI, so I >> assume I have to add vehicles using TraCI to simulate a particular type of >> flow? >> >> 1. So if I wanted to insert vehicles at a rate of 6000 vehs/Hour, I need to >> insert 6000 / (60 x 60) = 1.6667 vehs/Second or 2 vehs/Second? (assuming 1 >> second = 1 TraCI simulationStep()? >> >> 2. There seem to be limitations to 1. For example, if there is a road with >> only a single lane, then there is a maximum vehicle flow that it can >> tolerate, beyond which there is no effect. Is that correct? So I would have >> to have multiple lanes to increase the flow? >> >> 3. Assuming 2 is correct, since 1 lane cannot have a flow higher than 1 >> vehs/Second, I will need as many lanes 'x' to accommodate the desired flow >> [x] vehs/Second? If not, then what are the other ways apart from increasing >> number of lanes that can increase the capacity of the road to tolerate more >> vehsPerHour or flow? >> >> Please advise. >> >> Thank you, >> Sincerely, >> Hriday >> ___ >> sumo-user mailing list >> sumo-user@eclipse.org >> To unsubscribe from this list, visit >> https://www.eclipse.org/mailman/listinfo/sumo-user > > -- > > Sadi M Jawad Ahsan > Graduate Teaching Assistant > Department of Computer Science & Electrical Engineering > mail to: wh11...@umbc.edu > mob: (240)7565564_
Re: [sumo-user] FW: Electric wehicle def.
My 2p The original model was based on measurements from a Bus transit system quite some time ago - one might think that battery/drive train/recuperation efficiencies would have improved considerably since then. I was interested in modelling my own passenger ev (kia soul) and trying to get close to my observed behaviour. I started with a sensitivity analysis against the various parameters in the model and determined that most impact was from the efficiency values, vehicle mass and the radial friction. (frontal area didn't have much impact until speeds > 70km/h) In artificial networks (straight roads, x junction etc) I could not get anywhere near my observed efficiency - the model efficiency values were too high, but reducing these gave unpredictable results. I believe achieved speeds were simply too high. I then tried realistic networks - extracting roads from openstreetmap. I found that I needed much higher efficiency values to replicate observed behaviour. Obviously this was reflecting a single vehicle albeit across many short (5-15km) routes and several longer routes (400-700km). My conclusion was that real world road layout, speed limits, roundabouts, junction topologies etc are needed to properly invoke a realistic relationship between speed, acceleration and deceleration (recuperation) The values I finally submitted got me within better than 10% of observed, close to WLTP and this was still valid in journey prediction. Obviously ymmv! :) Original Message On 2 Nov 2023, 14:32, Mirko Barthauer via sumo-user wrote: > Dear Petró, > > although the model described in the cited publication has been integrated > into SUMO, it was a third-party contribution. I get your message that the > default values of some model constants like the efficiency factors might be > unrealistic. Even if I leave out losses at tire level (as road friction isn't > considered in other parts of the simulation either), I get still way lower > efficiency than the default values. Could you please give as the reference > you took the efficiency table from? Then we can discuss internally how to > deal with that. > > If you want to discuss the topic with the original author, you can find him > e.g. on > [LinkedIn](https://www.linkedin.com/in/tam%C3%A1s-kurczveil-24624a137). His > [thesis](https://doi.org/10.24355/dbbs.084-201707181031) includes an extended > description of the model (German only). > > Best regards > > Mirko > > -Original-Nachricht- > > Betreff: [sumo-user] FW: Electric wehicle def. > > Datum: 2023-11-02T14:42:34+0100 > > Von: "Petró János via sumo-user" > > An: "sumo-user@eclipse.org" > > Dear Developers > > We would like to use SUMO for make a simulation of electric city bus. > > Please help for us the following questions. > > About the SUMO Proceeding description the Vehicle Energy Model working on: > > In case ηprop is the efficiency of the total driving system between the > battery and the roadway. > > Some other study has efficinency of the driveline elements and power > converter: > > - So is it correct to calculate the ηprop=ηdrive equal „Forward” mode? > Because of ηdrive ≈ ηb * ηm * ηco * ηtire ≈ 0.72, so usually ηprop need to > be 0.70÷0.80 in „Forward” mode? > - Pconst. is the average power of constant consumer like heating, cooling air > ventilationing, air compressor, etc. which get energy from the battery via > power converter (ηpc =0.95). The equation (3)->(2)->(5) the battery energy > decreasing by the constant consumer energy (with some others): Econst / > ηprop. It looks like the constant consumer energy goes trought the total > driving system. Please clarify for us if we think wrong, because of this > calculation cause higher consumption of constant consumer. > - Please clarify for us what Recuperation efficiency – ηrecup – means > exactly. Is it the efficiency the total driving and power converter system > from the tires to the battery? So is it correct to calculate the > ηrecup=ηdrive equal „Backward” mode? Because of ηdrive ≈ ηb * ηm * ηco * ηco > * ηtire ≈ 0.56, so usually ηrecup need to be 0.50÷0.60 in „Forward” mode? > - Or should be use? > > Thank You for Your short answer. > > Best regards, > > Petró János > > ___ sumo-user mailing list sumo-user@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-user
