Yun based robot

Greetings all,

Background/what has been done already: I have been building my robot with quite a bit of success. It is to the point where I want to see what is going with my robot in near real time as its operating. To start, I wanted to have my six sensors (3x ultrasound rangers, 1x compass, 2x encoders) display on a web page hosted by the Yun. I DID get this to work using standard Rest interface via zepto .get commands. All my sensor data populates and updates on the screen as expected.

Problem: The problem I am running into is that when the page is up and active, the robot's performance drops to a crawl! My pings go from several a second to about twice a second. Given the fact that no other processing is happening, I am very concerned that this dramatic performance hit will render the robot nearly useless.

Research: I have seen several people talk about related issues, more specifically more efficient methods of communicating sensor data to the Linux web server. In my case, since I don't need a real time interface to/from the web page, making use of the Mailbox functionality sounds like the solution. With this, I can have the Arduino send all the appropriate information to the Linux side so that it can then be parsed and update the web page. There are some examples out there on how the arduino side can send and process these messages, but...:

Need: I would appreciate it if someone could provide me an example of how to: a) Send a message from the arduino to the Linux side (Solved) b) Parse this message on the Linux side c) Update the web page with the proper information d) and in the near future have the web user initiate a command from the page and send that back to the arduino (Probably use Rest for this)

Thanks in advance!

Erik

Vulchikova: The problem I am running into is that when the page is up and active, the robot's performance drops to a crawl!

If this were my project I would do as much as possible of the project, (especially all of the web code) in Python on the Linux side of the Yun so as to minimize the burden on the Arduino side. The Yun is normally portrayed as an Arduino with a Linux system attached and under its control. I prefer to think of the Yun as a Linux computer with a Leonardo slave attached to it.

You may get some ideas in develop on PC deploy on Yun

...R

How are you serving the web? Php, node?

@Vulchikova, Robin2 is giving you sound advice. I used to work at a robotics company. This is what I can tell you.

You have a small pipe coming from the Arduino side of the Yun. That pipe can a most do 250kpbs. It is a serial port. As it is you have 5 sensors worth of data you want to process, and want it to be bidirectional communication.

In short, you have already done the hard part, you have made the pieces work together. What you need to do next is optimize the data processing so it is useful to you.

I would suggest instead of using the mailbox, just have the Arduino-side dump all the data to the Linux side, have it do whatever processing it needs, and ship the data to another processor (possibly a PC, Laptop or mobile device - like an iPad or Android) for visual processing.

For what it is worth, you will want to use Python or Javascript (via nodejs) to read your data, and the processing on the Linux side. Then once you have a stable platform move to C or C++ - which will give you better performance. Also, if those scripting languages do not work for you, others are available for the Linux-side of the Yun.

I hope this helpful. If you have more questions, please ask. Jesse

Vulchikova: Problem: The problem I am running into is that when the page is up and active, the robot's performance drops to a crawl!

As you discovered, the REST interface method is not ideal for your application: whenever a request comes in, the sketch must stop what it's doing to parse and process the request. This can be inefficient. I think you are on the right track to off-load the web processing to the Linux side.

In my case, since I don't need a real time interface to/from the web page, making use of the Mailbox functionality sounds like the solution.

I disagree. My understanding is that the Mailbox class implements a type of guaranteed delivery message queue. This isn't necessarily what you want here: it's not important that every update make it out to the web page, you really only need to display the latest update.

I agree you want to periodically send data from the sketch to the Linux side. This data should be sent all the time, not just when the web page is requesting it. Send it at the end of each pass through loop(), or send it once a second, or something like that. Then, the Linux side should handle all of the web processing with no further involvement from the sketch.

I see a few ways to do it of of the top of my head. This list is ordered from the easiest to the hardest, but it's also what I believe to be the highest overhead to the lowest:

1) Bridge.put() - the sketch periodically calls Bridge.put() to send the data to the Linux side. You can write Linux side code to read and process the data, and update a web page, but you don't need to do that. Instead, some JavaScript on the web page can make a request to http://arduino.local/data/get to read all of the put() data as a JSON object. It's pretty straightforward for the JavaScript to parse that and populate the content of your web page. I think I have an example somewhere if that route sounds interesting.)

2) Process class - the sketch uses the Process class to start a Linux side process. Then, it periodically calls the write() function of that Process object to send the sensor data. The Linux process (probably Python?) then reads from standard input, parses the sent data, and updates some variables to track the latest values. You then need a CGI script or some other process that can get called from the web server to read and return that data. (A more experienced Linux programmer will have to give some shared data advice on how to do that.)

3) Raw serial - this is very similar to option 2, but bypasses the Bridge library completely. The sketch opens Serial1 and periodically sends the data. You will need to write a Linux process that is automatically started at boot time, which opens /dev/ttyATH0 and reads the serial data from there. The rest is the same as option 2.

d) and in the near future have the web user initiate a command from the page and send that back to the arduino (Probably use Rest for this)

REST is an easy way to do it, but once again the handling of the request and parsing of the data will slow down your sketch. Another option is the Mailbox class: this is an appropriate use for it: it offloads a lot of processing to Linux, and the sketch need only poll the Linux side occasionally to see if a message is available. You could also do it with Bridge.get() but Mailbox would work better in this case: if you send the same message twice, you will still get both messages, which is not necessarily true with Bridge.get(). Basically, the web page makes a request of the form http://arduino.local/mailbox/xxx, and the sketch can read the messages using mailbox.messageAvailable() and mailbox.readMessage(). See the Mailbox example.

Using REST, Bridge.get(), or Mailbox is compatible with options 1 and 2 above. If you go with option 3, then you will need some sort of CGI script on the Linux side to handle incoming requests from the web server. This will have to forward the request to the Linux process talking to the sketch, which will send it to the sketch where the sketch can parse it and act on it.

Put some thought into the design, pick one of these methods (or another) to try, and I'm sure you can get some more detailed help if needed.

@Vulchikova, Shapeshifter make some good points. You might consider a new thread with the title "Bridge Replacement". We do know that there are bridge replacements that people have worked on. In addition, I have a partial list via bookmarks at this URL

http://codesnippets.altervista.org/documentation/yun/bookmarks/projectsNsoftware/projectsNsoftware.html

Jesse

All,

I was able to get my information over to the Linux side with little processing overhead using Bridge.put(). This is working beautifully now. Thanks for all the advice, especially ShapeShifter. Now that I have my data populating the web page, its time to move on to far more interesting aspects: sonar data processing to create suitable map data, implementation of a good navigation/path finding routine, and some basic core logic.

Good work, thanks for the update.

Vulchikova: its time to move on to far more interesting aspects: sonar data processing to create suitable map data, implementation of a good navigation/path finding routine, and some basic core logic.

Yes, that does sound like it will be interesting and fun!