Hello guys!
Has anyone ever tried to make a line follower using XOD?
I’m trying to make one but I’m having a hard time controlling the engines …
For example, how to give a command to the motor when a first sentence is false and the second is a true, exactly in this order?
thnks
Hello!
I’ve tried and succeeded. XOD is declarative and you’re thinking in imperative mindset. In XOD you don’t give commands to a motor, you define what its speed should be at any particular moment. For example, if you want it to run forward if condition A is false and condition B at the same time, and stop otherwise try this:
Feel free to provide a specific example of what you’ve stumbled upon.
In my case, robot would over-run the line if I ran motors at full speed, so I used if-else to select “max speed”. If any sensor sees the line, then max speed is 0.4; otherwise, max speed is 0. Additional if-else was used to turn off (or slow down) motor on side of robot that could see the line (if right sensor sees the line, turn off the right motor to re-center the line).
If your line-sensor has analog output, then you can use that to control motor speed based on how much of the line you are seeing. If right sensor is starting to see the line, slow down the right motor a little; if right sensor is fully over the line, stop right motor.
Thank you! You really answered my question, but I was not at all clear …
My problem has been the following, I have 4 digital sensors reading false and true information all the time, giving a total of 16 possible combinations of results and for each one of them will be a decision for the engines, because in fact they are two. …
Trying to solve these problems I ventured to have some C ++ commands adapted.
Then I tried the following …
In this format I only have 14 and 15 results.
Am I going down a very bad road?
It’s clunky a bit, but it’s OK. Should work. I don’t understand actually why you’re getting 14 and 15 only. Are you sure the source values (sensor measurements) work correctly?
Another question, what that number denotes? I thought it is something like line position below the sensor array where 0 is the left extreme and 16 is the right extreme, but looking again I’m in doubt. Would you elaborate?
I’m happy for be correct but sad cause i was sure that was wrong😅
In this moment I’m not using the sensor but the constant boolean node, exactly for not have erros.
I think that with the numbers (1 - 16) should be easy control the engines…Something like if i have 1 in output, using equal node, i give a command for the engines, like move foward.
Interesting that you have 4 sensors. Usually there is an odd number of sensors for line-following robot. 4 will work, but might be harder to program.
3 sensors is easiest to program. If either outside sensor sees the line, it is time to adjust to re-center the line. Middle sensor just confirms that you are still on the line & haven’t lost it.
With 4 sensors, you have to decide how you want it to work. If only outside sensor sees the line, you probably want to make a hard turn to re-center the line. If only one inside sensor sees the line, you might want to start a gradual turn. If both inside sensors see the line, go straight.
With 4 sensors, there will be lots of combinations that don’t make sense. You can’t have line under both outside sensors, but not the inside sensors. You can’t have line under ever other sensor. Depending on how sensitive your sensors are, how close together they are and how thick your line is, you probably won’t have 3 sensors seeing the line; you might not even ever have 2 sensors seeing the line (which would make it hard to know when to go straight).
Your code converting the 4 sensors to a byte as if they were binary bits is not “wrong”, but it probably doesn’t help. Most of the numbers are invalid (like 3 sensors seeing the line), and the numbers are kind of meaningless; 1 means there is no line to follow, 2 means the line is to the right, 9 means the line is to the left, 7 means it is in the middle.
There are several options.
In all cases, you probably also want code to stop the robot if all sensors think they see the line. If you are following a black line on white background, lifting the robot will mean that all sensors “see” the line because none of them are getting reflection from white background.
If you are using regular motors (not stepper motors), they will coast when you tell them to stop, so it is very possible to over-run the line (especially if you are trying to go fast), so the robot will no longer see the line. You probably want to stop when this happens so the robot does not just run away.
I thought to use two sensors on center, one in right and one in left for more precision…
Did you think that is necessary? It´s a competition robot and i’m building with my classroom.
I´m a math theacher from Brazil and the students does not have interess in math or progamming, but thanks the XOD i can work programming and diy more easily. For that i´ve insisted to use xod to make a line follower robot for OBR ( Brazilian Robotic Olympiads). It´s only the context…
i thought in the problem of cross… Make a parameter for this problem for example. If the 4 sensors are in the line, probably we have a cross situation.
If it is an option, you might want to go to 5 sensors. That gives you a single, middle, go-straight sensor and 2 sensors on each side to control turning. Even if you install 5 sensors, you might want to program the robot to use 3 to start with. It can be surprisingly difficult to figure out correct logic even for simpler cases, and keeping robot from over-running the line is also difficult (but would be easier with more sensors).
If you are attempting a maze-following robot that can have T or X paths, things become even more complicated. You might want to use 3 center sensors to follow line, and 2 outer sensors to detect side-paths. Extra logic to determine which path to take is way harder than just following a line; I recommend starting with just following the right wall (always turn right when there is the option; make a U-turn when you hit a dead-end). I think competitions usually have a large “blob” of “line” at the end of the maze to indicate success. Robot needs to determine that the “cross” line is too thick, and this must be the end; another complication…
Based on my experience with cheap drive motors trying to follow a line with 3 sensors and obstacle avoidance with range-finder, I don’t think it would be very practical trying to follow a maze with regular motors. It is too hard to determine where you are or how far you have moved without stepper motors. My robot tends to wander side-to-side when trying to go straight after adjusting for speed differences between the 2 motors. How long to run motors to turn 90 degrees will change based on state of battery charge, friction of surface, inertia of robot when you start the turn, etc. (for example, you probably can’t turn 180 degrees by turning 90 degrees twice; you will over-shoot because the robot is already spinning when you call for 2nd 90 degree turn). I’m not saying it can’t be done; it will just be surprisingly hard. Start with enough code to follow a simple curved line so you can see some success before moving on to harder things.
I finded the problem!!!
The declaration of logical parameters was wrong… Now i can do this like the following:
thnks so much!!
Thanks for support me!
I will try with three sensors and dc motors first, cause is the pieces that i have.
If i make it promisse make a video with the result.
If i can not, i come back with more questions ok? haha
Not strictly related to your questions, but you can find a new article about PID controller interesting
