[Solved] Linux side for Complex Calculation

[Solved], but still Open for more suggestion(s).

I know the title sound vague, so let me re-clarify it.

Goal: Apply SLAM algorithm on Yun based 2WD Robot.

Current Aim: To have Linux side handles all the complex calculation while Arduino side handles motor control. To illustrate, it should look something like

Arduino -> Feed Sensor Data -> Linux -> Process Data -> Return Result -> Arduino -> React base on Result

Problem: I'm sure some of you are aware the Yun's Arduino Side has memory limitation being only at maximum of 28kb, even a simple "Blink" sketch can easily take up 4.5kb/28kb; Hence numerous of time I'm forced to limit my function in a sketch.

Current Solution: At the moment, I have created a HTML based webserver which utilized JavaScript for calculation and returning the result to Arduino. Example:

$.get('/arduino/analog0', function (data) {

I'm not sure how feasible this solution is and I'm hoping for more constructive suggestions.

Thank you :)

rayz93: Arduino -> Feed Sensor Data -> Linux -> Process Data -> Return Result -> Arduino -> React base on Result

The simple solution for this data flow is the Process class in the Bridge library. You would collect some sensor data, and start a Process object with the name of your Linux side script, passing the sensor data as parameters. The Process object starts the script on the Linux side, which processes your data and generates some output. Back on the sketch side, your sketch reads the output from the process and acts on it.

You don't mention the nature of your data: size of a sample set, and frequency of collecting/processing data. The above scheme would work if you have distinct "batches" of data, and not at super high data rates. That's because there is a certain amount of overhead to pass the data between processors and start your script each time.

If you need to process a continuous stream of data, and/or need high data rates, another method might be better: perhaps a socket stream, or forgo the Bridge library altogether and do your own serial passing between the processors (use the Serial class on the sketch side, and talk to /dev/ttyATH0 on the Linux side.)

If you have lower data rates, and don't want to start a new process for each sample batch (making it easier to preserve state information) you could start a process asynchronously, and use Bridge.put() on the sketch side to pass data items to the Linux side. The Linux side could then use Bridge.put() to send data back, or use Mailbox, or just return a stream of data through the Process object that called it. Bridge.put() has the advantage of being fairly low overhead, but it works like a shared variable: putting and getting values from it is asynchronous, and the getter can only see when the value has changed -- if the same value is put() twice in a row, the getter will not see the second put. Mailbox has the advantage of being a FIFO queue, so that messages written to the mailbox will always be received in the proper order, including duplicates. But it's higher overhead, and only works one way -- from Linux to the sketch.

There are a variety of ways to do it. The ideal way will be dictated by the size of your data samples, the sampling frequency, and the amount of returned data.

rayz93: ::::SNIP:::: I'm not sure how feasible this solution is and I'm hoping for more constructive suggestions. ::::SNIP::::

@rayz93, ShapeShifter has a great starting place for you. However, robotics projects vary in goals. You've got a nice idea to use SLAM, and typically it's a favorite among the hobbyist in Silicon Valley, and many robotosist like it. Here are you limitations:

  • SLAM has been effective in many small projects - including two wheel bots
  • ROS - which includes the leading SLAM implementation - is written in Java
  • SLAM was written by graduate students - intelligent, bright, but inexperienced
  • Java implementations are typically bloated - SLAM no less
  • when project run against the Java or SLAM wall of inadequate resources, they have to redesign

On the last part (the wall), I can say this for my time in Silicon Valley and the Homebrew robotics. There I watch PHd people and hobbyist alike run against this wall. As such, my advice is jump-in make mistakes, then pivot as quick as you can, do NOT try to overcome the natural obstacles - like insufficient RAM.

Lastly, the best implementations of SLAM I witnessed used very large powerful Intel motherboards, which might serve better as heating elements.


Ah, I see. Now I'm starting to have second thoughts about SLAM on Arduino xD

I'd better research more before implementing anything.

Either way thank you, both. :)


I'm going to recommend a design I've seen work, but was scrapped by the development team because of a peripheral goal. The goals was to do facial recognition with OpenCV, hence the need to scrap the design and go with an Intel heater. The group was working out of the Hacker Dojo, and had one of the better designs (that include brushless pancake motors).

The design include a custom voltage control for the motors. And visually the motor was very similar to this http://www.alibaba.com/product-detail/brushless-pancake-motor_1637696968.html BUT the motors and tires were integrated. I don't have a number or maker for this.

The motors were driven with an Arduino Uno . The bot had two (2) rear wheels to drive, and two front caster. They had issues with weight distribution (because it was so light) and had constant voltage problem (mostly because they drove the wheels with the wrong voltage, 12V or 24V, I think.)

Collision avoidance was primarily handled by sonar, but it also used a Neato lidar to steering. The steering, control and user Interface was handled by a Raspberry Pi (although any good ARM processor would do).

What they end up with what was a classic MCU or CPU at major control points (motors), and the most powerful CPU was the defacto controller. Also the majority of the UI issues were shoved out to a laptop, PC or multi-core tablet.

Best of Luck, write back if you have questions.