stakutis
USA
Asked
— Edited
Resolved by CochranRobotics!
I have yet to buy my first one and am curious about the programming model. I can't tell if you write programs that run on the device, or run on a host that talks to the device, or both.
And I'm not sure what the platform is. It *looks* like a lot more powerful than an Arduino (which is slow and low memory), but I saw some post that made me think otherwise.
I want to write my own code that runs on the device and that supports my own interface to my own host where I control many other types of devices. How possible is it? Or, to do the more complicated moves do I have to use the GUI tools?
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.
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.
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://www.ez-robot.com/Tutorials/Lesson/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.
Before I begin, however, let me just say ...
@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.
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!
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.
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.
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
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...
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
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?
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.
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.
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.
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
*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.
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.
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?