Asked
— Edited
Resolved by DJ Sures!
Hey guys I have a question/ am curious about something.
I have 3 V4 boards and 2 of them work great. One of them has a serious delay while running ARC scripts. the script will start but nothing will happen for 4-5 seconds.
they have all been updated and run on the same windows 10 computer. All are powered with 12 volts DC.
Has anyone else run into this and knows why I am experiencing one board with a large delay?
Thank you again!
Aaron
Upgrade to ARC Pro
Synthiam ARC Pro is a cool new tool that will help unleash your creativity with programming robots in just seconds!
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.
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, 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.
Aaron
he wrote:
it's a cool idea ...
maybe an ultrasound transmitter ? similar to the video below :
https://www.youtube.com/watch?v=tAyWrJoVUbs
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
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.
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
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
Alan
It would make more sense to use a custom color filter
Alan
ME439PROJECT1SPRING2016.pdf