I want vehicles to enter a junction in FIFO mode,
when speed mode is 'right of way' the priority is constant per road per simulation.
When i don't use 'right of way' i get collisions.
Is there any way to avoid collision when right of way is disabled?
Or is there any way to specifically define the right of way to work in fifo mode
There is the junction type allway_stop which might do roughly what you want. Just try it out by changing the junction type in netedit.
Related
I'm simulating drivers with Eclipse SUMO using TraCi. I have a road segment of 1Km (highway) that contains five lanes: two right lanes that are leading to a right turn (exit), and three left lanes that are leading straight. It seems that drivers that want to go right will stand on the right lanes regardless of the queue size, resulting in two lanes that are very slow, and beside them, three lanes that can have a speed of 120 Km/h.
In reality, some drivers are not waiting in the 1 Km queue, but deciding to jostle to the queue in the middle, while other might regret standing in the queue and decide to go straight instead. This is resulting in a slow down on the three left lanes i.e., it is rare to have two adjacent lanes
(lanes 2 and 3 from the right on this case) with a 100 km/h speed difference (safety reasons)
My question is if a parameter that limits the speed ratio between two adjacent lanes exists, or if there is another way to simulate this kind of behavior, as I could not find any.
There are two different behaviors you propose as alternative to standing in the queue. The first one is changing the lane later which you might achieve by reducing the eagerness to do a strategic lane change with the lcStrategic parameter.
The second idea is to change the route and/or the destination. To change the route automatically you can enable the rerouting device for the vehicles. This will work only if there really is a faster route (taking the jam into account) in your network which leads to the same destination. Another possibility is to employ rerouters to set new routes or destinations. You can define a probability here but it is not possible to let this depend on the size / delay of the jam .
I am new in the world of freertos, I have to do a project that consists of an automatic alcohol dispenser that measures temperature. The parts/sensors of my project are:
DHT22 for temperature (I know its not ideal but its the only one
that I have).
Hc-sr04 for distance measurement (ultrasound).
I2c display 16x2 to show the temperature.
Buzzer to make sound.
Servo to dispense alcohol.
The idea of the project is that when someone comes within 15 cm of the device, the temperature is displayed on the screen, the servo moves and can dispense alcohol, and the buzzer makes a little sound.
As I understand it, I have to create a task for each activity. One to measure temperature and possibly send that information to a queue, another to read the queue and display it on the screen, another to make the sound with the buzzer, another to measure distance with the ultrasound, and another to move the servo.
This is how I was asked to do it, but my question is what is the best way to organize the tasks?
How do I make it so that ...
first the distance is measured,
then the temperature is measured,
then it is shown on the display,
the servo is moved and the sound is made?
What is the best way to communicate between tasks (when a task measures less than 15 cm, tell another task to measure temperature, and then it is shown on the display, and the servo moves and makes the sound)?
I would like to see how you think about it and it would help me a lot to know.
I’m very new to the subject and I’m having a hard time thinking which is the best way. I would appreciate simple solutions that not involve complicated stuff as I'm having a hard time with freeRTOS.
This seems like a fairly simple system, as all work can be done sequentially (i.e. one thing happens after another). You certainly don't need to use dedicated tasks for activities which are done sequentially. In fact, the simplest architecture by far is to have a single task, running in a loop, doing everything. I strongly suggest you start with that approach and build something that works.
Then after you have something that works sequentially in a single task, re-consider your options. It might be the perfect architecture, it might need minor adjustments. You'll be in a much better position to judge.
I have been playing Bejeweled Blitz for a while now. Yes, it is an addiction. In thinking about the game, I have observed that on some boards, the bottom runs dry (no moves) leaving only the top part of the board playable. Frequently that part of the board drys up, and one is left with moves in area cleared by the last move.
The board never runs completely dry, so clearly the program is doing some sorts of calculation that allows it to choose what to drop to prevent it from running dry.
I have noticed in this 'mode' that it is very common for the algorithm to drop jewels which causes more non-dry area to appear in the horizontal area. Perhaps less frequent is a drop which seems designed to open up the bottom part of the board again.
So my question is "How would one go about designing an algorithm guarantee that there is always a move available.?"
I wrote three-in-a-row game a while ago and the way I dealt with that problem is by selecting gems to drop at random and counting all valid moves. If selected gems did not provide at least 1 valid move I would select another set of gems and so on.
This is solvable by exploring the space of possible "jewel drops" and then you apply a rating based on your rules you have asked for. Higher rating could mean follows rule and low ratings mean not following then you choose one slot with the highest rating.
This is not easy to explain, but a rule based approach should do the trick.
In a soccer game, I am computing a steering force using steering behaviors. This part is ok.
However, I am looking for the best way to implement simple 2d human locomotion.
For instance, the players should not "steer" (or simply add acceleration computed from steering force) to its current velocity when the cos(angle) between the steering force and the current velocity or heading vectors is lower than 0.5 because it looks as if the player is a vehicule. A human, when there is an important change of direction, slows down and when it has slowed enough, it starts accelerating in the new direction.
Does anyone have any advice, ideas on how to achieve this behavior? Thanks in advance.
Make it change direction very quickly but without perfect friction. EG super mario
Edit: but feet should not slide - use procedural animation for feet
This is already researched and developed in an initiative called "Robocup". They have a simulation 2D league that should be really similar to what you are trying to accomplish.
Here's a link that should point you to the right direction:
http://wiki.robocup.org/wiki/Main_Page
Maybe you could compute the curvature. If the curvature value is to big, the speed slows down.
http://en.wikipedia.org/wiki/Curvature
At low speed a human can turn on a dime. At high speed only very slight turns require no slowing. The speed and radius of the turn are thus strongly correlated.
How much a human slows down when aiming toward a target is actually a judgment call, not an automatic computation. One human might come to almost a complete stop, turn sharply, and run directly toward the target. Another human might slow only a little and make a wide curving arc—even if this increases the total length to the target. The only caveat is that if the desired target is inside the radius of the curve at the current speed, the only reasonable path is to slow since it would take a wide loop far from the target in order to reach it (rather than circling it endlessly).
Here's how I would go about doing it. I apologize for the Imperial units if you prefer metric.
The fastest human ever recorded traveled just under 28 mph. Each of your human units should be given a personal top speed between 1 and 28 mph.
Create a 29-element table of the maximum acceleration and deceleration rates of a human traveling at each whole mph in a straight line. It doesn't have to be exact--just approximate accel and decel values for each value. Create fast, medium, slow versions of the 29-element table and assign each human to one of these tables. The table chosen may be mapped to the unit's top speed, so a unit with a max of 10mph would be a slow accelerator.
Create a 29-element table of the sharpest radius a human can turn at that mph (0-28).
Now, when animating each human unit, if you have target information and must choose an acceleration from that, the task is harder. If instead you just have a force vector, it is easier. Let's start with the force vector.
If the force vector's net acceleration and resultant angle would exceed the limit of the unit's ability, restrict the unit's new vector to the maximum angle allowed, and also decelerate the unit at its maximum rate for its current linear speed.
During the next clock tick, being slower, it will be able to turn more sharply.
If the force vector can be entirely accommodated, but the unit is traveling slower than its maximum speed for that curvature, apply the maximum acceleration the unit has at that speed.
I know the details are going to be quite difficult, but I think this is a good start.
For the pathing version where you have a target and need to choose a force to apply, the problem is a bit different, and even harder. I'm out of ideas for now--but suffice it to say that, given the example condition of the human already running away from the target at top stpeed, there will be a best-time path that is between on the one hand, slowing enough while turning to complete a perfect arc to the target, and on the other hand stopping completely, rotating completely and running straight to the target.
I'm using GPS units and mobile computers to track individual pedestrians' travels. I'd like to in real time "clean" the incoming GPS signal to improve its accuracy. Also, after the fact, not necessarily in real time, I would like to "lock" individuals' GPS fixes to positions along a road network. Have any techniques, resources, algorithms, or existing software to suggest on either front?
A few things I am already considering in terms of signal cleaning:
- drop fixes for which num. of satellites = 0
- drop fixes for which speed is unnaturally high (say, 600 mph)
And in terms of "locking" to the street network (which I hear is called "map matching"):
- lock to the nearest network edge based on root mean squared error
- when fixes are far away from road network, highlight those points and allow user to use a GUI (OpenLayers in a Web browser, say) to drag, snap, and drop on to the road network
Thanks for your ideas!
I assume you want to "clean" your data to remove erroneous spikes caused by dodgy readings. This is a basic dsp process. There are several approaches you could take to this, it depends how clever you want it to be.
At a basic level yes, you can just look for really large figures, but what is a really large figure? Yeah 600mph is fast, but not if you're in concorde. Whilst you are looking for a value which is "out of the ordinary", you are effectively hard-coding "ordinary". A better approach is to examine past data to determine what "ordinary" is, and then look for deviations. You might want to consider calculating the variance of the data over a small local window and then see if the z-score of your current data is greater than some threshold, and if so, exclude it.
One note: you should use 3 as the minimum satellites, not 0. A GPS needs at least three sources to calculate a horizontal location. Every GPS I have used includes a status flag in the data stream; less than 3 satellites is reported as "bad" data in some way.
You should also consider "stationary" data. How will you handle the pedestrian standing still for some period of time? Perhaps waiting at a crosswalk or interacting with a street vendor?
Depending on what you plan to do with the data, you may need to supress those extra data points or average them into a single point or location.
You mention this is for pedestrian tracking, but you also mention a road network. Pedestrians can travel a lot of places where a car cannot, and, indeed, which probably are not going to be on any map you find of a "road network". Most road maps don't have things like walking paths in parks, hiking trails, and so forth. Don't assume that "off the road network" means the GPS isn't getting an accurate fix.
In addition to Andrew's comments, you may also want to consider interference factors such as multipath, and how they are affected in your incoming GPS data stream, e.g. HDOPs in the GSA line of NMEA0183. In my own GPS controller software, I allow user specified rejection criteria against a range of QA related parameters.
I also tend to work on a moving window principle in this regard, where you can consider rejecting data that represents a spike based on surrounding data in the same window.
Read the posfix to see if the signal is valid (somewhere in the $GPGGA sentence if you parse raw NMEA strings). If it's 0, ignore the message.
Besides that you could look at the combination of HDOP and the number of satellites if you really need to be sure that the signal is very accurate, but in normal situations that shouldn't be necessary.
Of course it doesn't hurt to do some sanity checks on GPS signals:
latitude between -90..90;
longitude between -180..180 (or E..W, N..S, 0..90 and 0..180 if you're reading raw NMEA strings);
speed between 0 and 255 (for normal cars);
distance to previous measurement matches (based on lat/lon) matches roughly with the indicated speed;
timedifference with system time not larger than x (unless the system clock cannot be trusted or relies on GPS synchronisation :-) );
To do map matching, you basically iterate through your road segments, and check which segment is the most likely for your current position, direction, speed and possibly previous gps measurements and matches.
If you're not doing a realtime application, or if a delay in feedback is acceptable, you can even look into the 'future' to see which segment is the most likely.
Doing all that properly is an art by itself, and this space here is too short to go into it deeply.
It's often difficult to decide with 100% confidence on which road segment somebody resides. For example, if there are 2 parallel roads that are equally close to the current position it's a matter of creative heuristics.