Are they in AP or client mode? If in AP mode, check the WiFi channel on the EZ-B web page. It could be set to a channel that is saturated in your location.

If in client mode, the channel is set by the router, but they can be set to 802.11g or n. N is faster, but has shorter ranger and more likely to have issues penetrating walls. There is a checkbox to enable or disable N mode.



Alan

Also check your project - it may not be optimized. Post it here and someone can look at it.

Also, if the project is not optimized, the communication channel may be flooded. There is a flood protection option in the connection control config menu. Be sure to read the question marks and help to understand it.

thank you DJ playing with the flood protection really helped out the response time, I think it was the project and it not being perfectly optimized..

Aaron

Aaron, that video is awesome. I have so many questions! How is the robot following you?

i see an Easter bunny inside the box !

he wrote:

Quote:

Senior design project for cal poly pomona. the robot is designed to follow a transmitter

it's a cool idea ...

maybe an ultrasound transmitter ? similar to the video below :

https://www.youtube.com/watch?v=tAyWrJoVUbs

Very similar but uses IR and ADC rather than ultrasonic

I really like their design but started me thinking of trying their method with an ezb. However could an ultrasonic sensor be tricked into reading another ping signal without the use of an xbee like in their video?

My understanding is that the sensor sends a ping and waits for the ping back. That time interval and the speed of sound result in a distance. Without the returning ping actually coming from the same sensor wouldn't they be out of sink with one another and when the ping is initiated? Is there anyway to compensate for this or set a delay to start once the initial ping is registered?

That way you wouldn't need the xbee to manually send the ping the same time it starts waiting for the return?

Aaron

You could use it without an xBee - but you would lose one feature:

The reason for the xBee is to have the micro initiate the ping, so a distance could be determined. The distance allows the robot to adjust speed.

If you had a handheld simply send a ping every second, you would lose the ability to determine distance, but you would know the direction. So long as you don't care about distance, you don't need the xBee.

A more cost effective, more compact and less complicated alternative to xBee are these RX modules. I've used them in past projects with great results: http://www.romanblack.com/RF/cheapRFmodules.htm

You can get them for around $2 for a pair on eBay - if you decide to go the route of the ez-b initiating the ping.

Personally, i would not use it at all. I would just have a ping sent every second. The speed could be adjusted by an IR distance sensor and camera - since the robot would require obstacle avoidance anyway.

My design uses infrared and the Polulu IR beacon and ADC monitoring for high and low values. pretty straight forward for the EZB *eyeroll*

Link

the only major downfall is sun light and other electronics that utilize IR. I have tried window tint and made bezels to block some of the UV rays but it is not as accurate as it is indoors. My professor was impressed either way... however I still know that it is not 100 percent reliable.

Hence why I am interested in the ultrasonic rather than IR...
I did not know RF modules were compatible! I will have to give these a shot

If you go the ultrasonic route, and use the rf, it would be pretty easy.

The biggest challenge you will face is the timeout speed of the ultrasonic. You see, if the ultrasonic sensor does not return a value, there a timeout speed. I don't know off hand what that speed is / but you can tell by covering the transmitter with your hand and running a quick ezscript command.

The timeout and ultrasonic sensor is what slows down the ezb dramatically. The solution would be to use an arduino to code a very short program which handles getting the direction of the ultrasonic and returns it to the ezb in form of either ADC or i2c

Lastly, the rf transmitter would connect to any ezb port. You can send serial commands from any port. So that part is easy

@DJ, How about adding blink pattern recognition/tracking to the ARC camera. Then you could use a visible or IR LED (since the camera sees IR LEDs fine) and use a simple 555 timer circuit to make a unique blink pattern. Then you can just use the built in tracking capability ARC already has to have the robot follow you.

Alan

The timing of the camera frame rate is inconsistent due to wifi quality/signal strength and packet prioritization

It would make more sense to use a custom color filter

Thanks DJ. Excellent point.

Alan

it is my last quarter at Cal Poly Pomona and i am enrolled in a 400 level mechanical engineering controls class... it saddens me that I am forced to use an arduino for something so simple that would take 5 minutes with an ez-robot board


ME439PROJECT1SPRING2016.pdf