Welcome to Synthiam!

Program robots using technologies created from industry experts. ARC is our free-to-use robot programming software that makes features like vision recognition, navigation and artificial intelligence easy.

Get Started
Spain
Asked — Edited

Script Manager And Script Pauseon

You can pause a script and then unpause?
I'm trying to run my personal radar control and I have a script that moves the servo ping sensor, but I would like to pause the movement when turning to avoid obstacle and then unpause to move forward.
I have proven this if successful:
CC ("Script Manager" ScriptPauseOn, "radar")
Not if it is misspelled or does not exist the command "PauseOn" for Script Manager
I have also proven with the command PauseMS but seems not to work.
Thanks in advance for your answers:)

Spain
#25  
I've inserted the 250-ms sleeps under each line and it worked fine, now the servo moves sweep across his rrecorrido and does it well.
The trouble is that when it detects a ojeto turns and stops, and only corrected to the left, then sweep the servo stops moving, and forward and goto function from an external script (which we discussed earlier) enters a loop and voids the rest of your code.
The good thing is that every time we are closer, sure with the ez-b in their hands will see everything more clearly, seeing what he did without being able to experience it physically:)
Spain
#26  
Incidentally this is your code with my servo ports assigned and added the "sleep (250)":RADAR.EZB
United Kingdom
#27  
I will put together a test rig and check it out. I may even add the ping sensor and servo to my hearoid (since I need to anyway) if I get time tonight. If not I'll work on it over the weekend with a test rig.
United Kingdom
#28  
Right, just having a good ol' look at this now for the next 20 minutes or so (10 now). I've set it up with the floor map so I can see a virtual robot moving. I've slightly edited the code so the ping is a random number to save me needing to connect an EZB up.

It works fine, and then it stops. Currently I have only a rough idea of where it goes wrong but why it goes wrong I need to find. Basically you'll probably find that it moves around OK and then it will suddenly stop sweeping the servo.

So that's where I'm going to start looking.

Also, the updated code with the sleep fixed (it was in there but only 50ms so hardly counted) and forward commands added in. More of a roaming script than a detection script now:)

And I found the problem is in the code for detection direct ahead, it throws off the sweep code. I'll delve in to that better later on but have to be out in 10 minutes so it'll wait.

Here is the code all changed, it has some extra "testing" variables and options in it, I'll leave them there so you can see how I went about finding the problem. I'll explain it all later when I have time.

Code:


# Ping Object Avoidance
# Using Ultra Sonic Ping Sensor on servo for avoidance

# Adjust values below for configuration
$pingport = D0 # Change for Ping Port
$echoport = D1 # Change for Echo Port
$maxdistance = 75 # Change for maximum distance from object before avoiding in units
$onlyforward = 1 # Only if moving forwards? 0 = no, 1 = yes
$reverseturn = 0 # Reverse before turn? 0 = no, 1 = yes
$turnamount = 500 # Change for how long to turn for in ms
$reverseamount = 500 # Change for how long to reverse for in ms (if applicable)
$movementspeed = 255 # Change for movement speed

# Sweep variables
$sweepmin = 25 # Change for min limit
$sweepmax = 77 # Change for max limit
$sweepcenter = 52 # Change for center position
$sweepservo = "D3" # Change for servo port
$sweepprevious = $sweepmax # Do not change
$sweepcurrent = $sweepcenter # Do not change

# Testing Options
$testmode = 1 # Change to 1 if testing without PING sensor
$SweepErrorFlag = 0 # Do not change

# -- The Script --
Servo($sweepservo, $sweepcenter)
FORWARD()
GOTO(sweep)

# Check if only to detect when moving forwards
:detect
IF ($onlyforward = 1)
IF ($Direction = "Forward")
GOTO (detectstart)
ELSE
GOTO (detect)
ENDIF
ELSE
:detectstart
IF($testmode=0)
$currentdistance = GetPing($pingport, $echoport)
ELSE
$currentdistance = GetRandom(0,255)
ENDIF
IF ($currentdistance <= $maxdistance)
GOTO(avoid)
ENDIF

# Sweep the servo to the next position
GOTO(sweep)

SLEEP (750)
GOTO(detect)
ENDIF

# The avoidance script
:avoid
IF ($reverseturn = 1)
Reverse($movementspeed,$reverseamount)
ENDIF
IF($sweepcurrent = $sweepmin)
RIGHT($movementspeed,$turnamount)
FORWARD()
ELSE
LEFT($movementspeed,$turnamount)
FORWARD()
ENDIF
RETURN()

# The sweep script
:sweep
# Get the current position
$sweepcurrent = GetServo($sweepservo)

# Move in the correct direction and store previous position
IF($sweepcurrent = $sweepmin)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepcenter)
ELSEIF($sweepcurrent = $sweepcenter and $sweepprevious = $sweepmin)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepmax)
ELSEIF($sweepcurrent = $sweepcenter and $sweepprevious = $sweepmax)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepmin)
ELSEIF($sweepcurrent = $sweepmax)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepcenter)
ELSE
$SweepErrorFlag = 1
SLEEP(10000)
ENDIF

# Return back to the main script
Return()


Also, see the attached ezb file (merge it to import the script in to your current project)pingroam.EZB

NOTE: Testing mode is set to on. Change the variable at the start for testing to 0 if you want to test with an actual PING sensor
United Kingdom
#29  
A quick video of it working away...


It doesn't check left and right after detection in the centre position yet as I think that's where another bug lies and I want to sort that part with an actual sensor fitted to a moving robot. My new EZB should be turning up tomorrow (should have been today, why was I out?!) so I can do that tomorrow evening:)

Although feel free to attempt it yourself, hopefully you are gaining some knowledge in scripting through this topic.
Spain
#30  
The truth is that I'm learning about scripts with this topic, I realize that the best way is to type it and practice. Also I have also learned a lot by practicing on the mobile platform in a practical, write and test.
I have seen reactions "ghostly" so to speak, of the robot reactions that had nothing to do with the program, and course corrections when the sensor did not detect anything, and stuff. And as changing a parameter, others are modified unintentionally is something mysterious, but certainly has a logic I do not understand yet.
By the way, do not understand how you run the program without ultrasonic sensor readings. Include random numbers to simulate sensor readings?
United Kingdom
#31  
Yes, random numbers, so the actual floor map is a bit unrealistic but it runs though and tests the if statements, sometimes meeting the requirements to run the commands other times it doesn't.

Anyway, I got impatient...

Code:


# Ping Object Avoidance
# Using Ultra Sonic Ping Sensor on servo for avoidance

# Adjust values below for configuration
$pingport = D0 # Change for Ping Port
$echoport = D1 # Change for Echo Port
$maxdistance = 75 # Change for maximum distance from object before avoiding in units
$onlyforward = 1 # Only if moving forwards? 0 = no, 1 = yes
$reverseturn = 0 # Reverse before turn? 0 = no, 1 = yes
$turnamount = 500 # Change for how long to turn for in ms
$reverseamount = 500 # Change for how long to reverse for in ms (if applicable)
$movementspeed = 255 # Change for movement speed

# Sweep variables
$sweepmin = 25 # Change for min limit
$sweepmax = 77 # Change for max limit
$sweepcenter = 52 # Change for center position
$sweepservo = "D3" # Change for servo port
$sweepprevious = $sweepmax # Do not change
$sweepcurrent = $sweepcenter # Do not change

# Testing Options
$testmode = 0 # Change to 1 if testing without PING sensor
$SweepErrorFlag = 0 # Do not change

# -- The Script --
Servo($sweepservo, $sweepcenter)
FORWARD()
GOTO(sweep)

# Check if only to detect when moving forwards
:detect
IF ($onlyforward = 1)
IF ($Direction = "Forward")
GOTO (detectstart)
ELSE
GOTO (detect)
ENDIF
ELSE
:detectstart
IF ($testmode=0)
$currentdistance = GetPing($pingport, $echoport)
ELSE
$currentdistance = GetRandom(0,255)
ENDIF
IF ($currentdistance <= $maxdistance)
GOTO(avoid)
ENDIF

# Sweep the servo to the next position
GOTO(sweep)

SLEEP (750)
GOTO(detect)
ENDIF

# The avoidance script
:avoid
IF ($reverseturn = 1)
Reverse($movementspeed,$reverseamount)
ENDIF
IF ($sweepcurrent = $sweepmin)
RIGHT($movementspeed,$turnamount)
FORWARD()
ELSEIF ($sweepcurrent = $sweepmax)
LEFT($movementspeed,$turnamount)
FORWARD()
ELSE
Goto(sweepcenter)
ENDIF
RETURN()

# The sweep script
:sweep
# Move in the correct direction and store previous position
IF ($sweepcurrent = $sweepmin)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepcenter)
$sweepcurrent = GetServo($sweepservo)
ELSEIF ($sweepcurrent = $sweepcenter and $sweepprevious = $sweepmin)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepmax)
$sweepcurrent = GetServo($sweepservo)
ELSEIF ($sweepcurrent = $sweepcenter and $sweepprevious = $sweepmax)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepmin)
$sweepcurrent = GetServo($sweepservo)
ELSEIF ($sweepcurrent = $sweepmax)
$sweepprevious = $sweepcurrent
Servo($sweepservo, $sweepcenter)
$sweepcurrent = GetServo($sweepservo)
ELSE
$SweepErrorFlag = 1
SLEEP(10000)
ENDIF
# Return back to the main script
Return()

:sweepcenter
$SweepCenterFlag = 1
Servo($sweepservo,$sweepmin)
IF ($testmode=0)
$pingmin = GetPing($pingport, $echoport)
ELSE
$pingmin = GetRandom(0,255)
ENDIF
Sleep(400)
Servo($sweepservo,$sweepmax)
IF ($testmode=0)
$pingmax = GetPing($pingport, $echoport)
ELSE
$pingmax = GetRandom(0,255)
ENDIF
Sleep(400)
Servo($sweepservo,$sweepcenter)
IF ($pingmin > $pingmax)
RIGHT($movementspeed,$turnamount)
FORWARD()
ELSE
LEFT($movementspeed,$turnamount)
FORWARD()
ENDIF
Return()


I had to move a few things around, mainly concerning the previous and current position variables. The way I had them didn't work correctly (although I haven't figured out why, as far as I can see they should have but I am probably missing something obvious).
Then I needed to add in the forward commands missed out of the sweepcenter sub routine and also add in the testing code for using a random number rather than the GetPing in the sweepcenter sub routine.

But it all seems to be working well now... I left it running the test while I went for a shower and it was still working when I got out:)

pingroam.EZB

Some of the code could be tidied up a little and the sweepcenter routine could be moved in to the IF statement rather than using a goto since it is the only place it's called from.

We got there in the end though. Although totally untested with a ping sensor so the direction may be backwards or it may trigger when far away from an object rather than close to one - I'm unsure which way around the ping sensor reports the value. Easy fix if it is wrong though, it's just a case of changing a couple of ifs.

I have a video of it running too but the screen recorder decided it doesn't like encoding or compressing so it is 9.3Gb for only a few minutes... So I wont be posting that tonight (although it is uploading to youtube as I type this so maybe I will).

Edit: Video

United Kingdom
#32  
Since I have a few minutes to spare at the moment some quick notes on how I went about testing the script without connecting to an EZB or any sensors.

To emulate the sweep servo was pretty simple. Adding a control for a horizontal servo and setting it to the sweep servo port number will visually display the servo position within the control. This allowed me to be able to see that it was sweeping correctly.

Adding a movement control panel allowed visual indication of the direction in which the robot was moving.

Adding the floor map was just another indication of the robot moving however it was not required.

Replacing the GetPing for GetRandom supplied random numbers for the sensor data allowing random checking of the conditions in the IF statements.

The Variable Watcher control is also a very important tool. It allows to keep an eye on the variables so I could see what was changing. Also with the error flag variables it would indicate when the script had failed to perform the if conditions correctly. Adding a long sleep command after the flag change also helped indicate when the problem occurred.

And finally, in the script dialogue pressing the run button will show the debug information to the right which can be read through to check it is functioning correctly, where it runs astray or where there are problems.

However, that said, nothing beats checking scripts on an EZB with an actual robot.


To fix the script from the initial buggy code was a case of breaking it down section by section and finding where the script was going wrong, checking the code and adjusting it to suit.

As this shows I am still learning and often have bugs in code. Don't be disheartened if you have buggy code to begin with, we all do:) Trial and error will prevail.
Spain
#33  
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):) :) :)
United Kingdom
#34  
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.
Spain
#35  
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):)
United Kingdom
#36  
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 :))
Spain
#37  
Video ready, at twice the rate of reproduction:)

United Kingdom
#38  
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.
Spain
#39  
I'm eager to see the result of your evidence; robot and shoebox.
This could soon become a thread for advanced navigation.:)
United Kingdom
#40  
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
User-inserted image


Needs batteries though and it's not anywhere near up to my standards even for a test bot... but it works.
Spain
#41  
Cool, ultra portable robot. Batteries and me neither friends since we discovered lipo batteries a few years ago, but for a vehicle of evidence; aceptaria even duct tape:)
United Kingdom
#42  
The whole thing is put together and secured by tape:)

I could fit a 5000mAh LiPo in the white box (one come in the white box) but I don't want to use a LiPo on this as I always worry about them going under voltage.

The 6xAA battery holder fits on the back nicely or under the EZB, so I'll be using that. Also, the camera has now been added too. I'll do a project showcase for it when it's all done and looking pretty and stuff.
Australia
#43  
Hi Rich,
I use Lipo on my robot, Hobby king sell an under voltage alarm for use with electrical planes. This has a warning LED when its getting low and then a Pizo alarm when it hits rock bottom for the cell. $3.49 US
http://www.hobbyking.com/hobbyking/store/__7226__hobby_king_battery_monitor_5s.html

You could take the signal to the pizo and piggy back an alarm to the EZB or alternatively hard wire a master power relay so this alarm will cut power to the entire bot. The alarm connects to the cell monitoring port not the Battery cables them selves so it monitors one of the individual cells for the min voltage.

regards
ghost
United Kingdom
#44  
Just made a new post with a new idea in it:)

Hopefully it'll work.

P.S. I have one of those alarms but I've already had to split my balance port to 2 (1 for charger and 1 for monitor), I'm reluctant to split it to three.