@Robot basic.

Hi John. When you say "EZ computer", I'm assuming you're talking about the EZ-B v4 controller. The ADC ports in the EZ-B are Configurable at 8-bit (0-255) or 12-bit (0-4095) return values in the ARC software. In an ADC control in the ARC software such as "Read ADC", ADC reading intervals can be selected from 100 ms to 60000 ms. I read sensor data from my EZ-B at 250 and 500 ms with no problems at all, and is certainly fast enough.

Just to run through a few things to check for anyone else reading this facing similar issues... with the EZ-B connected to the ARC software so you have a nice strong connection, make sure that you are supplying the correct power to the sensor that you want read (Remembering that the power output from an ADC Vcc port is 3.3v), that they are connected to the ADC ports correctly, the correct port is selected in the ADC control config menu, and that the sensors and cables are in good condition, adjust the "interval ms" in an ADC control so suit your and your sensor needs, and adjust any potentiometers that may be on the sensor itself to dial in any sensitivity that helps get correct readings.

I hope that helps.

Post edited to reflect changes.

Thanks for the reply Steve - jut a few questions and comments to help clarify. First, I have used various sensors and just a pot for testing, so there are no problems with the sensor.

You say you are reading the sensor data at 250 and 500 ms and that you are receiving reading faster than 80ms - this confuses me as 250 and 500 are NOT faster than 80. It does not matter how fast I can get the data if it only updates every 100ms (or 250 or 500).

If I place several GetADC() calls inside a loop, the speed really slows (seems to take about 80ms for each call so reading all 8 ADC ports takes about 1/2 second.

Also, you say the ADC can be configured as 8 or 12 bits - where do you do that? I am using the default and do not see any option for such configuration.

I appreciate all the help.

John

Hi John.

I just re-read my post and I see I didn't explain what I meant clearly enough (replying on my phone while traveling). What I was saying was that I use 250 and 500 ms intervals to read my sensors which is plenty fast enough. My post should have read "certainly fast enough" not "faster than". I apologise for that. The minimum setting for data read intervals in any ADC config menu is 100ms which is pretty fast and uses a bit more processing power.

The configuration info was what I remembered reading from the EZ-B v4 data sheet. I have posted a screen shot and link below...

EZ-B v4 data sheet

I believe this can be done by writing scrips, but this is something I havn't tried so can't be of much more help there.

Hope that cleared things up a little, and sorry for any confusion.

John, I think Steve is thinking you mean interval or polling rate and you are talking execution time to do the read ADC. I have seen it be as fast as 50 ms or so on my system. This is due to the communications time across the wifi. If you need fast, you probably would have to go with an Arduino which I think has a read ADC execution time of 100 microseconds. But Arduino doesn't come with wifi, out of the box.

@Robot BasicI 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?

Here is a thought for you...

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.

The arduino due can be purchased for 17 dollars here, http://www.banggood.com/Arduino-Compatible-DUE-R3-32-Bit-ARM-With-USB-Cable-p-906466.html.

I normally buy Mini Pros in lots of 5 for $15. let me see if I can find the link for them.

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:

Quote:

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.

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.

I've done several projects with UDP and TCP communication - with the proper protocols the comm should NOT be a bottle neck. I agree that using a separate processor to handle the sensors makes sense - but then why not let it handle the servos too. When I first started reading about the EZ-b, one of the things I really loved was that it made it easy to read accelerometers, gyros, etc - EZ has done a SUPER job of providing a fantastic selection of sensors - this capability alone makes it possible for many novices to experiment with things beyond their skill levels. But..... if you cannot access the data from such sensors in a timely manner, then the value is far less valuable. Let me give an example to illustrate my point. Suppose we have a 6-leg spider (imagine that). If you give it motion with a series of servo frames, then a beginner can get it to walk easily. But that walking is often only effective on a smooth flat surface. A much more exciting project (one that makes a real robot not a beginner's toy) would be to have a switch on the bottom of each foot. This would allow the software to lower each leg - not to a predetermined point dictated in a frame, but until the leg reaches the floor (or other object). This would allow the robot to have the intelligence to walk over irregular surfaces, up and down stairs, etc.... in a truly autonomous manner. But the spider's ability to walk at even a reasonable speed would be hindered if it takes 1/2 second to read the state of the six switches (let alone any other sensors the robot might need). And this is just a simple example. You can't really put sensors on the grippers (my Arlo robot uses EZ-arms and it has 4 sensors on each gripper) - if I had used the EZ-b, just reading the 8 gripper sensors would take nearly a second - making it impossible to use the sensors to effectively guide the grippers to an object to be picked up. Furthermore, as mentioned earlier, what is the value of being able to read gyros and accelerometers (which are generally used to give orientation information) if you cannot read that data fast enough for your robot to react to orientation problems in time to correct them. Sure you could let a separate processor handle the sensors, but then the EZ-b's fantastic ability to read sensors is essentially lost. If I am missing something, please enlighten me. 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 understand what you are saying and where you are going. I am not trying to argue anything with you, just point out the way that I do things which might help you out.

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.

@RobotBasic

Quote:

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

d.Cochran - I completely agree with you - that is the philosophy we used to build the RobotBASIC-RROS system. It is also the way I built my Arlo robot which uses MANY subsytems with RobotBASIC in control. So yes... I DO UNDERSTAND what you are saying and agree with you too.

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

Hey John, I think your are missing one point with this architecture.

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.

Lets take your computer. It is the job of your computer to store data on its hard drive. Can you do too many things on your computer that write too much too quickly, sure. I would say then go with a raid or a faster hard drive. Well, now there are subsystems that are caching controllers that sit between your computer and your storage. This caches the information so that it doesn't have to worry nearly as much about the pipe to your hard drive. Do I think you should not store data on your hard drive, no. I would say that different situations would require you to look at different solutions. The hard drive issue is something that very few people face. I face it at work on a daily basis because. The computer and the hard drive should be able to keep up, but the bottleneck then needs to be handled some way before you can get more speed.

John, latency is an issue with the v4, see my thread on this.

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