The lack of interrupts (in my opinion) is a big disadvantage with the EZ-B/ARC, if it had interrupt capability then (again in my opinion) it would be near perfect. The EZ-B latency issues are a real issue to me personally.

Tony

Hey Tony,

I'm glad you were able to find a work around for the uart communication but I am surprised about your comment about the lack of interrupts.

Since ARC is a multi-threaded system and all variables are global you can interrupt a process very easily. Obviously, it's not a true hardware interrupt where it halts any process at anytime but you can use a "check for flag" anywhere in your ez-scripts that looks for the change of a single variable then use the Halt() command to exit the script and do something else.

I'm curious to where a hardware interrupt would be needed, possibly an emergency button maybe? I would likely just use a button that would just physically cut power in that case. Possibly a reset button? I would just use a button that momentarily separates in-coming power in that case. ....curious.....I'm still very curious.....

I will have to check out the plugins. Somehow I missed that in my research. Thanks!

One example of use of an interrupt in robotics (not necessarily in this case, more so for a child processor) is for a digital encoder. That way you catch all of those pesky little pulses. I have also used interrupts to monitor IC communication. For example, maybe a d latch, with a latch pin that is only held high for 50microseconds. Idk, it is just a good way to solve problems.

-Eric

I'll just throw my 2 cents in here on a couple of topics covered. A lot of us are building robots with embedded windows computers to run ARC. There are a lot of small low power computers available now pretty cheap.

In most cases the SDK is being used to pass variables between ARC nad an external app. It is certainly possible to build all of your functionality in the SDK, and with the Universal Bot sdk, run it on pretty low end machines (raspberry Pi for instance) but ARC makes the basics so easy, only those looking for a challenge use that. The new plugin capability will probably replace a lot of the current SDK functions.

Alan

Jeremie, this is my view on interrupts - its an issue if you want to use the EZ-B v4 to build serious robots, for simpler robots the EZ-B is a truly excellent system. I personally think that an advanced robot needs sub-system nodes that feed back to the EZ-B, these sub-systems (if realized correctly) take away a huge amount of the processing overhead on the EZ-B and together make a much more powerful robotic system. Any system with multiple processors needs a way to "flag" their fellow processors very quickly and efficiently and here is the rub if you want to do even a simple thing like just strobe the v4 from the sub-system it can take up to 600 milliseconds to reliably respond! This in today's computing world is an absolute lifetime, take the sub-system PICs running at 20MHz which equates to around 5 million instructions per second, so the PIC could process around 3 million instructions in the time it takes for the v4 to respond! This latency I know is due to the WiFi overhead and the v4 processing many other things, but if their was a way of using true interrupts (on the EZ-B) so really urgent data could be processed in real time it would turn the EZ-B into a very powerful robotic controller.

Tony

I'm with Tony on this. In my robot platform I use a Beaglebone Black to handle the communication and rapid decision making. The EZB is attached to the BB and sends commands to it and receives information back from it. The BB is attached to arduinos which do motor control, sensor readings and other input/outputs. The BB is able to react to the arduino readings of sensors and then take an action.

An example of this are the ir sensors that are detecting edges or drop offs like stairs. When the robot is moving and a dropout is detected, the motors are stopped. This happens in a couple of milliseconds. The information is then sent back to the EZB which then transfers back to ARC letting it know that an edge was detected and the robot was stopped.

1/2 of a second delay could cause the robot to to fall down the stairs. This architecture also allows for a simplified method of controlling devices and motors from ARC or the SDK. For example, you are able to use a serial command of "move robot forward 4 inches" or "turn robot right 15 degrees". ARC or the sdk doesn't need to know what these commands do to accomplish these tasks. It just receives a command back that the task has been completed.

The BB was chosen for this because it is has a very reasonable price, is open source hardware, and is pretty impressive hardware. It also will house a lot of the other features that will be proprietary to my platform. It offers a way to more securely house these functions.

Anyway, I just wanted to give an example of where this would be nice.

I love the EZB and the ease of ARC. I do believe that it is great for most situations, but like everything there are a couple of things that could be improved on or expanded on a bit. I just happened to need some of these in this project.

@thetechguru That was some useful info, thanks! Using an embedded platform sounds good. Could you explain (or point me to another resource that could) how the SDK is used to pass variables to the ARC and an external app. This might be really useful! Thanks a ton!

@Toymaker and @d.cochran Yeah interrupts are definitely more useful on a sub-system processor.

-Eric

Eric, send me an email (look at my profile) and I will send you some code today that does this. There is a class that I have built in C# that handles this and can be dropped into a project and used.