Windows 2016.01.29.00

(Autonomous Robot Control Software)
Make robots with the easiest robot programming software. Experience user-friendly features that make any robot easy to program.

Change Release Notes

  • Still weird typing 2016 in release notes. Time flies...
  • showcontrol for RoboScratch in EZ-Script to be used in mobile version
  • ez-b v4.x/2 comm expansion configuration utility
  • RoboScratch double buffer removes flicker when dragging elements
  • RoboScratch new element for embedding custom EZ-Script
  • *Updated: MPU9150 control for compass tilt compensation and more accurate heading. Read the control manual for calibrating (wave the compass module in a figure 8 to calibrate when ever the values go wonky... just like your iphone asks you to)
  • *Updated: SoundBoard (ezb) fix for when there is no auto positioners in project when editing script

ARC Downloads

ARC Free


  • Includes one free 3rd party plugin robot skill per project
  • Trial cloud services
  • Free with trial limitations

For schools, personal use & organizations. This edition is updated every 6-12 months.



Only $8.99/mo

  • 2 or more PCs simultaneously
  • Includes unlimited skills
  • Cloud backup
  • And much more

Experience the latest features and bug fixes weekly. A Pro subscription is required to use this edition.



  • Load and run any ARC project
  • Operates in read-only mode
  • Unlimited robot skills
  • Early access fixes & features

Have you finished programming your robot? Use this to run existing ARC projects for free*.

  • Minimum requirements are Windows 10 or higher with 2+gb ram and 500+MB free space.
  • Recommended requirements are Windows 10 or higher with 8+gb ram and 1000+MB free space.
  • ARC Free known-issues can be viewed by clicking here.
  • Get more information about each ARC edition by clicking here.
  • See what's new in the latest versions with Release notes.

Compare Editions

Feature ARC
  Get ARC for Free View Plans
Usage Personal
Early access to new features & fixes Yes
Simultaneous microcontroller connections* 1 255
Robot skills* 20 Unlimited
Skill Store plugins* 1 Unlimited
Cognitive services usage** 10/day 6,000/day
Auto-positions gait actions* 40 Unlimited
Speech recongition phrases* 10 Unlimited
Camera devices* 1 Unlimited
Vision resolution max 320x240 Unlimited
Interface builder* 2 Unlimited
Cloud project size 128 MB
Cloud project revision history Yes
Create Exosphere requests 50/month
Exosphere API access Contact Us
Volume license discounts Contact Us
  Get ARC for Free View Plans
* Per robot project
** 1,000 per cognitive type (vision recognition, speech recognition, face detection, sentiment, text recognition, emotion detection, azure text to speech)


Upgrade to ARC Pro

Become a Synthiam ARC Pro subscriber to unleash the power of easy and powerful robot programming


Love the addition of custom scripts. Since this is based on a chain of events, I would suppose one would have to know what comes before and after it (script wise) so it will integrate properly. Not just any script will work in any configuration. And what works in one place will not necessarily work in another place. Anyway, what I'm saying is that this particular component may require a bit more attention to explanation in the tutorial.

I know this is a WIP, but I thought I'd take the occasion of this update to mention a couple of things I have seen about the operation of the Scratch window.

First, there is no vertical autospacing that occurs when a component is inserted between two other components.

Second, the components cannot be pushed below the bottom of the window or the right side. This makes it impossible to add components beyond those points, limiting the total number of components allowed. I see that if you shrink the window into where the components are, scroll bars will appear so I guess it is meant to be able to scroll both ways. As it stands now, however, there seems to be no way to go beyond those boundaries. It might be helpful if, when pushing a component to the bottom or right side, the scroll bars appear and the whole image shifts in the appropriate direction.

My apologies if I am premature in all these issues and you were going to address them in due course.


Can you post a screen shot of what you're seeing?

Nothing that you've described is a bug or an issue, if I'm understanding the post correctly.

  1. you can move elements around the screen to make room for new elements. Sliding an element between two other elements will cause you to move those other elements.

  2. the boundary of the screen is restricted so children and new users learning to program do not accidentally lose elements that are hidden with scroll bars.


Correct. I'm not saying they are bugs as such, just limitations. I see now that the boundary restrictions are purposeful, so that explains that.

The autospacing (vertical expansion) that I am talking about is more of a convenience than anything else. Just that I thought it would be nice if the space between elements would automatically open up (vertically) when a new element was moved in between two elements already in place. This, as opposed to how it is now in which the lower one (and every one under it) has to be moved down manually to make room for a new control placed above it. I thought it would be good if those controls would automatically move down to make room for the new component. Likewise, everything automatically move up if a control is removed.

Since this is for beginners, I figure there is going to be a lot of insertions and removal of components as users are experimenting with how things work. That means a lot of shuffling of other components down when something is added to a column. Having the components move back up when something is removed is, of course, not as big as deal as things moving down when one is inserted. It would just help keep things tidy.

Speaking of tidiness. I wonder if it would also be good if the elements snapped into place (at least initially) so that the lines between them were nice and vertical. I guess I just like things to line up easily. In a way I suppose that would be akin to the auto-arrange option in ARC for getting controls to line up. So making a "snap to" option in this could be good.

Just suggestions.


Updated the version to .28 because this one now includes the MPU9150 update as mentioned in the first post


Sorry to say this DJ, but the MPU9150 is still not giving data of any value from the compass (and yes, I did the calibration routine, several times). At least now it appears to be giving degrees, the values are between 0 and 354 (maybe 360 but I have never seen it above 354 yet this evening).

Regardless of orientation, it always reads somewhere in the 200's, then will occasionally jump for a second or two down to 14 or so, up into the 300s, and then settle back in the mid 200's. It definitely detects movement, because it is fairly stable when still, and it seems to know which direction it is moving, because the value will raise or lower depending on which direction I turn it, but then it jumps wildly and seems to have no basis in reality.... Turning it 180 degrees, it will jump back to around its initial value as if I had turned it 360 degrees. If that was at least consistent, it would be useable, but it jumps wildly between other values on its way there.

I have tried it in every orientation - flat with the circuit board up, flat with it down, vertical with the plug on top, vertical with the plug on the bottom, sideways. No difference, and it is connected to a bare EZ-B with no servo motors or any other magnetic sources nearby.

I have tried it on two different EZ-Bs tonight, and used different I2C ports on both of them.

In the same location where I am testing the compass on my phone works perfectly, even if I bring some servos fairly close to it. The compass x, y, and z variables fluctuate between positive and negative numbers with no apparent basis in reality.

Also, the temperature is now reading between -2000 and -4200 celsius and fluctuating wildly.

Do you think I just got a bad circuit or do you need to go back to the code again?



Perhaps you have metal around it? Yes, the temp has not been adjusted yet - waiting on additional info about decoding the data correctly.


@Alan... I will try mine later tonight when I finish work...


@DJ, no metal or magnets nearby. Compass in phone works. I'll test tonight compared to a needle compass too.



Hi Guys, Any more on the compass?



DJ. Either you or Jeremie in one of the other threads about the compass issues mentioned that the sensor device is being redesigned. Are you testing with the old one (that was sold through Brookstone) or one of the new ones?

If it works with the new one, I will wait for its release and include one in my new order. I have almost enough EZ-Credit to cover it anyway, and the accelerometer/gyroscope at least works on this one, so it will have a use, just not the one I bought it for.



Hey Alan,

We are testing with one of the Brookstone sensors. At the moment we are revisiting the older code while we finish up development on the new sensor. As you can see, ARC is getting some new additions as a result:).


OK. As usual, if there is anything I can do to help test. Logs, debug builds, whatever. I am curious if Richard R's and Andyroid's sensors work better than mine with this build. If they do, I'll assume mine is bad and wait until they are shipping again, but if not, I am here to help....



Hi Alan I will test mine tomorrow morning and let you know how I make out.

Ron R


I have added comments from tonight's testing to your thread here:

Makes more sense for the issue to have its own thread than to keep talking about it in the release notes thread.

Some progress, but more weirdness too.