or anyone who can help. There is something going on with a couple actions I've built in my AutoPosition control that I don't understand.
I have about 8 actions built from from a larger number of frames that position 6 servos. Three servos in each of two robot arms.
I've noticed that at least two of my actions in the AutoPosition control will not start if I call them first thing. I need to call one of the other actions first (which will respond and start up) then the two trouble children will start to work when called. For example, if I start up one of the troubled actions right after start up nothing will happen. Then If I call one of the non-troubled actions they would start and run. Then after this, when I call one of the troubled Actions they will then start and position the servos as expected.
I usually call my actions from a script and place one after the other as needed. However this issue happens even when I start the actions directly from the AutoPosition control. To get around this I have to script one of the non troubled Actions before the problem child just to get it to work.
Any idea why this is happening? I can't see any difference in the way I built the frames to position the servos but I may have missed something. I think I remember something about setting the servospeed when building the frames but I really can't see anything I set improperly. That doesn't mean I didn't screw something up though. LOL. Any help is welcomed.
It sounds like you're experiencing an issue where certain actions in your Auto Position control aren't initiating properly unless another action is triggered first. This behavior can be puzzling, but there are a few areas we can explore to troubleshoot and hopefully resolve the issue.
Initialization of Servos: One common cause for this type of issue is the initialization state of the servos. If the servos aren't properly initialized or if their initial positions aren't set, they might not respond to the first command they receive. Ensure that at the start of your project or before calling the problematic actions, the servos are being initialized. This can be done by creating an initialization action that moves all servos to a known position or by explicitly setting their positions using scripting commands at the beginning of your project.
Servo Speed and Delay: You mentioned something about setting the servo speed. It's worth checking if the servo speed or delay settings for the problematic actions are set in a way that might prevent them from starting immediately. If the servo speed is set too low or if there's an unintended delay configured for those actions, it could cause the behavior you're observing. Try adjusting these settings to see if it makes a difference.
Scripting Conflicts: Since you're calling actions from scripts, ensure there are no conflicts or commands that might interfere with the execution of the problematic actions. This includes checking for any
sleep()
commands that might delay execution or any conditional statements that might not be met initially.Action Dependencies: Consider if the problematic actions depend on the completion or state of other actions or frames. If there's an implicit dependency that's not being met until after another action is run, it could explain why they only work after triggering a different action. Review the frames and actions to ensure there's no unintended dependency.
Debugging with Logs: Utilize the
print()
command in your scripts to log messages before and after calling actions. This can help you verify the flow of execution and whether certain sections of your script are being reached as expected.Hardware Check: Although less likely, it's worth checking the hardware connections and power supply to the servos, ensuring everything is properly connected and that there's sufficient power for all servos to operate simultaneously. A low power supply might cause erratic behavior.
Firmware and ARC Version: Ensure your EZ-B v4 firmware is up to date and that you're using the latest version of ARC. Sometimes, bugs or improvements in newer versions can resolve unexpected behavior.
If after trying these steps the issue persists, consider isolating the problem by creating a simple project with just the problematic actions and testing them in isolation. This can help determine if the issue is with specific actions or frames or if it's influenced by other factors in your project.
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.
Thanks @DJ. I'll review all my servos peed settings again in the AP and see what I have. I thought I did this but I'll look closer this time.
I don't set any servo Speed settings in scripts for the calls I make to the AutoPosition control for animation. I thought I had all the actions set in there to 1. However there are a bunch of times in scripts that I want to move an individual servo and set it's speed from that script.
EDIT: Should I be setting servo speeds in my INT script when I start up the robot? WOuld this help along with setting all the speeds in the AP to -1?
#2 EDIT: I also should mention I have a script inserted inside the action window of the AP that runs when the action runs. All my actions have scripts inserted to run when the action triggers but have no problems with the others, only the two actions I mentioned above.
Speed 1 is slower than speed 0
if you are using different speeds, all the speeds need to be set otherwise -1 will use the last speed. So if the last speed is super super super slow, it won’t be set again.
I also don’t know if speed is the reason. Maybe try removing the script first and see if that makes the Auto Position action work the first time.
Remove things to eliminate any other issues
@Athena
Hey thanks DJ for keeping track of my problem and for your suggestions.
I've seem to have the issue resolved now.
One problem was that I had actually forgotten how to set the servo speeds in the AutoPosition control. It's been a while sense I fooled around in there and I guess I'm kind of rusty. I was using the wrong method to make the changes.
After a little studying and retraining I found I needed to double click on the servo frame listed in the window on the right side of the Action section in the AP control and make the changes there in the pop up window that would appear. I had been trying to make the speed changes in the setting window that sits in the center of the Action section instead. Something that also helped me was that noticed that the description of the frame in that right side window also shows the settings I've assigned to it. Looking through each action's frame settings I saw that most were set to different servo speeds like 1, 0 or -1. I reset each frame's speed to 0 (fastest) and everything is working now.
I'm assuming that the -1 setting were messing thing up but I'm still not quite sure what was causing this issue. I'm thinking that if I don't have a servo speed set foe a certain servo at startup and then assign a -1 speed to it (-1 will use the last speed) nothing will happen because it doesn't have anything to reference.
Anyway, thanks again for the guidance!
It's great to hear that you've resolved the issue with your AutoPosition actions not responding on the first call, Dave! It sounds like revisiting the method for setting servo speeds within the AutoPosition control and ensuring consistency across your frames was key to solving the problem. Your observation about the -1 setting potentially causing issues due to the lack of a reference speed at startup is insightful. Setting all servo speeds to 0 (fastest) as a standard practice can indeed help avoid such inconsistencies and ensure smoother operation of your actions from the get-go.
Remember, the -1 setting for servo speed in AutoPosition actions relies on the previously set speed for that servo. If no speed has been set or if the last speed was extremely slow, it could lead to unexpected behavior. Ensuring that each servo has a defined speed, especially during startup in your initialization script, can provide a more predictable and controlled environment for your robot's movements.
Including scripts within the action window of the AutoPosition control adds another layer of complexity and flexibility to your robot's actions. It's important to keep in mind how these scripts interact with the servo settings and the overall flow of your actions. As you've experienced, troubleshooting by isolating variables, such as temporarily removing the script to test the AutoPosition action, can be an effective strategy for pinpointing the root cause of issues.
Your willingness to dive back into the AutoPosition control settings and refresh your understanding demonstrates the importance of continuous learning and adaptation when working with complex robotic projects. If you encounter further challenges or have more questions, feel free to reach out. The community and I are here to help. Keep up the fantastic work with your robot, and happy building!
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.