Well, I've run your code on the robot movements have changed panel by panel h-bridge servo movements for my robot, assigned the servos and sensor ports, set some variables as $ maxDistance = 15 to work closer walls. I have also changed sleep (750) for sleep (250) to increase the scanning speed servo. The code works great! Anyone can use simple adjusting various parameters. I will post a video of my robot running your code pair delight. You did a great job, sure when you try it on your robot will still modifying code to refine details. Also is an open platform for experienced or continue adding lines of code. (Video later)

Funny you should mention refining the code, I was about to take a look at that. There are bits of code that are a little sloppy and messy which I want to fix, re-organise the configuration variables at the start to make it easier for others to use, remove the testing code and flags and adjust the sleep delays (as I needed them slow for my eyes to keep up with the code when testing).

I also have other ideas of how to add to the script too, using different turn rates depending on sweep position and ping distance. Using a different Movement Panel to go around the object rather than just turning... Lot's of additions can be made and everyone is welcome to make them

Great news that it works on a robot though.

Also I have some ideas to share, it would be great to integrate them into your code, for example: -Idea 1: Balance of distances (very useful for hallways and rooms): The robot moves forward while the sensor takes distances left and right lateral distances sum to set the width of the corridor, based on the total width divides it by half tries and knowing this side measurements are the same and making small course corrections to circulate through the center of the hall. This process is constantly repeated to recalculate the total width of the passageway at all times. -Idea 2: dead end, sometimes the robot is at a dead end and try to exit from the front or left or right but it does not, if the rotation time set to "$ turnamount" is very high, has more success to exit, but a high number causes your browsing more vague, more degrees running turns and prone to navigation in zic-zac or waveform. To retain more precision in navegcion and retain a $ turnamount small figure, it would be interesting to read a script: If you've tried out the alley for two attempts and still can not go forward, then turn 180 degrees. They are ideas in the search for a combination of integrated solutions. (video almost ready)

All very achievable with a little thought.

The script as it stands is the backbone of a much more complex script. Once I've built the test robot this weekend (my new EZB has been delivered!) I can test it out with trial and error, set up some test courses for it to travel down etc.

Mapping with the sweep servo position and storing the values as variables, running some simple maths to work out how far from the centre line of the corridor and adjusting the speed of the one side of the drive wheels to level up is one way to achieve it. So rather than stopping, turning, moving, turning and continuing it can move forwards but veer off to the one side (imagine if left hand drive wheel moves slower than the right hand, it'll ARC around to the left slightly)

A lot more thought needs to be put in to it to work out what needs to happen but then it's just a case of adding in the right bits of code in the right places.

Dead end escape I have a different idea from what I've already seen. If we base it on the current code, it will detect an object dead centre in a dead end situation, it'll check left and right positions and turn appropriately. Now, after this we need to add in some code that if it instantly detects an object again then to slowly turn in the direction it last turned in, waiting for the ping to be over a certain amount indicating an escape is possible by driving forwards.

Reason I said to waituntil is because 180 degree rotation is not accurate when using time based movement commands. But waiting until the path ahead is clear ensures escape without error.

Just a few ideas floating around in my head, I have many more (some of which may not work, some may work, trial and error again will prove which ideas fall in to which categories)

Video ready, at twice the rate of reproduction

That's great. It gets a little stuck in a couple of places but then I guessed it would since there is no "boxed in" escape routine (yet).

I can't wait to get home and build the shoebox bot for testing this out so it can be expanded on I know Ultra Sonic isn't great in my house so I expect to almost immediately add in code for a Sharp IR sensor too.

I'm eager to see the result of your evidence; robot and shoebox. This could soon become a thread for advanced navigation.

Shoebox was too big... box my LiPo battery come in, perfect size

Although I'm not happy with it using 4 modified servos to drive it, it works but it isn't great.

A sneek peek at the test bot

Needs batteries though and it's not anywhere near up to my standards even for a test bot... but it works.