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
Upgrade to ARC Pro
Experience early access to the latest features and updates. You'll have everything that is needed to unleash your robot's potential.
Related Content
Synthiam
Based on your post activity, we found some content that may be interesting to you. Explore these other
tutorials and community conversations.
have a question. How do you know it's taking 80 ms to do a read? What techniques are you using to arrive at that figure?
The EZ-B can interface with an arduino over the serial port. The arduino can be monitoring these sensors and report back to the EZB if there is a threshold exceeded on these sensors. The arduino can pound these sensors without causing issues on your network. Arduino mini pro's can be picked up for about $2 on EBay.
http://www.banggood.com/Arduino-Compatible-DUE-R3-32-Bit-ARM-With-USB-Cable-p-906466.html.
John
Thanks again
It, or in combination with the 4-in-1 orientation sensor (also I2C) should meet your needs.
Alan
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.
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.
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.
Please do not think I am negative on the EZ-b. On the contrary I think it has many exceptional attributes - but knowing what more advanced hobbyists really need (and why) should help future versions of EZ products perform better. As a example of a simple improvement, there could be a script command that allows all 8 analog ports to be read and returned as a group (perhaps stored in an array). I think you will find that all 8 ports could be returned in about the same amount of time as ONE port is now returned (because the overhead of the communication will be about the same for 1 byte or 50). This simple change could dramatically increase performance and thus the functionality of many operations - and I could easily come up with other such commands that would be just as valuable if not more so.
I strongly believe that advanced robot systems need to have subsystems that are able to run in loops to monitor various important systems. For example, I use a car bumper sensor which has 4 ping sensors. This is controlled from an arduino mini who's job is to communicate with that sensor array and tell the EZ-B when a sensor is tripped. The arduino calculates the distance to the object based on the value from one or more sensors and sends that information back to the EZ-B. The purpose of the arduino is not to make any decisions, only provide information back to the EZ-B. The arduino is great at running these loops. The EZ-B isn't. The EZ-B sends the information back to the PC. Extensive code runs to make a determination of what to do there. The code then sends the necessary commands back to the EZ-B, which then passes a serial command to another arduino mini who runs the movement for my wheels. The first arduino mini is still reporting back to the EZ-B of the sensor readings while the second arduino then tells the sabertooth to move the robot. Once the sensor connected to the first arduino reads that the threshold is not met, ARC recognizes this and sends the command to stop to the other arduino. The other arduino tells the sabertooth to stop. ARC understands that the sabertooth has stopped and things can proceed.
The reason that you don't do multiple things on an arduino or any other single thread machine is that it can only do one thing at a time. The EZ-B can do multiple things at a time and your PC can do even more things at a time. The arduino is not multi-threaded and is good at running specific loops. The EZ-B is designed to be either a controller of subsystems and/or control specific devices.
What you are describing is perfect for a combination of systems, but one has to be the main system and the others have to be subsystems. It is the same with programming. You have one main controlling application which then calls other well defined and limited components. They do one thing and do it well.
Without understanding this, the EZ-B is sometimes seen as a toy to some. Those who understand systems and subsystems will understand how powerful it really is and utilize this approach to push the architecture to the limit.
Reducing the number of times something is reported back to the main system is always a good idea. It is the same in all of technology from telephones to robotics. It allows your robot to be far more proficient and perform far faster. This is the same model used by every advanced robot that there is. It would be nice to have one controller that does everything great but it isnt possible. Some things are better on PIC processors than PC processors. They are a completely different architecture for good reason, but they can be used together to get the best of both.
That's actually a very good idea. Problem is, as I understand it, the software on the EZ-B4 is not reprogrammable by flashing it. So that is, unfortunately, probably not feasible. Still, never know. It might be possible by rerouting through the serial port to fetch the data, but I'm not sure how all that really works.
But.... you've missed my point. I am NOT saying there should not be subsystems that handle things like motors or sensors - what I am saying is that what is the point of building a great system (the EZ-b) that can help you read lots of different sensors - IF you tell me the best way to use this system is to NOT let it handle reading the sensors. Do you not see the inconsistency here?
I'm just suggesting there are ways of giving everyone more options - ways to make the power of EZ-b even more available to a bigger variety of situations.
Plus, all the comments in the thread tell me the bottle neck is the communication between the board and the PC. All the subsystems you mention still have to COMMUNICATE... and that information STILL has to be sent back to the PC.... in order for it to make the decisions.
All that said, I think you and I are in far more agreement than you might think.
I truly respect and applaud your observations.
John
The EZ-B is just communicating back to the PC where everything is happening. The PC is querying the EZ-B for the values over Wifi. The EZ-B is responding over WiFi. If you send any traffic over wifi at a rate of 8 requests per half second or even per second, you will over saturate the wifi. If this were 100 MB or GB speeds via wire, you wouldn't, but then you loose the ability not to be connected via wire.
The solution would be to prevent some stuff from coming back over wifi to the computer unless necessary. This is where the subsystem comes in. It only has to report positive or negative results, not both. Since the robot is in say a negative mode on the sensors most of the time, most of the traffic isn't sent back over wifi. Only when the data needs to come back it comes back. The communication system between the subsystems and the EZ-B would be point to point serial communication and not on the wifi network.
The stack is a custom stack to EZ-Robot. I haven't had really any issues except for when I have flooded it with requests.
www.ez-robot.com/Community/Forum/Thread?threadId=8067
Its a hang up with this type of system, my way around it is to produce custom PICs to act as sub-systems to take on a lot of the processing overhead - and this works very well. I see your point though, but when you get to a complex robot build using the v4 (in my opinion) you need to start using smart sub-systems. With the mix of the v4 and sub-system nodes then some pretty awesome robots can be realized!
Tony