Robot avoiding issue


Hello !

it’s my topic in this forum, nice to meet you all !

i am a newbie with XOD, i tried to made an avoiding robot but there are some issues with that…
My robot is composed of 2 motors and one head (servo + echo). The goal is the next :

He moves alone, when he gets closer to less than 10 cm from an obstacle, he stops, looks to the right, to the left and then decides from the measurements which direction to go

but I stucked on the use of servos with the delay function, the servo had anarchic behavior as if he wanted to go in all directions at once, and this even using a delay function at the end of each movement. I follow this tuto but dosn’t work for me

I managed to unlock myself using the function “servo-pulse” and now my head look lest then center then right, i called this patch “distance”, there are 3 outputs (1 measured for each direction)

Now i want to used this 2 outputs (center isn’t necessary because it’s my first measured which launch “distance” if measurement is less than 10 cm), so i create the first measurement with less (lauch “distance”) and greater (go straight) but there is a big issue here…In first time, i just want to use 1 motor (M3) and put -1 (left choice), 0(center choice) or +1 (left choice). my servo react like if all function run together…I know there is an error in select for X2 but i don’t know how to fix it…

Can u help me please ?
-I don’t understund why “delay” dosn’t work with me (i tried for test to write on LCD something at 2, 4 and 6 s but nothing work too
-I Don’t know how to use a motor with multiple choice incoming (more than 2)

  • I think i have a big problem with the temporisation of my code…

Thx a lot !!!



First issue is that the range finder node at the top of your patch is always firing, so it continues to fire while your distance node is trying to do its calculations. The range finder requires time to ping and wait for echo and additional time to settle after getting a reading, so continuous polling is likely to mess up your distance node, and it is likely to see >10cm while distance node is looking left/right, but it will assume it is distance center.

Another issue you are going to run into is that you will need to engage motor for a set time to turn your robot. To resolve both of these issues, you are going to have to use pulses to control program flow. To understand how to do that, start with the traffic light tutorial here: The library gweimer/traffic-light-advanced takes the concept to the next level, which you will need for your robot. Your distance node is already using this concept, but your main patch is also going to need it.



Please share your main patch screen shot. this one is for servo.



Thx for replies !

I go look in first time and i come back if there is any problem :slight_smile:



Just one question about motor

i tried this

When i don’t use “motor”, the loop work well, and there is 1 or 0 displayed on the screen, but when i connect the output number of “select” to the motor, my loop blocked and “go straight” is used only 1 time… as the motor never let the delay go to done. Do u know why ? thank you :slight_smile:

Edit : i delete the IEC and now it’s working… i don’t know why, it’s an calcul power issue ? i have an arduino UNO



What is IEC that you deleted?



sorry i wanted to say the LCD i2c, I totally mixed everything.

Ok, now my robot is working thx to your example !

I am proud of this :), it’s pretty clean, isn’t it ? (yeah it’s a newbie work but, i am proud :D)
So… there is a last issue … when I test the robot in the air without touching the ground, everithing is ok, robot wants to turn in the good direction, he stop etc… but when i put it on the floor,
he’s starting to do anything -_-. i don’t know if it’s an power issue (i have 4 batteries AA, a also add and 9 V but dosn’t fix it) as robot forced to put 1 to motor, or an issue with the echo soncar…

Have you ever had this problem ?

the next step being to make a humanity Savior Mecha, I have to sort out this power problem lol




If it works in air, but not on ground, that would imply a power limitation problem. What voltage are the motors rated for? Are the AA batteries connected to the motor controller, or to arduino with motor controller pulling power from there? They probably need to connect directly to motor controller with arduino getting power from motor controller or separate battery.

The code looks good. I only saw a couple things I would have done differently.

Why does Look have a delay node instead of connecting OUT to Look center-Done pin? If Mesure isn’t stable doing that, you can add defer before OUT. Using delay means you have to calculate what delay should be, or experiment to find appropriate value, and you are either waiting longer than necessary, or risk having code continue before calculations are done.

The next change is a little more involved. It is not really a “fix”, just a trick to reduce amount of code needed. Rather than modif-trajectory with go-left/go-right, I would probably feed look-Mesure to a generic turn node that looks something like:


If DIR is 1, the multiply nodes just pass the 1, -1 values. If DIR is -1, the multiply nodes swap the values to turn the other direction. You might even change the name of DIR pin to RIGHT so that 1 is basically true & -1 is “false”…turn left not right. You would want to add comments about DIR (or RIGHT) needing to be 1 or -1 since “false” is usually 0, not -1 and 1, -1 is not obvious for direction. You could also change DIR (or RIGHT) to be a boolean so it is more “standard” and add an if-else node to calculate multiplier instead of passing in 1, -1, which can simplify your “look” node since you would only need one compare and wouldn’t need the “select” node.

The next issue doesn’t make much difference in this code, but could be HUGE in some cases. In your check and look nodes, you have less and greater nodes. What happens if it is exactly equal (not likely with floating number, but possible)? There is also the issue that the compare value (0.1 in this case) is duplicated…you need to change both if you decide to try other values. One way to avoid both these issues is to replace the greater node with a “not” node that gets its input from the less node. You always want one or the other to be true. Having 2 compares makes it possible that both or neither might be true (especially if you change the value for one compare and forget to change the other). Using one compare and “not” means that exactly one will always be true; there is only one place to make changes if they are needed; and it is less calculating for the arduino to perform, so should be slightly faster.

The last issue is similar to the previous one. You can replace the two pass-if nodes with a single branch node. Besides reducing node count (and risk of activating both or neither path), it makes it more clear what you are doing since you aren’t even using the passed value in this case, and you are using them to create a branch in your code (choosing one of multiple possible actions).

Looking back, it seems like I’m being very critical of your code, but as I said at the beginning, your code looks good. These are more “based on my experience, I would do it this way” comments than “you did it wrong, you should fix it” comments. To be honest, your main patch is a LOT simpler than what I came up with writing the same program to teach a class with (though some of that simplicity is because you hid the “move forward” code in the “check” node). The main difference in functionality is that my version has a couple ways to stop the robot so it doesn’t run forever (stop if there is obstacle in front of us on startup or after turning).

1 Like


Ohhhhh first thank for this helpful help !!!
So :slight_smile:

The motor control shield is connected to 4 AA batteries. Like i said, i tried to connect in addition a 9 V battery to the arduino but dosn’t work.

Thanks for the delay node explication, I fix it :slight_smile: in first I changed with removing delay and connect Look center to Out but it dosn’t worked, i add and “defer” and now it’s working I don’t know why,.

Ohhhh, it’s really smart to use multiply, I did not even think about it.

I have an issue with the “not” node… I tried like this by removing “greater” node but the program acts as if the STOP loop was the only solution, there is something wrong in my way to use “not” ?

Don’t worry, it’s really rewarding to have corrections and explanations from someone with a lot of experience. yes indeed, I tried at first to make the cleanest and SIMPLE code to see where I was going to make mistakes.



The not node only replaces the greater node. You still need the pass-if nodes (or replace them with branch node)



Adding defer node before OUT allows other calculations to finish before value on other output pin gets used by next node.

1 Like


Hello !
sorry to have not answered earlier, I have not retouched at XOD since.
So, it’s working with 9V + 4 AA, i will test him in order to see all improvments it needed.

The first things i saw it’s sometime, there is “modif-traj” and “look” that are working in the same time (when robot is in corner). I will try to fix it :slight_smile:

Thx Gweimer