The fastest response within ARC is limited to 100ms (which is 10 times per second). This is to avoid flooding the communication channel. If you wish for a faster speed, you can do so with the C#/VB EZ-SDK and create your own application.

Hi Dj!

I've only been using your product for a few days, but I have to say you've got a really good product here, compared to writing code from scratch, I had taken one of my custom robots and replaced the controller (Parallax Propeller) with your controller and had it running in less than 5 minutes! This gives me more time to work on custom built robots instead of playing around for hours programming, so for someone like me who prototypes, this is great!

I'm still trying to figure out the sonar distance measurement problem I am having, where it's 12 inches away from a target, ARC says 18, I did change out the wires and they are less than 8 inches from sonar to controller, this includes the sonar that came with your kit. Is there anything else I can try?

Thank You

The value of the PING sensor is not in inches. This is because every ultrasonic ping sensor returns a different value - so calibration is nearly impossible. The number is simply a unit of imaginary distance for that particular sensor

Thank you for the kind words. I appreciate them I'm glad to hear we've been successful at providing you with a prototyping platform. I love hearing that!

DJ,

I think I know what the problem may be with the Parallax Ping sensor is, according to the spec sheet for it:

Input trigger: positive TTL pulse, 2 s min, 5 s typ.

Echo pulse: positive TTL pulse, 115 s minimum to 18.5 ms maximum.

So if it takes the EZ-B 100ms to read a responce and the ping sensor is 18.5ms max it's taking too long and the responce is not accurate?

Let me know what you think.

Thanks again

Oops, you posted just before I did, that answers my question then, so basically I just need to find a number that works with the robot the sensor is on for distance, thanks again..

@ charleybot. Pull out a tape measure and make a mark every two centimeters. The get a object that is easy for the sensor to see like a shoe box. Move the box every couple centimeters and write down the value the sensor is registered. This may vary for each sensor so this is good info to have. Then you will know aprox distance in centimeters for a given value the sensor returns. Make sense? To be accurate as possible do this with every sensor and take notes as each sensor may vary 2 to 4 centimeters off from another one. Have fun - Josh S.

@charleybot i see what you're asking. The Poll Interval value in ARC doesn't affect how the EZ-B communicates with the sensor. The Poll Interval determines how often to update information from the sensor. If the ARC asks the EZ-B for sensor information too quickly, the communication channel will overload. When that happens, your servos and other things will act strangely and lagging/delayed.

@jstarne1 - Thank you for the idea, actually that was what I was doing today before we got hit by hurricane Sandy, have to finish it tomorrow.

@DJ - I understand what your saying with the issue of data being too fast over Bluetooth, which I was wondering about, I changed out the Bluetooth module with a Roving Networks RN-XV WiFly module (https://www.sparkfun.com/products/11047 ) simply because I have Wifi throughout my house and yard and the host data rate on the WiFly is 464kbps, so far connecting to the EZ-B is much quicker than with the Bluetooth module, but according to the specs for the BC417143 it's data rate can go up to 3Mbps, so I am wondering if there's going to be any issues using the WiFly module?

Thanks again..

@Charley you won't run into any issues with the wifi module. The EZ-B is communicating with the ultrasonic sensor, not the computer.

The connection speed between the computer and EZ-B will automatically adjust based on the communication method used. The wifi module will be much faster

@DJ thanks, I actually had one of those days where I probably shouldn't of been working on electronics.. I was setting up the Wifly controller and had to update the firmware, well that was the easy part..... After the firmware update to the Wifly, it rebooted and must of said something bad to the EZ-Controller because my robot basically flew off the table full speed right behind me and hit the floor, result was a few new swears (okay lots), a stripped servo, and I also did something to the LM1084IT-5.0 reg as it's no longer outputting 5vdc, more like 2.6vdc.

Before this little mis-adventure happened the only issue I had with the wifi controller was that it seemed to stutter when controlling the sonar servo using the sonar control, but when using the bluetooth it did not, the debug window did not show any errors either so I was trying to figure out what was causing the stuttering when using the wifly controller(I figured between the firmware update on the wifly and maybe fine tuning some settings, you know...).

Anyways i'll have replacement regs in a couple days and hopefully be back up and running.

Thanks again

PS - good thing ARC doesn't have an option to repeat what someone says, cause it would of had to work pretty hard on what I was saying today...

HAhaha, sounds like an adventure! I was having a meeting with someone the other day who had a funny similar story. He said many years ago he built a very large robot powered by car batteries in his small apartment. He didn't put an on/off switch because it was remote controlled. Well, he had some interference and the robot went insane! Started driving around smashing into things. Apparently it took out a coffee table and a door!

So... consider yourself lucky

LOL, considering my work bench has all my test equipment on it I am very lucky it was pointed the other direction.. I've already put a second switch in so that the motor power can be turned off while the rest of my robot is running..

Oh that's a smart idea!

I usually hang or raise my robots so they are off the ground while i configure them