Welcome to Synthiam!

The easiest way to program the most powerful robots. Use technologies by leading industry experts. ARC is a free-to-use robot programming software that makes servo automation, computer vision, autonomous navigation, and artificial intelligence easy.

Get Started
Asked — Edited
Resolved Resolved by Rich!

Rtc & Localized Positioning System Update, Shaft Sensor, And Solder Rig

Hi gang.
I have a couple items i'd like to ask. Some have been addressed to an extent (timers) but I haven't seen anything (or at least understood) that addresses my required capability. I also have a few update and general questions I figured i'd throw in. The main question is number 1.

1)I've searched through the forums on clock/timer links but haven't found exactly what i'm trying to do. I understand Arduino shields can be used with EZ-B so I've purchased a RTC. My goal is to have the robot perform certain functions on certain Dates & Times. I thought maybe a countdown would be complex as the dates and times would be easier to mark on a calendar than count how many seconds before 9:00 next Tuesday arrives and then 10:00pm the Saturday after that etc. How can I accomplish this?

2)Are there any further updates to the localized positioning system capability?
My bot needs the ability to follow a map but assure (to the extent it can be assured) that the it doesn't stray from that line in certain areas of the map so it won't fall off stairs, drive into the road etc. so it seems this capability would be the best to accomplish this.

3) I was thinking about adding shaft encoders to the signal wires on my jazzy motors. I know vex makes a few, does anyone have alternate recommendations or experience doing this mod with the ez-b?

4)Does anyone know what type of sweet soldering rig DJ has in his video's? I feel like a caveman with my $20 iron, that thing looks like it could make me the Michelangelo of soldering.

Appreciate the feedback.


Upgrade to ARC Pro

Unleash your creativity with the power of easy robot programming using Synthiam ARC Pro

United Kingdom
1) A RTC is not required for the EZ-B since it requires a host PC (or mobile device) which has it's own RTC that is used.

To perform things at specific times, dates, days etc. can be achieved many ways. The easiest would be to use a WaitUntilTime(hour,minute) command in EZ-Script, this will stop any code after this line running until such a time you have specified.

For instance,


Print("It's 1:30am")

If that script is run at any time it will not move past line 1 until 1:30am. Anything after it would not run until 1:30am.

Another method would be to use the $hour, $minute, $day etc. variables (the full list is in EZ-Script help to the right of the EZ-Script dialogue). Using IFs to only run code, or not run code, depending on time, day, date etc.

For instance



# Run every day other than Saturday
IF($dayname =! "Saturday")
# Run only between 20:00 and 22:00
IF($hour >= 20 and $hour < 22)
# Turn on LED on port D1
Set(D1, on)
# Otherwise turn the LED off
Set(D1, off)

# If it is saturday
# Turn on LED on port D8
Set(D8, On)
# Run a different script
ControlCommand("Script 2", ScriptStart)


I use both... I use the IF($hour = ...) to send the script to the right location then the waituntiltime() to hold the script until the time is right. This way avoid any missed activity if the project is restarted. When I have more time I'll post an example (however I believe one is posted in Josh's fish tank project post).

If needed I can expand on either of the above methods, just ask.

2) Use sensors to detect walls, floors, holes etc. is generally how things are done. You could, in theory, write complex code to map areas and it has been mentioned before but as far as I know, nobody has done so in ARC as of yet.

3) The use of encoders is often discouraged due to their inaccuracy.

4) No idea what DJ used in his videos but it looks to be a regular, variable temperature iron. Personally I use a Precision Gold 60w ESD Soldering Station which I would recommend. I have used a whole range of cheap to expensive irons and guns, electric and gas powered and this one is by far the best. It wasn't cheap but it wasn't the most expensive either and I ruined and wasted more money with the cheaper ones than this one cost me.
I agree with Rich, encoders are more of a pain then they are of worth... Since DJ has introduced object recognition in ARC I have be thinking of a way to use this for indoor navigation somehow... Haven't worked out the details yet, but with the ability to recognize objects means the ability to avoid them... I am thinking of a way to use standard pings, IR and object recognition to navigate around a room. I mean with a purpose as opposed to just wandering aimlessly... Not sure If you meant outdoor navigation... If so and you plan to do any distance then GPS would be the way I would go....
United Kingdom
GPS is only accurate to 1M at best, personally speaking I would want more accuracy than 1M. Plus GPS doesn't avoid things.

The whole navigation topic is one of great discussion from time to time, there are a few old topics which would come back to life if posted in. There was mention of EZ-Robots working on some kind of navigation solution, I am guessing the Revolution delays have set this back a little too but keep your eyes open for something which I am sure will be awesome.
GPs with EZB is difficult because of always needing to be with-in wifi range... so you're right Rich... GPS (unless used for long distances somehow) is definitely not for backyard robot use... I do hope DJ does come up with an indoor navigation solution... that truly would be awesome...
Thank you both. I appreciate the continued support, I only wish I hadn't been delayed so long to get started.n this project. I'll look at the script, I'm not a coder but hopefully I can make sense of it since the project requires the bot to do the exact same function every time.

* I'm a little concerned about the mapping and location as this is an outdoor bot and it will occasionally drive right next to the road, 1m error is a wide swath in that scenario. DJ mentioned a localized positioning system capability that would somehow function with a stationary ir camera viewing the bot. If that functionality arrives soon it should solve that problem. I'm sure I'm missing something but if I made a mapped path would the robot not follow that path only or would it still have potential to stray?

I'll hold off on the shaft encoders. I already bought the rtc so I guess I'll sell it. I also bought a set of ir send/receive units I'll post about soon.

*Do you think I should get that ez-b v4 brain box/board (is there a difference?) or would the v3 work fine for the stated project parameters?

I also have a DE kangaroo coming. I've been really impressed with DE's cust svc and build quality and this device looks really cool, I hope to try your code soon from the relevant forum post concerning that.

*Finally, would you describe the ez-b as a microprocessor or microcontroller? I'm just not really clear why this product doesn't seem to be as well known as the others out there.
I recently bought the much touted BBB to play with. It's a powerful unit but as far as robot functionality without the linux rabbit hole chase, it's a bust.
My Ez-b is two years older at least and it just works and despite not having as many (in quantity) online location resources, the quality of support from the site and forum is awesome. I'm really glad too because many forums are hit and miss.
Thanks for any suggestions.
Hey Matt,
I'll attempt to answer a few of your questions.... EZB is basically called a microcontroller

1) Your bot can only follow a mapped path if it has some way of knowing where it is at all times... i.e using GPS, wheel encoders, IR beacons etc
... a) and what if there is an obstacle in it's path... It will need the ability to navigate (using sensors) around the object the resume it's course

2) Dj's localized positioning system is going to be for indoor only (for now anyway)

3) Using V3 and V4 makes no real difference in regards to your project... one uses bluetoooth (V3) which always needs to be within 30ft range of your PC. The other (V4) uses wifi... Again, you'll need to be with wifi range of your bot unless you put a computer on board your bot...

No matter what, you are going to have to learn a fair bit of (scripting) or in not so many words programming in order to accomplish what you want to do... You just can't throw a couple of motors on a robot base, offer a few mouse clicks and Bobs your uncle... Even with the power of ARC and the EZB it's just not that simple...

My advice is read the tutorials (many more are on the way) and buckle down and learn ARC scripting... You'll be glad you did. It opens up way more possibilities and cool projects...

Good luck... Have fun most of all...:)
Bellow is a code I wrote (ha, maybe 10 yeas ago) using the basic atom pro microcontroller (not made anymore)... All it does is enable my robot to navigate to a set way point using an onboard gps... This version was never finished and has no real obstacle avoidance included... Just navigates from a to b.... It's nothing fancy (and I am no great programmer, that's for sure), but the language is similar to ARC scripting... Hopefully it won't scare you off, but better yet encourage you more to learn to program... If I can do it, you can too....

'For Atom Pro and 4WD3 Lynxmotion rover 12Volt motors

'order of serial inputs of GPRMB and GPRMC may need reversed depending on GPS unit.
'variables used....

tr1 Var Word 'true heading variable
wp1 Var Word 'waypoint heading variable
twp Var Word 'temp rotation variable
pulsecount Var Word
rotate Var Word
stat Var Byte
arrive Var Byte
surface var byte
left_detect var word
right_detect var word
object_on var word

Sound 9, [100\880, 100\988, 100\1046, 100\1177]

object_on = 0
surface = 0


if in4 = 0 then 'A button higher the number, smoother the surface 4 for concrete
pause 300

if in5 = 0 then 'B button - object avoid on/off
object_on = 150
FREQOUT 9, 250, 3000
pause 200

if in6 = 0 then 'start program
if surface=0 then
goto begin

goto top

'serout S_OUT,i9600,["object on=", DEC object_on, 13]
'serout S_OUT,i9600,["Surface=", DEC surface, 13]

Low p0
Low p1

Sound 9, [100\880, 100\988, 100\880, 100\988]

' next sentence takes information from $GPRMC sentence coming from GPS unit
' set to NMEA data out.
' It is set at the standard NMEA rate of 4800 baud

SERIN 14, N4800, [WAIT("GPRMC,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),DEC tr1] 'the current true heading

SERIN 14, N4800, [WAIT("GPRMB,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","), DEC wp1] 'the current waypoint bearing

SERIN 14, N4800, [WAIT("GPRMC,"),WAIT(","),stat] 'valid fix?

SERIN 14, N4800, [WAIT("GPRMB,"),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),WAIT(","),arrive] 'waypoint arrival?

serout S_OUT,i9600,["W", DEC wp1, 13] 'Waypoint bearing in degrees true
serout S_OUT,i9600,["C", DEC tr1, 13] 'course in degress true
serout S_OUT,i9600,["V", stat, 13] 'valid fix
serout S_OUT,i9600,["A", arrive, 13] 'arrived

IF arrive="A" THEN
PULSOUT 1,3050 'stop motors
PULSOUT 0,3050
FOR rotate = 1 TO 10
sound 9, [100\880, 100\988, 100\1046, 100\1175] 'play arrival note

IF stat="V" THEN 'wait for fix
FREQOUT 9, 1000, 3000
'serout S_OUT,i9600,["No fix yet",13]
GOTO getgps

IF wp1<tr1 THEN 'calculate the shortest direction of turn to waypoint bearing

IF twp<=180 THEN 'move right
rotate=twp/surface '4 for concrete, 3 for short grass, etc...?
'serout S_OUT,i57600,["Turn Approx ", DEC rotate*surface, " degrees right", 13]
GOSUB moveright
ELSE 'move left
'serout S_OUT,i57600,["Turn Approx ", DEC rotate*surface, " degrees left", 13]
GOSUB moveleft
GOSUB go_forward

for pulsecount = 0 to 444
if object_on<>0 then
gosub check_IR
pulsout 0,(2050) 'go forward at about 90% (20ft) comp for any veer
pulsout 1,(3950)
pause 20
goto getgps

FOR pulsecount = 0 TO rotate 'when rotate=20 it's 90 deg turn on concrete
PULSOUT 1,2000
PULSOUT 0,2000
pause 50

FOR pulsecount = 0 TO rotate
PULSOUT 1,4000
PULSOUT 0,4000
pause 50

ADIN P18, right_detect
ADIN P16, left_detect
if right_detect>object_on then
rotate=80/surface 'turn according to type of surface, greater turn on rough surface
gosub moveleft
elseif left_detect>object_on
gosub moveright
United Kingdom
Very quick reply (for now).

Don't worry too much about having to code for the EZ-Script. It is insanely easy to use and I am generally on hand to guide you in the right direction. I do tend not to write the scripts for people and try to get them to write them themselves but if you were struggling I wouldn't leave you hanging - so far nobody has struggled:)

For the more complex yet generic functions, such as using IFs to jump to the right place for the WaitUntilTime I have added writing such a script to my list, and if you haven't yet seen my scripts they are all commented and easy to adjust to suit your requirements so it's really just a case of writing the parts for the specific robot actions.

As for positioning and avoiding roads etc. there are ways to achieve this. You can use encoders if you want to, I know Tony uses encoders on his AIMEC bots but a lot of us tend to avoid them because of the accuracy issues. But using them in conjunction with ping sensors, IR sensors, cameras etc. I'm confident we can come up with a way to keep the robot on it's path or at the very least avoid any danger to itself or other people.

The V3 or V4 would work, the V3 is still a very powerful board and I intend to continue to use mine (and possibly buy up a few which come up for sale when the V4s are shipped).

It's beyond me why the EZ-B isn't as popular or well known as Arduino, Beaglebone etc. It may be that EZ-Robot is still a pretty new company and until around a year ago (not even that) they were operating out of DJs basement and had a total of 2 staff. The recent push in media, events, STEM etc. that EZ-Robots has been doing will most likely boost it's popularity by a lot. I'm confident enough to say that it will, one day soon, be as popular if not more so than other microcontrollers.

I would like to go against what @Richard R said though, with the EZ-B you could just throw on a couple of motors (via a H-Bridge) on to a platform and have a robot. It wouldn't be that good a robot but it would be a robot and would be very easy to make. In fact, I have. My test bot (version 2) is a couple of motors (4 actually) connected to a h-bridge, mounted to a Dagu 4wd chassis, a ping sensor on a servo mounted to the chassis and that's it, a robot that can guide itself around my living room without crashing. It doesn't do much else but it doesn't crash:) That's the one end of the spectrum. The other end are robots like Dave's B9, Anthony's Lexi, Doombot's Doombot. And then you have all those in the middle or towards the high end of the spectrum like the Wall-E robots, my Melvin, etc. (too many to list).

That's the beauty of EZ-B and ARC. It's as simple or as complicated as you want/need it to be. It just works. The hardest part is the fabrication of the robot. In Anthony's words, "you point you click you drag you're done"
Well all of that makes sense to me. I will try to work with the script for the two or so functions I want it to so at certain times.
I was just thinking. Wouldn't it be possible to place inexpensive beacons of some sort outside that would give the robot the ability to triangulate its position exactly within the defined area? Transponders are inexpensive. I think some of the invisible dog fences use something similar. I also have two sensor barriers that came with the roomba I've never used, they look like the photo below:

User-inserted image

If I put something like this around the perimeter of the yard wouldn't it essentially act like ground based gps?
Hope this makes sense.

Has any been able to detect on object and identify and let's say the particular object name?

See a ball says "this is a ball"?

How about resize the scan size for an object?
I have, but objects only get correctly identified maybe 1 out of every 10 times... I agree, the scan size window needs to be able to be resized to fit the particular object being scanned .... the default scan area is currently way too small...

But did it say the object? Also I saved 2 and next time opened they were gone.

I did get an error but didn't look at when closing.. I need to get to something else quickly.
You have to tell it to say the object's name , but yes I got it to recognize my face the best out of all the objects I trained it to... I assume DJ is still working on it...
I bought the Roborealm AVM navigator software yesterday and also asked Steve if he would make it work with ez-b easily and pasted a forum link so maybe he will. I don't have the ability to make it work on my own but hope it can work in the future.
Maybe with the wireless ez-b camera? Or I have some old iPhones and camcorders lying around, some of them have good cameras.