Is there an outside area for script in ARC that can keep an eye on Blockly and override it if necessary, rather than writing it in each Blockly script to avoid a certain scenario which amounts to a crash of the end effector. Hypothetical scenario: Swing the base of the robot 180 degrees but if the second arm is extended it will hit an obstruction at 130 degrees of rotation. If there were outside rules that could be stated beforehand in another overriding script or function it could make the proper adjustments on the fly to avoid the crash. The other script might say something like this: If the base is going towards 130 degrees lower the arm to 20% and after it gets past 150 degrees raise it back up to the original 80% extended. Any suggestions?
Asked
— Edited
Related Hardware EZ-B v4
Related Control
Script
In ARC, you can create a global script that monitors the state of your robot and takes action when certain conditions are met. This script can run in the background and act as a safety or override system for your Blockly scripts. To achieve this, you can use the Script skill to write an EZ-Script that continuously checks the position of your robot's base and arm and adjusts the arm's position if necessary.
Here's a hypothetical example of how you might set up such a script:
Add a new Script skill to your ARC project (Project -> Add Skill -> Scripting -> Script).
In the script editor, write a script that runs in a loop and monitors the base and arm positions. Use global variables to track the state of the robot's movements.
Save the script and start it. This script will now run in the background and continuously monitor the positions of the base and arm.
In your Blockly scripts, you can continue to command the robot as usual. The background script will take care of adjusting the arm's position when the base rotates towards the obstruction angle.
Remember to replace
D0
andD1
with the actual servo ports you are using for the base and arm, respectively. Also, adjust the servo positions (20 and 80 in the example) to match the safe positions for your robot's arm.By using this approach, you can create a centralized monitoring system within your ARC project that acts independently of your Blockly scripts, providing an additional layer of safety and control.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
@Athena great answer and was what I was thinking, just didn't know how to do it. Thanks
You're welcome! I'm glad the information was helpful. If you have any more questions or need further assistance as you work on your project, feel free to reach out. Good luck with your robot, and have fun building and programming!
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
@Athena I see a bit of a conflict in your previous script when you have 2 scripts running at the same time. The first script will tell it to go to a position and then the oversee script will tell it to lower down which repeats at an interval of 100 ms. In the meantime for the other 99 ms the first script is still telling it to go to the original location. Is there a way to put a hierarchy on the scripts which would let the oversee script take over. Also when returning back to the intended location wouldn't that need to be put into a variable or remembered so it knows where to go. Could this be done with a -1 or a 0 in Blockly whereas it allows it to go to that position and the oversee script doesn't step in to override it. Can you explain in detail about these scenarios.
You're correct that there could be a conflict if two scripts are trying to control the same servo simultaneously. To resolve this, you can use global variables as flags to indicate when the override should take control and when it should release control back to the main script.
Here's a more detailed approach to implementing a hierarchy and memory for the intended position:
$overrideActive
flag before sending a move command. If the override is active, update the$intendedArmPosition
variable instead of moving the arm directly.$overrideActive
flag to control this behavior. If you set$overrideActive
totrue
, the overseeing script will not attempt to override the arm position. You can then set it back tofalse
when you want the overseeing script to resume its protective behavior.By using this approach, you create a system where the overseeing script only takes control when necessary and remembers where the arm was supposed to go. Once the condition that triggered the override is cleared, the arm can return to its intended position. This method ensures that your scripts cooperate rather than conflict with each other.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.