@d.cochran Coming up for air from playing with my JD. It's so much fun (notice, I used the word "much" I hate this popular thing of saying so fun).

I agree with what you're saying concerning the use of ARC to do the servo control. Doing that from scratch generally only makes sense with devices other than the EZ-B. Right now I am using the extensive text handling capabilities in the Script language to send and receive commands to and from the ARC program (as you mentioned in your post) from my own software. Semaphores direct traffic as needed. I use that technique whenever it's available since it eliminates having to learn and program in whatever language the actual API is coded with. And, of course, I can leverage all the stuff the Script language can access. It's good for sending an entire script or scriptlet to be executed as well.

In regard to the text file interface, the whole trick is to have an efficient Script loop running all the time to check the file(s) for an update. Unfortunately there is no Script function for checking the date-time or archive flag of a file to see if it has been updated so I use checking for the presence of a file to tell it that. On my software end I use a shell "event" to tell my program when the file has been updated. Right now I use a brute force approach by checking for the presence of the semaphore file to determine when the incoming (to ARC) file has been updated. With a sleep in there as well, of course. If you or anyone else has a better method I would be interested in seeing it.

The reason I use text files is that I like to cleanup things in RSS feeds prior to having it spoken through ARC and thus EZ-B. I set a parameter in ARC when the file is updated from my C# app through the SDK. Once the text has been used, I clear that parameter and remove the file. If you wanted to keep the file, you would just reset the parameter in ARC.

Because checking for the variable happens on the PC, I just use a WaitForChange($VariableName) in a continually running loop after the request has been sent to my app to go get and clean up the RSS feed for speech. Once the speech has been said and the file removed and the flag cleared, the loop is stopped.

I hope this helps.

d.cochran,

Thanx so much for all the information (I'm still a bit lost in figuring some of it out) and I'll try to explain what I'm after and to your point: why? ("why" go about it the way I'm trying).

The market/opportunity I'm after is a little bit different. EZ is one of the better example robots to hallmark my mission (but still not purpose-built for the exact need...yet a great example).

Here's the cool part of our common thinking/synergy: Move the "guts" of any program OFF the darn device and onto something that can do SO much more. I'm all over that. And in fact, is the premise of my open source initiative (www.meaowmeaow.com) to provide super-easy web-style interfacing to IoT and Robotics.

If I were trying to build an example of a really cool human-ish robot moving about and picking something up and talking and doing planned-motions/falls/get-ups I'm sure your builder environment would be a pleasure.

I'm chasing something bigger, largely around healthcare, human companions/pets, "dynamic toys", and much more. In contrast, the IoT community tries to build "dashboards" of your home-heat and appliances allow you to remotely activate them and check status. (Boring). The home robot market is about running canned scripts that do fun things (fun, but not a product for the markets I'm chasing). The industrial robot market is about things like ROS and RobotC and "real" languages with real complications to the average programmer and not at all easily intertwined with web-life.

My stack makes it simple for a designer-slash-programmer to intermix many devices, robots, I/O's, weather, medication charts, phone calls, etc...into one package that is as "ordinary" as building a web-page (portal) that talks to a variety of asynchronous sources and controls them to a particular theme...which can and will change all the time.

Now, that said, moving 18 different servos to get the beast to move across a desk it a lot to ask and I would relish a set of "meaow-meaow-callable" javascript routines for such. Because while it is moving it is looking for the candle (heat) or bright light or table-edge and adjusting it's behavior while knowing the medication schedule and perhaps heading for the Pharma box WHILE waiting for the new bluetooth reading from granny's glucometer (which might effect how robot reacts/scolds/advises/moves). (I have such level of devices today intertwined, albeit not with the glory of an EZ).

It's a grander level of integration, and I see many "things" in the market coming together to play in the game with a higher value and not knowing anything about each other. I want libraries and libraries of pieces that can be strung together and yet under an environment that everyone knows how to program (javascript/html, async, ajax) and constantly updating.

Not sure if that helps...Thoughts (or spankings) encouraged.

Stakutis I see where you are going now, and Java is not well served by EZ-B 's SDKs, but I think it would be easier to build a Java wrapper around the dotnet SDK than to try and recreate everything the SDK can already do.

That being said, I am not much of a programmer so I could be overestimating the difficulty of one approach and underestimating the other.

Alan

Thanx for responding! We are all learning so much...

Not Java. Not not not. Instead: Javascript. Yes, it is a HUGE difference.

Java programmers are like me (or me with more hair a while ago)...which is bigger systems, full systems, enterprise systems, big solutions...and ugly (mind you, I'm a huge java fan and one of the first users in New England...yes...but in the end...it's now another enterprise language).

NOT javascript. I'm talking and living (now, and younger in spirit!) in the javascript html "page" world. Not app world. It is different. The shift is towards the client, not the server. Faster. More horsepower. But the programmers of 2000 couldn't handle it. Lots of reasons (and I've written books on such). Now they can.

If you write a web-page, all the page-I/O is async, right? Clicks? Events? And go ahead and talk ajax to server and the Weather or your Geo or your medication or bank balance...ALL asynchonous and now little web/GUI programmers have to deal with this. (and they do! 'promises' and callbacks and loads of other stuff is now common).

Why is this important? You're NOT gonna control anything that moves or reports without understanding async. Sequencing a series of moves and collaborating that with real-world data/events is just hard. Hence the robo languages I've mentioned...uhg!

I'm a proponent of an approach that literally matches web-programming...AND can control kick-cool robots (EZ) and sensors and all at the same time.

Anyway, others might (?) find this approach useful and I'd like to share it with them...I just need to build the simple interface to the EZ devices.

Hey stakutis,

I get what you are trying to do. Here is my take on it, but first let me explain my background so that you can understand where I am coming from.

I have been a programmer for over 20 years and have mainly done business type programming. Some of it is some pretty complex business programming to truly automate a lot of the manual tasks. For example, I wrote the phone activation system for SouthWestern Bell Wireless which went into NOC and provisioned a new cell phone when cell phones were analog devices. I wrote systems that predicted the number of bankruptcies that would be filed a year from a point in time at about 95% accuracy. I wrote a OCR system for reading hand written data off of checks that is used in check processing centers. I wrote a system for using rules to classify every changing forms used for mortgage loans. When I say that I have written business apps, its not your normal database application type stuff but some systems that do a huge amount of processing. This allows me to think outside of the box because it is what I have had to do my entire career. This isn't to boast or anything, but just to give you an idea of my background. Now I manage a team that just makes sure that our 300+ daily production jobs complete so that the business can run. Important job, but pretty boring in comparison to what I used to do, so my focus for this type of challenge has moved over to robotics.

I understand what you are thinking and understand what you perceive to be complicated issues. They really are not. Let me explain. The SDK and ARC allow you to control your devices easily. To make your robot walk forward takes a series of movements of the servos. To make your robot turn left takes a series of movements of the servos. To read a sensor, no matter what type of sensor, takes a query of a hardware device to check the value of that device. This is the same for hobby grade robots or industrial robots. The movements can be scripted so that the application you are describing can not worry about what it takes to move a specific type of robot. When the robot is told to move forward, you could either call a class that then moves these servos, or you could just call the command in ARC to move these servos. Now, what if the robot stopped a point that wasn't in a standard standing position? Sensors could be read and the robot could start walking again from the point that it had stopped, or variables could be stored showing which position the robot stopped at.

What I am trying to say is that the communication to the EZ-B is already there. The ability to read sensors is already there. The ability to react to these sensors is already there, or you could program it outside of ARC in another device. I don't think that you have realized yet that ARC is able to do everything you are asking for it to do from a robot control standpoint. The language is a scripting language so it isn't a complicated language, but it can control your robot well based on sensor readings. It might be beneficial to move the reading of some sensors off to PIC controllers or to arduino's or something that just runs code in a loop to remove this load from the EZB, but that is your call. I do this and some others have also, but there are very few times that it is necessary.

If you want to use C or some more complicated language, you can. Not all features that you might need are in ARC. For example, there isnt a way to go get the robots current location, display it on a map, have the user request the robot to find the nearest convenient store, and then tell the robot to navigate to that store. The robot gets the walking directions from google and starts to go to the store while using sensors to monitor things like curbs, traffic or other obstacles which it avoids though a series of cameras and sensors. It is definitely possible to write this and it has been done. It doesn't require a difficult language to accomplish these things because all of the difficult stuff has already been done for you. It takes an understanding of what is happening where more than anything.

I feel like you are going to feel like I am arguing with you, but believe me, I am not. I am just trying to explain a new way of doing things in robotics. The best way that I can explain it is to go back in the history of computers in my life. I hated GUI based OS. Give me a keyboard and I could make the computer do whatever I wanted the OS to do. The mouse was silly. Then Windows 3 came out. I know, but I gave it a try because I saw that was the way things were going. 3.1, 3.11 included crappy networking but I could network multiple computers over 4 megabit token ring. Windows NT 3.51 made things better but limited me in other ways like direct access to the devices. So on and so on. I could still do great with the keyboard, and there are still some commands today that work much faster and easier with a keyboard like Renaming everything in a directory and subdirectories to a different extension. I still use a mouse now and I would never go back to just DOS.

As robotics grows, there will be some devices that offer you less control of the hard things because they do them for you. That is where we are with robotics. The hard things like controlling a servo or reading ports or whatever have been done for you. The controls for this system have been exposed for you to use in multiple forms. You can do this through web technologies, .net components and UWP. There are some others ways out there, but these are the ones that are supported by EZ-Robot. It is like any other platform in that .net may or may not be supported with that platform, but if I can build the wrapper for these commands to be exposed in the language that I want, then they become available.

I am going to say something and it might sound like I am trying to belittle you, but I really am not. I am saying this as a thought provoking statement. I don't use cobol or pascal when programming for a reason. New and much simpler ways of programming were invented. Cobol and pascal still have some advantages, but I don't program on them. I don't use a mainframe for a reason. Mainframes had some advantages, but newer things came out that made programming much easier. Anyone can make a robot do things with ARC. I used to not believe this but it has been proven to me time and time again. A good programmer will be able to make ARC do what it is good at doing, and do the other things outside of ARC.

I hope you take all of this in the manner it was intended which was to help or show you a different point of view which might help.

@stakutis Am I correct in thinking you wish to gain direct access to the EZ-B from a Java Script program of some sort? If that is the case, I wonder if a stripped down version of ARC would be more suited for what you want to accomplish? Maybe called EZ-Interface or some such. A program with none of the bells and whistles of ARC, just something to facilitate making the servos do things and read and set the other functions on the EZ-B. Is it that you see using ARC as big time overkill for your purposes?

Thanx everyone!