I have two netlogo files with this identical code:
to setup
ca
crt 10
[setxy random-xcor random-ycor]
reset-ticks
end
to go
ask turtles [
ifelse any? turtles-on patch-ahead 1
[rt random 40 lt random 40]
[fd 1]]
tick
end
In this file works: test 1,
but not on this one: test 2. It states
TURTLES-ON expected input to be an agent or agentset but got NOBODY
instead.
Why does this happen?
The error code is part of a larger model that states the same error, how can I fix it?
This issue is due to the difference in world-wrapping in your two files- in Test 1 you have world wrapping on:
Whereas you have it turned off in Test 2:
This means any turtle that reaches the edge of the world is querying a patch that does not exist- a patch outside of the world (nobody). You can either turn world wrapping on, or address the movement model by checking that movement is possible either with something like can-move? or by coding it manually. For example, you could change your go in test 2 to
to go
ask turtles [
ifelse patch-ahead 1 = nobody or any? turtles-on patch-ahead 1
[rt random 40 lt random 40]
[fd 1]
]
tick
end
Note that order matters in this case- you have to check for nobody before checking any? turtles-on patch-ahead 1
Related
I have a model where humans and a door are created. Humans face the door and run to it and exit. The problem is that some humans stop for some reason. Even if only one human is used, it some times reaches the door, and some times it doesn't. What do I have to do so humans always reach the door? This is the model, and this is the code:
globals [ID-door]
breed [door doors]
breed [human humans]
to setup
clear-all
set-default-shape door "star"
crt number [
setxy random-xcor random-ycor
set color cyan
set breed human]
new-door
reset-ticks
end
to new-door
ask one-of patches [sprout-door 1]
ask door [
set color yellow
set size 2
set ID-door who]
end
to go
if count human = 0 [stop]
ask human [
move-human
check-door]
tick
end
to move-human
face doors ID-door
ifelse any? human-on patch-ahead 1
[rt random 40 lt random 40]
[fd 1]
end
to check-door
if any? door-on patch-here [die]
end
Your problem is patch-ahead 1. This looks a distance of 1 in whatever direction the turtle is facing. Imagine the turtle is at the top left corner and looking toward the bottom right corner. The distance to the corner is >1 and the turtle is triggering the 'stay here' check and will be stuck until it is sufficiently turned around so that there is a different patch in front of it.
So you need to get the turtle to exclude itself from the check, which is a job for other. Change ifelse any? human-on patch-ahead 1 to ifelse any? other human-on patch-ahead 1.
I changed the move-human procedure to the following, and now the model works:
to move-human
ifelse patch-ahead 1 = nobody or any? other humans-on patch-ahead 1
[rt random 40 lt random 40]
[fd 1
face door ID-door]
end
As stated by JenB, patch-ahead 1 was the problem, so:
a) Because the world has horizontal and vertical limits (it´s not a wrapped space) the line patch-ahead 1 = nobody checks the absence of patches when such limits are reached.
b) The line other humans-on patch-ahead 1 excludes the current turtle as it may be counted because of the possibility that the distance of 1 may still be inside the current patch, like this image:
I want to compare the patches in a certain radius regarding the amount of a certain class of agents on them. The agents should move to the patch where the most agents (in this case humans) are. If they are already on the patch with the most humans then they must not move. I coded it and the humans group but most of them don't stay and run around in lines (one behind the other). Would be great if anyone of you could have a quick look at my code. Thanks
if Strategy = "Gathering-Simple" [
if ((count(humans-on max-one-of patches in-radius rad [count(humans-here)] )) ) >= count(humans-here) [
if count(humans-on patches in-radius rad) - count(humans-here) > 0 [
face max-one-of patches in-radius rad [count(humans-here)]
fd 1
]]
]
This is a complete working example that uses your code. Is this displaying the behaviour you mean? It does have turtles chasing each other.
to setup
clear-all
create-turtles 100 [ setxy random-xcor random-ycor ]
reset-ticks
end
to go
let rad 5
ask turtles
[ let target-patch max-one-of patches in-radius rad [count turtles-here]
if count turtles-on target-patch >= count turtles-here ; comment 1
[ if count turtles-on patches in-radius rad > count turtles-here ; comment 2
[ face target-patch
forward 1
]
]
]
tick
end
If so, have a look at the two lines I have comments on.
Comment 1: The >= means that, even if the turtles are already on the highest count patch, this condition will be satisfied because count turtles-here will be equal to the count of the turtles on the highest count patch (this patch).
Comment 2: This line means that as long as there are any turtles on any patch within the radius but not on the particular patch where the asking turtle is located, then the turtle will move forward.
If you want to only have turtles move if not on a maximum count patch, try this instead:
to setup
clear-all
create-turtles 100 [ setxy random-xcor random-ycor ]
reset-ticks
end
to go
let rad 5
ask turtles
[ let target-patch max-one-of patches in-radius rad [count turtles-here]
if count turtles-on target-patch > count turtles-here
[ face target-patch
forward 1
]
]
tick
end
I took out the = in the comment 1 line and removed the second condition entirely so now the turtles move if their current patch has fewer (strictly, not <=) turtles than the patch they've spotted.
I agree with the previous post, but have some additional information.
If you want to move entirely to the target patch on each iteration, instead of moving just one step towards the target patch, in the above answer you could replace the code which produces one step of motion
[ face target-patch
forward 1
]
with
[
move-to target-patch
]
I confirmed by experimentation that the results of the two methods of moving will produce similar but somewhat different results.
I tried the following syntax but got the following error.
Error messages: TURTLES-ON expected input to be an agent or agentset but got NOBODY instead.
In the 2D screen when an error message was issued, an error occurred when the turtle reached the rightmost cell. If the sintax "forward 1", this case works well withour any error. But I need to use the "forward 1 * 0.1" syntax with "tick-advance 0.1".
I already saw the following description, but I do not solve it still now.Does anyone know a good way? Thank you in advance.
https://ccl.northwestern.edu/netlogo/docs/programming.html#topology
The following is an example syntax:
ask turtles with [xcor < max-pxcor][
if not any? turtles-on patch-ahead 1
[forward 1 * 0.1]]
The can-move? reporter referenced in your link is one way (and references another: patch-ahead distance != nobody). In the dictionary definition, it notes that the reporter reports true when the turtle could move some distance without violating topology- in other words, if the turtle can move to an existing patch. Any patches "off the edge" of a world without world wrapping do not exist, and so return nobody.
tick or tick-advance shouldn't figure into this issue, as the evaluation of the patch-ahead is done by each turtle independent of timing. For example, here's a toy model that doesn't have tick or tick-advance at all:
to setup
ca
crt 200 [
move-to one-of patches with [ not any? turtles-here ]
pd
]
reset-ticks
end
to go
let speed 1 * 0.1
ask turtles [
if can-move? speed and not any? other turtles-on patch-ahead speed [
fd speed
]
]
end
Note that I've turned world-wrapping off entirely, and get a result like what is shown below- no errors, and turtles have stopped moving either because there is a turtle in there way or because they've bumped up against the edge of the world:
I have created a new patch type which allows turtles to turn randomly down various paths while one a junction patch ( with pcolor 6 ). How should I modify this code so that I do not get the error "Towards expected input to be an agent but got nobody instead." The code is as follows :
if pcolor = 6 [ set heading towards one-of neighbors in-cone 1 180]
Any help would be much appreciated.
To specifically answer your question, you need to check if there are any patches that fulfill your criteria. To do that, you can do
ask a-turtle [if any? neighbors in-cone 1 180 [face one-of neighbors in-cone 1 180]]
Doing it this way, you will create the same turtle set twice (when you check if there are any, and before you face one of them), so a more optimized way of doing this is:
ask a-turtle [
let eligible-neighbors neighbors in-cone 1 180
if any? eligible-neighbors [face one-of eligible-neighbors]
]
That said, I think Alan is right that you are getting this error because you have wrapping off and your turtles are either in a corner or facing a wall. If this is the case, you need to figure out what to do in that case. If you just want them to turn around and keep going, you could use ifelse like this:
ask a-turtle [
let eligible-neighbors neighbors in-cone 1 180
ifelse any? eligible-neighbors
[face one-of eligible-neighbors] ;; face a neighboring patch if there are any
[rt 180] ;; else, turn around 180 degrees
]
try first making a temporary variable with 'let', then setting the heading towards that.
e.g.
let FaceHere one-of neighbors in-cone 1 180
face FaceHere
haven't tried that - just an idea.
by the way, you can replace
set heading towards
with
face
I'm trying to set turtles heading equal to leader's heading and at the same all turtles including leaders must avoid obstacle( avoid_obstacles function). My problem is, when i add the set heading code
in flock function:
[set heading [heading] of one-of nearby-leaders ]
it cause my avoid-obstacle code to break. if i comment out this code, avoid obstacle work fine. below is my complete code.
to go
set time-to-evacuate time-to-evacuate + 1
ask turtles [check fd 0.1]
ask turtles [avoid_obstacles fd 0.1]
ask turtles with [pcolor = red][die] ;;turtles exit thru red door will die
if all? turtles [ pcolor = red ] ;; stop simulation
[ stop ]
tick
end
to check
if not leader?
[let beings-seen patches in-cone vision vision-angle with [pcolor = red]
ifelse any? beings-seen
[let target one-of beings-seen face target fd 1 ]
[flock]]
if leader?
[let beings-seen patches in-cone leader-vision leader-vision-angle with [pcolor = red]
ifelse any? beings-seen
[let target one-of beings-seen face target fd 1 ]
[flock]]
end
to flock
let nearby-leaders turtles with [leader? ]
if any? nearby-leaders in-radius vision
[ set heading [heading] of one-of nearby-leaders ]
end
to avoid_obstacles ;; all obstacles set as green patches
let i 1
while [[pcolor] of patch-ahead i != green and i <= vision]
[set i (i + 1) ]
if ([pcolor] of patch-ahead i = green)
[
ifelse [pcolor] of patch-at-heading-and-distance (heading - 20) i + 1 = green
[
ifelse [pcolor] of patch-at-heading-and-distance (heading + 20) i + 1 = green
[
ifelse random 1 = 0
[ rt 30 ]
[ lt 30 ]
]
[ rt 60 ]
]
[lt 60]
]
end
can somebody point what wrong with my code
First of all, consider abandoning the concept of having "leaders" as such. In crowd escape panic situations, they don't stop and hold elections. LOL. I don't know what your model is trying to model, so I have no suggestions here. My model "
Anyway, what your "followers" need to do is integrate to desires, the desire to go the same way as the leader, and the desire to avoid obstacles.
For the first, the follower simply needs a place to remember the "desired" direction. So, rather than set heading directly, you store the heading of the leader./ Then you perhaps use that heading to influence the movement around obstacles.j
For the second, well, obstacle avoidance is a complex discussion on its own. Whatever you have put together, you need to modify it so that it takes the "desired" heading into account, while still effectively avoiding obstacles. This is can be very difficult to do simply.
My model "homing particles 2009" uses one method. This model is designed to explore a particular homing/avoidance behavior. When a particle can't move in the desired direction, it is allowed to move in a limited number of other directions, instead.
Here is the link: http://www.turtlezero.com/models/view.php?model=homing-particles_2009
Unless you have added http://www.turtlezero.com to your list of allowed sites in your Configure Java console (not recommended, but you can trust me, right?), you will not be able to run my models in the browser. I haven't checked what that model needs to run in NetLogo 5.
The ultimate solution to that problem may be to use a path-finding algorithm, like a* (a-star).
In that case you provide your follower with a preferred destination (and that can be vaguely defined as "a point somewhere in 'that' direction"), and the route-planner algorithm plots a route. You can make the route-planner unaware of obstacles until they are "visible" or whatever you define (for example, in a press of bodies, a follower might not be aware of an obstacle until stumbled upon).
Hope this helps!