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).
