7
$\begingroup$

I know this is a broad statement, but when you've got support for both TCP as well as a full fledged computer on board (to integrate/run an arduino), does this essentially allow for anything that would run on a linux box (raspberryPi) to run and operate your robot?

I know clock speed as well as the dependency libraries for a given code base (on the Pi) would add some complexity here, but what are some of the big issues that I'm overlooking in such a vertically-integrated control system?

Including a RaspberryPi within a robot... Does this allow for a "universal API"?

| improve this question | |
$\endgroup$
  • 1
    $\begingroup$ I believe it is basic StackExchange protocol to repeat important information from your title in the body of the question. That way, someone won't miss important details. $\endgroup$ – DrFriedParts Dec 1 '12 at 10:44
  • $\begingroup$ Side note, use comma before but, instead of .... $\endgroup$ – Shahbaz Dec 2 '12 at 12:40
  • 2
    $\begingroup$ I'm a little worried that within a given topic, this is actually being brought up Shahbaz. I just hope you're not on S.O.'s payroll as this literally qualifies as trivial to the point of " you should not even mention it " . $\endgroup$ – carl crott Dec 4 '12 at 1:03
10
$\begingroup$

The short answer is "yes". I'm assuming you are describing an architecture that looks broadly ;-) like this:

Real-time system <--> Soft-time system

This is a very common robot architecture.

The real-time system (RTS) (for example, an Arduino with appropriate firmware) handles the low-level sensor farming (conditioning, data packaging, management, and routing), power management, motor management, and general purpose I/O operations.

The soft-time system (STS) (ex. the Raspberry Pi you mentioned) is a more powerful system designed to handle monitoring, long-range communications, and more elaborate sensor integration and processing tasks. It sits above the RTS, which handles all the intense timing details of waveform generation and low-speed local bus communication so that the STS can work the "harder" problems.

Obviously, this is a big over-simplification, but I think it gets the core ideas across.

I wrote a number of academic papers 1 2 on robot architecture if you would like to explore more deeply. If you have something specific in mind, please feel free to ask me (or the community) some follow-up questions. ;-)

| improve this answer | |
$\endgroup$
  • 2
    $\begingroup$ I've never see the terms soft-time and hard-time used in industry, is this an academic thing? In industry we tend to use the terms soft real-time and hard real-time, as used over on the Real-time computing wikipedia page. $\endgroup$ – Mark Booth♦ Dec 1 '12 at 23:32
  • $\begingroup$ @Mark -- I'm drawing an even broader conclusion ;-) Real-time systems have deadlines; soft-time systems don't. Hard-RT, firm-RT, soft-RT are all sub-classifications of real-time systems. That's just how I am "drawing the lines" in this context. I apologize for any confusion. $\endgroup$ – DrFriedParts Dec 2 '12 at 1:01
2
$\begingroup$

To offer an answer that (specifically) addresses the question, as I understand it, the RaspberryPi offers (either as part of the standard Pi distros, as add-ons or compilable from source) pretty much anything and everything that the Linux operating system provides.

However, for those that are not part of the distro (or from the repositories) there are portability issues, due to the specific hardware platform.

does this essentially allow for anything that would run on a linux box (raspberryPi) to run and operate your robot

As such, I'm of the opinion that "Maybe" is the answer... but whether I'd trust a robot to a Pi is another question entirely.

That having been said, now some personal opinion:

Yes I have a couple of Pis that I'm experimenting with, but I've rapidly broken through the hype surrounding the Raspie. I've come to the conclusion that it is so general purpose that it is, in effect, a solution looking for a problem.

As an embedded prototyping system, one is better off with an Arduino or a PIC dev-kit, in my humble opinion.

| improve this answer | |
$\endgroup$
  • $\begingroup$ hahah, late welcome to the party. You missed the part where you should mention input voltage being transformed into output voltage - then you'd get 8 or more upvotes! but yeah, I said that - not too popular around here. $\endgroup$ – Spiked3 Dec 20 '12 at 20:18
  • $\begingroup$ Just found the chat-room debate :( I've had a debate at work today with one of my grown-ups who seemed to think a Pi was suitable for a safety critical application... ho hum! $\endgroup$ – Andrew♦ Dec 20 '12 at 21:17
-2
$\begingroup$

"Does this essentially allow for anything that would run on a linux box ( raspberryPi ) to run and operate your robot?"

I'm an outsider, but from what I have heard Rasberry Pi has problems running ROS at the moment. A linux robot that can not run ROS is missing a huge part of the community, and I would have a hard time seeing that as "allowing anything that runs on linux."

To me the purpose of ROS is to allow research/development in a specific area without having to learn/develop all the other stuff that has already been done. That is the spirit of open source, that is the spirit of Linux, that is the spirit of ROS. Jut because you can not do this does not make it less of a robot, but it does make the reasons to use it much less, IMHO, and to answer your question.

Wouldn't it be a much better choice to run some non rasberyy pi computer with Arduinos? Is price the real issue? And if it is why does anything else matter then? A cute name does not make a cute robot.

edit: can anyone explain to me what a "universal API" is? How about a "vertically-integrated control system"? Actually, explain how this is even a question, with up votes?

| improve this answer | |
$\endgroup$
  • $\begingroup$ I fail to see how your post addresses the question $\endgroup$ – ThomasH Dec 4 '12 at 2:51
  • $\begingroup$ @thomasH the question in part is "does this essentially allow for anything that would run on a linux box (raspberryPi) to run and operate your robot" and my answer is "A linux robot that can not run ROS is missing a huge part of the community, and I would have a hard time seeing that as "allowing anything that runs on linux." - Let me know if you need anymore help. And thanks for your helpful contributions. $\endgroup$ – Spiked3 Dec 4 '12 at 3:14
  • $\begingroup$ that's fair enough, I missed that connection alright :-) Maybe it would be worth editing your post to say something like "In principle yes, but using a pi could mean not being able to run ROS" to make it a bit more obvious and maybe reverse some of those down votes $\endgroup$ – ThomasH Dec 4 '12 at 13:04
  • $\begingroup$ The down votes are from people who feel the Pi represents nirvana and hate any criticism. The more I look into it, I can see no reason anyone would use a pi for anything in robotics. I really don't care about their feelings, but thanks. Sorry to be rough on you, but I thought the connection was easy to see - and the lack of direct responses to my questions I think shows thats it is more of a touchy feely issue and not really a technical discussion. $\endgroup$ – Spiked3 Dec 4 '12 at 13:13
  • 2
    $\begingroup$ It looks like the tone has become a little personal here, but I want to salvage something from this. @Spiked3, what you're saying about ROS is true -- it's quite powerful -- but it doesn't fully address the question; that's probably why the downvotes were cast. That said, the initial question was poorly written ("universal API", what?); it's since been revised. I think if you had commented on the question (to get clarification) before answering, your answer would have been better received. I hope you'll continue to contribute, because you seem to have valuable experience to share. $\endgroup$ – Ian Dec 5 '12 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.