You write code that runs on the host and communicates to the EZ-B over WiFi. You write the code on a windows computer. For all features, you run it on a windows computer, but with some limitations, you can use the ARC software to create a mobile app that runs on Android or iOS.

There is a .NET and a Windows Universal SDK, so if you really want to write everything yourself, you can (running your app either on Windows 7 or higher using the .NET SDK or on Windows mobile or a Raspberry Pi running Windows 10.

Many developers have found the best use of the SDK is for integration, so use ARC for everything it already does well, and the SDK to communicate between your own applications and ARC to extend the functionality.

Alan

Thank you and that helped greatly. Still a little confused. Can I write code that runs on the device itself it or is that way too involved? And if I have a bigger application how do I interface to the builder? Api? Socket? Web services?

hey Stakutis, Welcome to the community.

Your code would be developed for windows, which uses the sdk to communicate with the EZ-B. The code runs on the windows machine. It communicates with the EZ-B over wifi and a TCP port. Your code doesn't run directly on the EZ-B. The EZ-B has to be tethered to a PC which runs the code.

The beauty of this design is that the PC does all of the "heavy lifting". The EZ-B is kind of like a communications port that is queried by the PC. Commands can be sent to it to use the digital, I2C, Analog, serial and camera port on the EZ-B. The EZ-B controls the hardware that is connected to these ports. This architecture allows you to then also have use of all of the capabilities that the PC has. For example, you can use API's from internet sites to do some pretty cool things. Lets say that you had a GPS I2C device connected to the EZ-B. This information would be able to be queried from the PC application, which could then go to Google Maps to get your location, directions to other locations and whatever else you want it to do. It allows your solution to become very powerful.

The SDK can be used to communicate with ARC. It uses a network port for this communication. The code can run from different machines than the one running ARC because of this. This allows you to build web services for this if you would like, or really any abstraction layer that you are comfortable building. I personally use a C# application that communicates directly to the port via an object that is available in the SDK.

I would suggest downloading the SDK. There are many examples and I believe all of them contain the connection object that you would use.

Thank you again. I've looked through lots of the documentation and downloaded the SDK and Builder and I'm still a bit confused.

Let me see if my understanding is at all correct...

The robot has some base-communication ability programmed into it and the host talks to that interface. In general, that interface "exposes" the fundamental pins and I/O's and all the joy of the internal computer. The host can set values and read values etc. And then the combination of such things makes the robot do something useful and all from the host. Is that about right?

If so, first, is THAT API at all published? Because that is exactly what I want to call and what I do for my other devices (often I have to write that interface). And I want to call this from javascript and stay in that environment.

And here is a very basic question that might help me understand overall how things work. To me, I understand that Builder allows you to specify all the connections (because you could connect any motor to any I/O) and allows you to tune the motors to specific initial settings, right?

In the videos, you show some amazing motions, such as the robot getting up off the ground. How and where is that logic? Does builder allow the user to somehow choreograph motions and record them for later play back? Or does the creator "script" each and every motor move and then get those assembled and timed correctly all in the scripting language? Is all of that motion "running" in the Host or is the host remote-calling some mini-execution environment/program downloaded to the device?

I would rather not "build" a C++ project or anything like. I'd rather call the API from my own javascript, and/or use javascript libraries that provide an interface. I'm willing to provide the latter if need be because then it fits into my overall control scheme well and I would LOVE to support this robo.

Answers are inline...

The robot has some base-communication ability programmed into it and the host talks to that interface. In general, that interface "exposes" the fundamental pins and I/O's and all the joy of the internal computer. The host can set values and read values etc. And then the combination of such things makes the robot do something useful and all from the host. Is that about right?

Answer - The robot can be communicated with directly, outside of ARC. DJ would need to give you more information on this, but yes, there is a service running on the controller that is what ARC uses to communicate with the EZ-B on. There was a post not that long ago about this and I will see if I cant dig it up for you.

If so, first, is THAT API at all published? Because that is exactly what I want to call and what I do for my other devices (often I have to write that interface). And I want to call this from javascript and stay in that environment.

Answer - some others are doing this. The other post I will look for which might provide some insight. I don't do things this way, but I remember reading that it is possible.

And here is a very basic question that might help me understand overall how things work. To me, I understand that Builder allows you to specify all the connections (because you could connect any motor to any I/O) and allows you to tune the motors to specific initial settings, right?

Answer - Yes, you can connect almost anything you would like to the EZ-B that has a Digital, Analog, I2C or serial interface. The thing that you have to remember is that the Real Time Clock isn't on the EZ-B and would have to be handled by your application. Something that requires very accurate timing (like a neopixel ring) couldn't be used directly from the EZ-B with real good success. I and others have used a serial or I2C interface to an arduino to handle this because the arduino can handle these critical timings. Another option is a PIC.

In the videos, you show some amazing motions, such as the robot getting up off the ground. How and where is that logic?

Answer - This is reading a device on the EZ-B and the logic on what to do in different situations is happening inside ARC on the PC.

Does builder allow the user to somehow choreograph motions and record them for later play back? Or does the creator "script" each and every motor move and then get those assembled and timed correctly all in the scripting language?

Answer - There is an Auto Position control in ARC which allows you to setup frames which are movements to specific locations. These frames are combined into actions. For example, stand up could have 20 frames of movements (multiple servos at one time) which are then added to an Action. You would call an action, which would run through the frames. This can be scripted if you would like to do that.

Is all of that motion "running" in the Host or is the host remote-calling some mini-execution environment/program downloaded to the device?

Answer - All of the logic is running on the PC and is sent to the EZ-B. There is no way to run any user code directly on the EZ-B.

I would rather not "build" a C++ project or anything like. I'd rather call the API from my own javascript, and/or use javascript libraries that provide an interface. I'm willing to provide the latter if need be because then it fits into my overall control scheme well and I would LOVE to support this robo.

Answer - There currently isn't a Java implementation of the API that is supported. I don't know what UniversalBot SDK would do yet as I am waiting for a couple of things before messing around with it. Let me see if I can find the other post. I will add it to the end of this post.

Post that might interest you. Disregard the majority of the post. It seems like the user got frustrated and then tried to point fingers or something. I didn't read the entire thread. If you ask, as you have seen, there are many users who will try to help or point you in a direction to get help. It looks like this guy tried and got frustrated and then left. The help had started to come in but whatever.

I do hate that I had to send you to a post that contains a very rare situation on this forum. Please don't hold it against us

It is discussions like this one that greatly expand my understanding of, and potential uses of, the EZ Robot environment.

Keep up the great work d.cochran.

Hi and welcome to the forum! The EZ-Robot approach is quite different than an Arduino/micro approach - because we work at a higher level. Assume that you want to make real robotics (such as darpa style or honda asimo, etc). You would need to develop the platform architecture which we have already developed. Leveraging the processing potential of your controlling device (ie PC or iOS/Android).

If you are a rare breed coming from micro programming, then it might be a little difficult to wrap your head around. Generally our users are either R&D facilities, newcommer hobbyists or education - with no prior micro experience.

I can, however, assure you that ez-robot will blow your mind and you would enjoy it a lot

I copy and pasted this from here: https://synthiam.com/Community/Questions/7844

Quote:

The EZ-B is dumb. It is a IoT-like device that just sits there waiting for commands. The actual program runs on your device (pc or mobile). The concept was inspired by seeing advanced robots, such as Honda's Asimo and other Darpa robots. This is because unlike all the arduino "robots" and stuff out there, those Asimo-style robots were doing amazing things! And I wanted people to do amazing things. So EZ-Robot is somewhat of a clone of the laboratory grade robotics strategy, with offloading the processing to a more powerful device to produce real robotics. This comes with a slightly different approach to programming.

Unlike an Arduino or microcontroller, you're programing the computer/mobile and not the ez-b. So every time you ask the ez-b to do something, it's being done over a wifi communication using TCP. If you're REPEAT has ez-b commands in it, then you're asking the computer to do a huge pile of work which explains why the experience is different. Once you send data to the ez-b, there's a zillion things happening - specifically the TCP protocol waiting for an acknowledgement that the ez-b has received the command.

This approach makes EZ-Script appear slow - when it is actually doing way more than python or c++ when sending a command to the ezb v4.

Now you're question could have been easier to answer if you asked something like.... "why can't I flash an led 5,000 times a second or write to a neo pixel with Set() commands like I can with Arduino in a Repeat loop?"

Well, that answer is simple and you may need to re-read my entire response again to understand. But ez-robot is not a microcontroller. You can use the ez-robot as a controller to leverage the single-use high-speed instructions of a microcontroller such as arduino, ARM or Microchip PIC.

In short, EZ-Script is very very fast and efficient - however, what you're doing with it matters, such as communicating to an ez-b v4 over a wifi tcp connection

The last part I need to touch on since you're asking about how programming works is threading. Notice I'm unable to do much comparison with C++ or python because the question is wrong. That's like asking what is faster, the space shuttle or a bicycle? The question doesn't make sense due to the nature of "what you are doing with it". C++ will always be "faster" but than practically anything, unless you understand how to code in assembly more efficiently than the C++ compiler can compile to opcode. This is where the problem with your question arises because it introduces programming abilities into the equation, and why the question doesn't make sense.

Many people will answer and say well obviously c++ is faster than python, but that answer is lacking real-world scenarios that make the question irrelevant in the first place. Because the space shuttle will be much slower than a bicycle if you were behind it's console not knowing how to drive the thing, it most likely wouldn't move... leaving the guy on the bike plenty of time to cross the finish line.

Now back to the ARC way of programming. It's process driven with a multi-threaded approach that is handled for you. This is the most important statement, because multithreaded app development which scales as large as ARC offers in C++ is an absolute nightmare that may put you in the crazy house. ARC handles the multi threading approach for you, without you needing to know anything about it... hence, saving your sanity.

Each control that you see is a separate thread. And each control shares a communication channel to the ez-b, as well as each other. The ControlCommand() is what connects controls together. But each control must run at a managed speed to share resources AND not run faster than another. So all controls are speed limited with a heartbeat that keeps them in sync. This prevents one control from dominating the CPU and leaving your robot unresponsive. So in some cases, EZ-Script or something will appear slow but that's limited by design because it means something else you're doing is causing slowness - such as maybe your computer isn't fast enough for camera tracking.

I never ever ever want to provide a microcontroller programming ability. I never want to be involved in anyone programming a micro directly. This doesn't mean I don't encourage people to - I simply do not wish to participate in teaching people how to flash an LED with arduino because there are already 25 zillion options out there to learn that. Instead, I want people to use one of the 25 zillion options and learn how to leverage Arduino to be used with ez-b. There's never been a fight between ez-robot and Arduino, because they are different things. We're the Engine and Arduino is a Wheel.

Now, don't get me wrong - just because ez-robot doesn't have a fight with Arduino doesn't mean that Arduino doesn't have a fight with ez-robot. That's a question you would have to ask those users, even though we have absolutely nothing to do with microcontroller programming - nor do we care to. What we care about is providing the high level tools to connect Arduinos, sensors, motors, cameras, etc... together to make robotics actually do something.

I did go a little off topic, but that's a little due to your actual lack of question because you're question implied a lack of programming understanding means the answer is much bigger!

FANTASTIC! Now we are getting somewhere, and somewhere fun!

I think I "get it". See if I'm correct:

• From any IP host, I can open a tcp/socket to the EZ-B port 23.
• To start a dialog, I have to send byte 0x55
• I then send I/O commands where are port-then-value
• I can do do many of those
• I ultimately close the socket

Questions that are important to me:

• Are all the values single-byte?
• How can I "read"?
• You must have a full list of all the commands/ports/values...?
• I assume the motors run near-instantly and not block
• Thus, is there any query to know if motors are stopped/completed?
• Is there a way to tell a motor to move forever...until I tell it to stop?
• One of the notes say 0x55 is responded by 0x04. Are there are other responses or a full list of the dialog?
• Does it ever send data without solicitation? Alert/error/alarm etc?

If I can get the above, I can map this completely into my open-source javascript/html robot stack. http://www.meaowmeaow.com and I would LOVE to support this. Can I get a system on short-loan? A few weeks?

This will help you the most - here is the open source package UniversalBot: http://synthiam.com/Products/ARC

With UniversalBot, all of the commands are provided in code examples.

As for a loaner robot, sadly we do not have spare units even for ourselves. We have a backlog of EZ-B's and robot orders due to purchase demand. Our manufacturing facility is working long hours to catch up - meanwhile, we are looking for new facilities which can help us scale.

MeaowMeaow looks like it will be a fun project

This thread is great! Direct answers about the programming innards. I'm copying it all into a file for later reference.

Perhaps now would be a good time to ask I question I had asked before but did not get an answer to. As I understand it, the values representing the position of the servos are simply stored in ARC based on whatever position command was sent last. When a GetServo() instruction is sent, all you are doing is reading the stored value in ARC and not a value directly from ezb. Therefore no communications with the ezb is needed to execute that function. Basically there is no way currently to verify the actual mechanical position of the servos.

The question is concerning the getting of the values from the digital and ADC ports. Are those values recieved directly from the ezb when calling a function such as GetDigital(), or GetADC()? It would seem to me they would have to be directly from the ezb, but wadda I know. Thanks.

That answer really depends on the type of servo. If digital servos are used, no, you cant read the position of the pot inside of the servo. This logic is all run off of the controller board in the servo. You send a signal that tells the servo what position to move and the controller board inside the servo then moves until the pot inside the servo has reached that location.

If you used a motor with the pot connected to an analog port, you would be able to do this but you would be bypassing the controller board in the servo.

Digital ports only return back high/low logic. Analog ports can return back variable data. This limits what you are able to read from the port.

There are other solutions to this also. For example, you could connect a pot to an analog port and have it monitor the position of the servo, but then you would be getting the information from the analog port and not from the servo itself.

WBS, the LEARN section is a valuable resource for information. It can be accessed by pressing the menu labelled LEARN from the top of this website. That section will show you the percentage of courses that you have completed so you may keep track of your progress.

There is an activity specifically on How Servos Work. A servo is a one way communication. The EZ-B can never know the position of a servo by asking it. The EZ-B only knows the position of a servo because it is telling it. And the EZ-B only knows how to control the position of a servo from ARC. So therefore, the answer to your question is always ARC.

For more information, use google to research how a servo works and view our activity tutorial: https://synthiam.com/Tutorials/Lesson/48?courseId=6

@WBS00001 I get what David is saying.... if you want absolute position of a typical hobby servo just open it up connect 3 wires to the pot and run it to the analog port of the ezb... To be honest not sure why you would want to, though... I trust my servos to move to their correct position and 99.99% of the time they do... Unless the servo is faulty or restricted somehow they will move to the position they were told to.... You could use dynamixel as they will provide position feedback....

I totally agree Richard. Not really suggesting it, but more trying to show the difference between analog and digital I guess.

@David.... You know after the fact I wish I had paralleled the external pot wires of my inMoov's large servos and ran them to the analog ports of the ezb.... I mean since I had the servo open anyway.... That way I would have 100% servo position confirmation....

By the way dude... you are freakishly, seriously smart.... Thanks this is awesome info....

@WBS00001 To sum it up servos in general are one way communication (unless you hack them or use dynamixels) regardless of what microcontroller or robotic platform is controlling them...

LOL, Actually, I was thinking about doing this. All of my pots on my large servos have 3 pin connectors on them. I was thinking about running them to analog ports as I have multiple ports available. It would allow me to say "hey, you are not in the right place" and tell the servo to move again. It wouldn't be hard to add the splitters that came with these servos to these and use them to connect to analog ports for monitoring. I just have to get time (and money) to get back to this project.

Thank you all for your responses, unfortunately all the posts were directed towards the servos. I only mentioned them as a lead in to my actual question. That is: The question is concerning the getting of the values from the digital and ADC ports. Are those values recieved directly from the ezb when calling a function such as GetDigital(), or GetADC()?

@WBS00001 Those values are, so the answer is yes...GetDigital and GetADC are read values from the ezb....

Just so that we are clear, you can't use GetDigital() and expect to get the value of the pot that is in the servo. You would get a 1 or 0 depending on if the servo is resting or active. This is the reason for the answers that were given. GetADC() would allow you to get the value of the pot based on how much resistance is currently being seen by the pot but this would require the pot to be connected to the analog port.

You can query the analog or digital port as often as you would like. If done too many times or too quickly, you will saturate the bandwidth of the wifi communications link between the EZB and the ARC software. If I remember correctly, this was where you asked the question before. The ARC software would query the EZ-B for these values and return them to you to use in the ARC software. The question originally can from using the WaitForChange command I think. The WaitForChange command doesn't have any delays built in so using it for querying the EZB for changes could be detrimental depending on how it is used.

@Richard R Thank you for your quick response. That's what I thought but, as I have found out, things are not always as they seem. The reason I wanted to know for sure is in regards to traffic on the wireless link between the PC and the ezb. Getting a servo position doesn't require any communications traffic whereas getting a reading fron the Digital and ADC ports does. And does every time they are called.

EDIT @d.cochran Thank you as well. Just saw your post. I guess I wasn't clear in the fact that I wasn't trying to somehow read servo position using either the digital or ADC ports. I can see why there was confusion. Sorry about that.

@WBS00001 you are correct.... since you can't ask a servo to give up it's position there will be "no receive traffic" on the wireless link only sending in order to move it to a position... However, asking the analog or digital port "hey what's up" requires "to" and "from" wifi communication....

All good. Glad you got your answer. I am also glad that you are grasping where things are happening. It sure makes programming a lot easier and more efficient. Good job.

Good responses. The last couple of robots I was using were wheel-type and you would tell it to "move forward" and not usually with a distance nor rotation. Keeps going until you STOP (typically you are monitoring an I/O, like distance, heat, table edge, line on floor, etc). So that probably doesn't really apply here

I've looked through servors.cs and EZB.cs a bit and I see the table (of sorts) of commands (which are colored by increasing their value for the port you want) and then a position/value.

I'm still unclear about what to expect for a response and if it is necessary that I wait for the response and can I keep sending commands on the socket or do I have to close it before they go?

I've written my javascript executioner for a few robots and want to do it for this one as well. It is SO cool to use java script (in a real web page) to control robots...all naturally asynchronous and easy and a full language. If anyone else is interested, that might help incent me to do it for this one as well.

It would be swell if there was a low-level communication guide for this robot (and I dont think it is all that hard to make...not too many commands). I haven't looked at sound and camera yet...those could be more involved.

One more question: I haven't used the builder or the "frame" stuff mentioned, but once you've built frames/actions, what steps through that? Is the host calculating all the motor positions and setting the servos and stepping or is any macro-script sent to the beast?

The way that servos work is that there is a pulse sent to the servo of a certain length, which indicates to the servo what position it should move to. The board on the servo handles checking the pot and determining how fast or far it needs to move. The host sends the signal to the EZ-B to tell it to send a pulse of a certain length to the servo.

I hope this helps.

Also, on the website development side, you can connect to a custom webserver on ARC and change the code on [edit]the website[/edit] to be anything you want it to. This web server exposes [edit] most of the features [/edit] of ARC including the camera. I know its not exactly the solution you are looking for, but may be worth investigating. I believe that this would allow you to use javascript or any other web based language to control the robot. Calling scripts or actions within ARC becomes very simple.

One more piece of information... No, you wouldn't have to wait to get a confirmation back that the action is complete with servo movement as there wouldn't be one. The servo (hobby grade) doesn't report back that the movement has completed. You can send a second command immediately after sending the first to move the same servo or a different one.

[edit]

There might be an acknowledgement from the EZ-B saying something like "Command Received" that you might be able to check for, but DJ will have to answer this.

[/edit]

Quote:

Good responses. The last couple of robots I was using were wheel-type and you would tell it to "move forward" and not usually with a distance nor rotation. Keeps going until you STOP (typically you are monitoring an I/O, like distance, heat, table edge, line on floor, etc). So that probably doesn't really apply here

Just so you know, you can do the same thing with the EZ-B as far as monitoring output. It just happens on the host and not the EZ-B. For example, you can tell the robot to go forward until you get a reading from another port (analog, serial, i2c, digital or Camera) of a certain value, and then stop the robot. Some people believe that this is slower than having things run onboard the controller. I haven't found a situation yet where this has been any sort of issue. It works very quickly. I just wanted to make sure you knew that this was possible.

@d.cochran

Quote:

The way that servos work is that there is a pulse sent to the servo of a certain length, which indicates to the servo what position it should move to. The board on the servo handles checking the pot and determining how fast or far it needs to move. The host sends the signal to the EZ-B to tell it to send a pulse of a certain length to the servo.

All servos have pots inside of them. It is how the controller board tells the position of the servo. By controller board, I mean that it is the controller in the servo. The servos are connected to a digital port. The digital port only has the ability to be high or low (on or off). The command is sent from ARC to the EZB which says to tell the servo to go to position 90 for example. The EZ-B then sends a pulse of electricity to the controller board in the servo of a specific length, which the controller board then interprets to mean "Go to position 90". The controller board in the servo reads the pot location and determines the direction and speed that the servo has to turn to in order to achieve this position. There is nothing sent back to the EZB or any other controller saying "I am at position 90". This is all controlled within the servo.

You can bypass the controller board in the servo and run power directly to the motor in the servo, and attach the pot to an analog port, which would allow you to read the position of the servo.

All of the parts are there as far as hardware except for the feed to an analog or serial port to tell the location of the servo. It just isn't how hobby grade servos are made to work. There are higher end servos that do have this communications port available to tell the location of the servo. These are called Dynamixel servo (smart) motors. This too can be controlled by the EZB. These do tell you their location without having to hack the hobby grade servos.

BTW, this will get clear as mud when you start using Ping sensors which are also Digital. You can tell distances with ping sensors which goes against all logic of how a digital port is setup to work because distance is variable.

Ping sensors are unique in that they use 2 digital signal ports. One is to tell the sensor to send out a ping, and the other is used to catch the ping. The difference in time from the send to the receive is actually what is being measured. The digital ports are still just sending a pulse and reading a pulse. There are calculations on the host to calculate distances. This often blows my students minds and they struggle with it because it is a digital device returning variable data. Digital isn't variable, only on or off, but when you understand what the device is doing, it is understandable.

@WBS, it is a good idea to visit the LEARN section of this website and follow the tutorials. There is a complete tutorial on learning how a servo works in the learn section. It will explain how a servo works so you may better understand. Do not over complicate EZ-Robot. The EZ in EZ-Robot stands for EASY, but it's spelled different - which is kind of a slang. The EZ part means we have created a platform which performs the complicated parts for you. The idea of making a robot is the function which it will perform, not the silliness of communication and moving servos, etc.. You should never need to care about how that works or why it works - just accept that it does like you do with 99.9999% of everything else you do on your computer today.

I can answer questions that you may have of how it works, but the priority is to get you building robots

Here is a direct link to the tutorial of how a servo works: https://synthiam.com/Community/Tutorials/48

@stakutis, i would also recommend that you follow the above tutorial to understand how a servo works.

The EZ-B takes care of holding the position of the servo for you once you tell it what position to hold. You only need to tell the EZ-B one time to do something, not repeatedly.

You send a command to the TCP socket of the EZ-B v4 and it performs the function. There is no response, unless it's a return type command. If you need to understand more about how TCP works and why a completion response is unnecessary, i would recommending googling. TCP stands for CONTROLLED communication, which you can rely on it for connection verification. Unlike UDP, where there is no verification that the command had been received by the host.

Some networking tips is to start learning about the OSI model and where TCP lies on the layer model.

However, knowing any of that is unnecessary to use the EZ-B v4 - but if you're asking those questions, it will help.

Thank you all for your explanatory posts.

Before I begin, however, let me just say ... MY JD ARRIVED TODAY! <imagine large group singing the Hallelujah Chorus and left over July 4th fireworks going off>

@DJ Sures Spent several hours going through all the JD tutorials (calibrating and fine tuning to boot) and getting it to work, which it does!

The only thing I had a problem with was getting it into WiFi client mode. My computer just won't see any other networks and no USB wifi adapter I tried will work with it. Anyway, I managed to use my tablet by downloading the mobile ARC app. and connecting to it in AP mode that way. Then set it to client mode via that app. Then used my Router setup program to "discover" it and give it an IP number which I typed into in the PC version of ARC (in place of the default of 192.168.1.1) to connect to the ezb via my PC.

Once I did that it connected to the ezb, no problem. And the ezb connects to my network every time I turn it on. So that's good to go. Thing is, it won't hold the IP address I type in. I have to type it in every time I start ARC. Is there a way to make it permanent? Didn't see anything in the tutorial about that issue.

EDIT Nevermind. I just started ARC again and the IP address was there. Must have forgotten to save it or some such the previous time. Sorry.

Also, FWIW, among the extra parts I ordered with my JD kit was an extra body. I noticed that the orientation of the on-off switch was opposite one to the other. I don't know if this is any big deal to you, but I thought I'd mention it. To me it would be good if they were all inserted the same way so people get used to flipping the switch the same way regardless of the body used.

The orientation of the switch is a big deal to me - thanks for the feedback

I'm at my cabin on holidays (yeah right) and we had all the neighbors out here on the beach playing with Six and JD this evening. They loved it! For a bunch of old dudes who have no idea how to use technology, they rocked the robots all evening!

@WBS00001 I have a few ezb4s... Some I have set static IP addresses for and some I have left random.... If I forget an IP for a particular ezb4 I just use the scan tool (you need to be in client mode to do this) until the ezb chimes then select that IP.... which btw automatically gets copied to the connection control....

@WBS00001,

Another way, if you are familiar with your router/Wireless access point is to look at the dhcp leases that have been handed out. I use a class C network structure at my house and assign my EZ-B's to their own range by doing static leases on their IP addresses. What does this mean?

10.0.0.X is my server and network device range 10.0.1.x is my pc/cell phone/whatever range 10.0.2.x is my guest wireless range 10.0.100.x is my EZ-B range.

My robot that has 5 EZ-B's on it uses 10.0.100.1 10.0.100.2 10.0.100.3 10.0.100.4 10.0.100.5

This allows the search through ARC to quickly find these devices if I have to scan for them, but because I use static leases, there isn't a chance that my router will do something silly and change the IP addresses on these devices by issuing a new lease to them.

I have also changed the names of these devices so that I know what they are. Head, right arm, left arm, body and base. This lets me know which one is which when I forget. It would be just as easy to make the JD, Six, Roli or whatever your robot name is.

I say all of this because you are a technical guy. You might already know how to do all of this on your router. If you do, it makes things a bit easier. If not, I wouldn't mess with it until you have an understanding of the workings of your network. Just wanted to throw it out there.

@d.cochran Thanks for the suggestion. Your post got me to thinking about my growing list of net devices,"My Cloud" drive, cell phone, tablet, Wink propane level monitor, TV, Blu ray player, alarm and home control/monitor system, and now JD. Up until now all I've done is some DHCP reservations and having a large number in the Client Lease time. It probably is time I look into static leases and sectioned ranges. Especially since, like you , I plan to have multiple EZ-Bs going simultaneously. Not to mention additional devices in adjunct to the EZ-Bs.

@WBS00001 If you are going to be running multiple EZ-B's, be aware of this bug: https://synthiam.com/Community/Questions/7229

It doesn't seem to impact everyone, so I think if your router is very fast at responding to DHCP requests you won't see it, but if it is a little slow, you will. If you get EZ-Bs powered up after the first one that seem to get different addresses than you have reserved for them, this is why. All the more reason though to give you EZ-Bs their own subnet.

Alan

Ok, I'm trying to use the (custom) http server to see how it talks to the robot over the wifi. I'm confused plus it seems like another layer i'd rather not introduce (although I think it was pointed to me because I could learn how it talks to the robot).

I see the html code has special "EZ" css and calls url's like "/forward.cmd". I suppose that is what I want to look at but I dont know where to find that http server code (i presume that forward.cmd is not a file but rather absorbed by the server).

I really just need a dirt-simple example of all the commands I can send and how to get responses. For motor control it looks pretty simple (send a byte, send another byte with a position). I dont know how to do I2C controls and camera and sound...

@Stakutis

The HTTP server still requires ARC to be running and handling the communication between the PC and the EZ-B. It just provides an easy way to develop a custom UI (among several other methods, .NET SDK, Universal SDK, Mono SDK, Open Bot (no longer supported by its developer, but open source and DJ has said to another Linux developer who needed a very small footprint that he would help to update it, also , since it is open source, you can view the source code and see what it is doing, just be aware it was written for a previous version of EZ-B so handles a few things slightly differently (less digital and I2C ports, no UART, Bluetooth instead of Wifi connectivity).

Since what you seem to want to do it bit bang directly to the EZ-B without using any of the SDKs, the best option is probably to run Wireshark on your computer, filtering on port 23 to capture and analyse the packets when you send a command from ARC to an EZ-B.

Why you want to big bang when there are so many simpler ways to communicate to it I don't really understand. If that is what you want to do, you are probably better off with an arduino or a Raspberry Pie with a GPIO breakout since by eliminating all the software that supports the EZ-B you are losing most of the power of the platform, but to each his own....

Alan

stakutis,

No matter what, you will have to run a machine. This machine will send the commands to the robot as has been stated many times. There is no code that you can write that can run directly on the controller. This is a good thing. Tethered robots are the only way to build advanced functions in a robot.

If you are going to use the ez-b, you have to have a computer running. If you have to have a computer running, why wouldn't you use the tools that are available, even running in the background? Your interface or Web page can be running and sending commands to ARC which can then control the robot. You can spend your time making the robot do amazing things instead of trying to figure out how to make a servo move?

I'm asking all of this seriously. What do you stand to gain from the path you are trying to take? What do you stand to gain from what I just described?

@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!