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.

synthiam.com/Community/Questions/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