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,

WaitUntilTime(01,30)
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

:loop

# 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)
  Else
    # Otherwise turn the LED off
    Set(D1, off)
  EndIF

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

Sleep(100)
Goto(loop)

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....

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. Matt

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. 'code '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

top:

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

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

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

goto top

begin: '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]

getgps: ' 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 PAUSE 400 NEXT end ENDIF

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

IF wp1<tr1 THEN 'calculate the shortest direction of turn to waypoint bearing twp=360-tr1+wp1 ELSE twp=wp1-tr1 ENDIF

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

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

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

moveleft: FOR pulsecount = 0 TO rotate PULSOUT 1,4000 PULSOUT 0,4000 PAUSE 20 NEXT pause 50 RETURN

check_IR: 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 return elseif left_detect>object_on rotate=80/surface gosub moveright endif return

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:

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.

Matt

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...

Richard,

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...

Ok thanks for the input.

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.