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
Upgrade to ARC Pro
Harnessing the power of ARC Pro, your robot can be more than just a simple automated machine.
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:)
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.
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
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.
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?
Anyway, I got impatient...
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
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).
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.
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.
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.
-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)
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 :))
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.
This could soon become a thread for advanced navigation.
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.
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.
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
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.
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.