elfege
USA
Asked
— Edited
Has anyone figured out way to get the goto() function to work with variable so it can goto the last defined loop such as this :
$lastLoop = ""
:loop1
$last = "loop1"
left(200, 0)
sleep(100)
print($last)
goto($last)
this would allow to have the equivalent to calling a function and resuming the current loop after its execution. It would prevent me from using too many scripts and avoid lots of redundancies. My project currently has 50 scripts so I'm trying to find a way to shrink this number. 
@RichardR I found this site by doing a search after purchasing a Walmart R2D2 shell. I have sense purchased the developers kit and made numerous trips to Radio Shack. While Building, I managed to lose the camera cable so I am waiting for a replacement on that. I will post pictures and video soon to the Robot Showcase.
@elfege: Sorry to hijack your thread
@DJ:
Thanks for explaining the hardware layers, Q1 i'm assuming the communication between ARC and the EZB is only one way, there are no callbacks right ?
When a servo command is sent with a specific speed/pos, there is no way no know if the servo is still moving or not, Q2 it's not possible to implement a firmware call (plus a script command) to obtain (polling) the servo status per port e.g. (no servo, attached, moving, detached, etc?)
That could help to avoid sending a release while the servo is still running. There a thread discussing the issue.
Q3 It's feasible to expect firmware updates for the existing boards (EZB4) ?
Alan
@PTP...No Information to the ezb is 2 way... Pings for instance send their data back to ARC. Hobby servos are one way communication only, however... Their internal pot is used by the servo's control board to control servo position. This information does not go back upstream....However you can hack any servo and run a wire from the pot to an analog port which would them provide the controller ( the ezb in this case) position feedback.... There are servo's like Dynamixels that provide position feedback to the controller. ...
i m on the phone but not driving
@alan:
I know the difference between a servo with feedback and no feedback. I also know the servo does not have speed control so the speed control is done by software my guess is firmware so the ARC sends a command like goto position x with speed y the firmware accepts the cmd and behind the scenes is looping from current position to position y with a specific speed, while doing that ARC/scripting does not know where the servo is (position) because there is no call back from the firmware to the ARC
So my question is why not implement a firmware call to ask the current servo status that away is 100% clean knowing where the firmware is doing
@richard what i mean only one away is the ARC call the eZb and not the other away arround.
For example i dont think the firmware (ezb) will notify the ARC when something is done but is a guess (otherwise you need to open tcp ports on your windows and all the support issues related to that)
So i know you can query a ping, poll image etc but the communication starts and ends in the ez side
Unless there is always a connect connection initiated by the ARC and the firmware uses that channel to send notifications
DJ knows for sure i m only guessing.
DJ, your a code god! You all can hijack any thread of mine at any time if it's as useful as this.
So, as far as threading, will my robot project running on ARC take advantage of multiple cpu cores? if I have a large project with many controls, loops ,audio streaming and adc checking going on will more than two cores help? I do understand that there are other things happening also to control the traffic (thanks to DJ's amazing discription). However in supported os are extra cores used?
Also, it sounds like it's better to have many controls called from one script for different functions then having one script handling them by it's self?
Ptp, there is no fredback from a servo, which had been repeated. Please read the how a servo works tutorial. Herr is a direct link for your convenience: https://synthiam.com/Tutorials/Lesson/48?courseId=6
Callbacks cannot work for a servo. Callbacks only work for specific commands, such as repeated in this thread. Also, your definition of a callback is performance limiting.
I explained in detail, but I'm time constrained to provide additional education on this topic. What I can recommend is to research binary communication protocols, not Ajax html JavaScript json programmer-friendly webservice approaches. I'm not certain if you truly understand how quickly the ezb is doing things, including audio, video and servos... This is an effecient binary communication protocol. The communication does not initiate with the ezb. The connect button on ARC is a dead giveaway, and the fact the ezb doesn't know where your ARC instance even is. You do not open tcp ports on the the Windows machine because there's already an established tcp connection.
groundwork research is a good place to start - specifically regarding the servo question.