Robot Basic
USA
Asked
— Edited
Resolved by Steve G!
I am new to EZ script, but I have read through all the docs and many examples and things seems to work as expected. However, when I try to access data (such as an ADC reading) from the EZ computer, it is VERY slow (taking 80ms or so). Sending data (such as servo positions) is reasonably fast, but it appears that if I want to obtain anything FROM the computer then everything bogs down.
My question: Is this delay what is to be expected or is there something I need to do to increase the throughput? Any information would be appreciated.
Thanks. John
http://www.ebay.com/sch/sis.html?_nkw=5pcs+PRO+MINI+ATMEGA328+5V%2F16M+MWC+avr328P+Development+Board+for+Arduino&_id=271357213632&&_trksid=p2057872.m2749.l2658
I appreciate all the help from everyone. My project is a walking humanoid (made from EZ servos) that actually balances rather than just moving through a series of frames. I can perform the operations on other computers but wanted to utilize the EZ-b if I could - unfortunately, the communication protocol time is just too slow (I tested by performed a series of ADC operations in a loop - if 10 operations takes 800 ms then each takes 80 ms. Sure, there is the overhead of the loop etc., but obviously I need to acquire data much faster than is possible with the EZ-b. That is really too bad as I love many things about the EZ paradigm (it is somewhat similar to the RobotBASIC-RROS operation). Since the actual time needed for internet communication is small compared to the delays I've measured, my best guess is that EZ could benefit from a better protocol. It would be fun to design something appropriate for applications needing improved performance, but that is a whole project on its own. Thanks again for all the help from EVERYONE. John
I will post back with how I eventually create my balancing EZ humanoid. Thanks again
Unfortunately not released yet, but the Inverted Pendulum in the EZ-Robot store communicates via I2C. I believe it is faster than the UARTS.
It, or in combination with the 4-in-1 orientation sensor (also I2C) should meet your needs.
Alan
Thanks Alan - but I don't think the problem is the time needed to read the sensor - it appears that the EZ-b takes much to long to respond to ANY request for data.
The EZ-B can process it plenty fast enough. What is happening is that you are flooding your wifi network with traffic if you are hitting 8 sensors repeatedly. This is the reason for the delay in the software.
To overcome this delay, you would need to take this load off of the network. This is the reason for the recommendation to use the arduino mini for this processing and have it report back to the EZ-B when there is a threshold exceeded. This will free up your wifi network to handle traffic much faster. You aren't pushing the capabilities of the EZ-B, but of your network. It is the weak link in the chain.
robot basic, what you are doing is referred to as PID Loop. To better understand how humanoids, such as Honda Asimo, etc work - i will explain a little here.
The EZ-B v4 is a master controller. Other slave controllers connect to it and receive communication. In your case, monitoring the position of servos would be done on a micro controller in a PID Loop (i.e. Arduino, Microchip Pic, ARM, etc). The PID Loop on the slave micro would receive commands from the EZ-B v4. The EZ-B v4 is a master controller which slave controllers would connect to. This is referred as distributed processing - and is a way to easily enable additional functionality and expand-ability.
Picture your PID Loop on the PID Controller for making the humanoid walk as a single process - and that's all it does. Use an Arduino, which is an easy programming environment with lots of community to assist. On the Arduino, create your PID Loop which makes the robot walk forward, left, right, reverse, etc... And have the PID Loop listen for commands from the EZ-B v4 of what action it should be executing.
Also, to assist in making the frames for the movement, check the ARC Auto Positioner, which can export code for you. The Auto Positioner will create an entire GAIT loop in code, which you can add to the Arduino. See this video for how to generate code...
Once the code is generated, you can create a PID loop on the Arduino which will monitor the accelerometer/gyro and adjust the servo positions respectively.
Think of it as your computer. There is a reason the CPU also does not contain RAM and ROM. The CPU in this case would be the EZ-B v4, and all the peripherals connect to it.
Additionally, the ARC software would be the complete master which enables peripherals to be added to the PC/Mobile Device.
As for the speed of requesting port data, this may be wifi interference. If you are a programmer and somewhat technically included, i would recommend googling how to use a WiFi scanner. The speed of obtaining ADC port data is much quicker than 80ms, unless you have WiFi interference, slow computer or lots of network saturation. Remember, programming for an EZ-B v4 is not like programming a micro controller - they're not the same thing. This is why the EZ-B v4 is not a micro controller.
d.cochran said:
Yes, that's what I was thinking. That's why I asked what method was used to arrive at the 80ms figure. You're running into the uncertainty principle in that your measurement procedure is seriously affecting your results.That being said, since you will need many readings per second to do what you want to, I also agree a separate processor is the only reasonable way to go. In fact if you are going that far, perhaps it would be good to place everything on the Arduino, or whatever is used, and do the sensor measuring external to the EZ-B as well. Then just have the Arduino setup send only servo commands to the EZ-B via one of the serial communications ports. Leave the PC out of it entirely as far as the balancing operation goes as well. All balancing done on the robot as an autonomous function. Though I'm not sure how the signals from the Arduino might mesh with the signals coming from the PC.