Robotics

[xXKelbaXx]

After playing some classic Megaman and reading about DC's robot wars, I've gotten interested in programming robots. I've googled this subject and haven't gotten a clean answer and I'm wondering if any of you know what is the standard language for robotics programming? Assembly? C/C++? Java (Java popped up frequently for some odd reason)? Any insight is helpful.

[TheCotMan]

After playing some classic Megaman and reading about DC's robot wars, I've gotten interested in programming robots. I've googled this subject and haven't gotten a clean answer and I'm wondering if any of you know what is the standard language for robotics programming? Assembly? C/C++? Java (Java popped up frequently for some odd reason)? Any insight is helpful.

The topic of robics it quite broad. However, many robotic systems are built as or with embedded devices. We have a member (LoST) who has provided a great deal of information on how to get started with embedded devices and programming.

You should browse through the threads in this section (IP Appliance) and see if these will help you. LoST has been very busy as of late, and may not have time to respond to you quickly, if at all, but others may be able to help you too. If you have a question after reading all of those threads and links, asking specific questions may get you quicker responses.

We also have some talented people from other DC Groups who are creating entries in another competition (Robot Warez) and they have been know to be quite helpful to people who demonstrate intelligence and research in their questions.

Good Luck

[LosT]

Sorry I haven't been around....been *busy* getting ready for my new job- building ROBOTS ;)

Design a robot like you would write code: generate 'pseudocode'- which in the robot world would be a basic outline of functions/features/structure....a skeleton idea of what you want to build...the "I want to build a robot" statement is too vague, and without clear goals you won't get anything built....

Design your hardware to your desired functions- some people would tell you to keep things like budget in mind when doing this- this is true to a point, but some of the most clever solutions I've seen for problems arose out of a desire that greatly exceeded budget...

If you are under time constraints pick hardware that you know...IF NOT, pick something you don't know- trust me...learning new hardware ALWAYS makes you a better robo/embedded hacker....

Generally you want to design your drive train/structure, brains (controller), and power as separate 'sub-systems'- and then make sure that each subsystem meets the requirements of the others...which of the subs you start work on first depends alot on how you think...I prefer to go with controller, power then structure/drive train....there are those who would argue with me; but knowing how heavy your batteries will be before you build a chassis will save tons of heart ache....and you don't know what batteries you need before you know what brains you need to power....

(Side note- when possible try to isolate power systems: one for control, one for brawn- consider the power spikes when motors kick on; brown outs, etc)

As far as languages, that depends on what hardware you have- quick and dirty:

Parallax products: PBasic, Java, SX assembler, SX/B Assembly/Pbasic hybrid
PIC controllers: C if you have a C compiler, PIC/Microchip assembly, Basic (if you have compiler)
Amtel: see PIC, replace PIC with Amtel
Motorolla: see PIC, replace PIC with Motorolla


Honestly if you are going to have 'good' code, you need to accept the fact that you will eventually have to look at some assembly, period. There is no such thing as optimized code spit out of a compiler (or tokenizer)- and assembly 'changes' depending on what hardware you are working with.

Hope this helps...it is 3 am, sorry for typos or ramblings...

LosT

[Tacitus]

First of all, congrats on the new job LosT!

Im Just going to share some thoughts on our (irvine underground robot team) deisgn process over the years and on the couple bots we have worked on... maybe it helps, maybe it doesn't....

A resource we are starting to explore is http://playerstage.sourceforge.net/ it looks somewhat solid and has a simulator package so you can run stuff sans hardware.

I am also starting to like acroname's brainstem (http://www.acroname.com/) it has a pretty clear API and documentation, has serial and iic onboard so it can communicate with other devices. The brainstem itself might be a little limiting but for basic work, it is simple enough to help get the job done. Some members of the community have also recommended the OOPic (http://www.oopic.com) as a step up from the brainstem.

I also like some of pololu's motor and servo controllers (http://www.pololu.com)

If you notice... this is a list of resources and not languages as the original poster has asked for- I guess if you had to draw a conclusion it would be to not worry about the actual language, but make sure you have good components and use whatever is the best way to interface/use them.

We at irvine underground have taken the approach to offload all computing to a full scale computer system, and have serial communications to our controller boards- this has worked well for us- it might be an approach to consider for those who do not have more of a software background than a embedded or hardware background- it will let you start to get stuff built and working, slowly learning about what hardware and embedded software works best, and allows you to design control logic in a higher level language you might be more familiar with.


if i could add a piece of advice I just want to echo what LosT said- Design Design Design, then design some more, a good design helps you at every point in the process and makes things down the line a lot easier.

[kallahar]

Oh yeah, and if you blow a fuse on the line going to your motors, you can't just replace it with a bigger fuse because then your motors start to smoke when you dump too much current to them...

[Tacitus]

Yeah, and if you are working to a deadline, build in some time for testing, then take that time and double it, then double it again, subtract this time from your final deadline, this is now your goal for having everything done. Don't devalue testing, it is more important than doing the actual building- Building should flow easy from spending a lot of time understanding your problem and designing well. The sooner you can get something built with quality, the more time you have to fix unexpected problems, like bad USB to Serial drivers from Belkin, or lack of GPS signals on the sides of buildings. You need time to make sure things work- and unless this is a full time thing you are working on, finding the time to test things in 2 weeks is not nearly enough.

[KeLviN]

Don't devalue testing, it is more important than doing the actual building- .

yeah... i'm gonna have to dissagree and say that they are both worthless without the other. the "actual building" is just as important as testing.

[Tacitus]

yeah... i'm gonna have to dissagree and say that they are both worthless without the other. the "actual building" is just as important as testing.

"Actual building" should flow easily from a good problem definition and good design. Testing is where you are going to discover a lot of bugs- but testing is tangental to the development process such that it is way to easy to forget to test until it is too late.

[KeLviN]

i'm not questioning the differences in natural progression between the two systems. i'm saying that coding is not any more or less important than building.

[Tacitus]

i'm not questioning the differences in natural progression between the two systems. i'm saying that coding is not any more or less important than building.

I am not questioning the imporatance of building... my original point was:

Don't devalue testing

[AlexCV]

My 0.02$ on robotics programming language:

My brother is part of a team designing an autonomous submarine for an engineering competition. They use a variety of languages:

Java for the PC driving the sub itself. C++ for some signal processing (vision) that is too slow in Java. C and Assembly on PIC to drive their servos, communication bus (you know, compass, engine control/status, etc.).

Or at least it's my understanding.

[LosT]

My 0.02$ on robotics programming language:

My brother is part of a team designing an autonomous submarine for an engineering competition. They use a variety of languages:

Java for the PC driving the sub itself. C++ for some signal processing (vision) that is too slow in Java. C and Assembly on PIC to drive their servos, communication bus (you know, compass, engine control/status, etc.).

Or at least it's my understanding.

That wasn't really a $0.02, but info on what your brother uses- not really an opinion per se- what 'communication bus' are they using? I2C? 1-wire?

Is the 'PC' contained in the bot? It sounds like a peripheral rather than a bot-
You are correct in that Java can be slow (often times if Java is used speed issues are taken care of via hardware rather than software)-

From what you describe the PICs are nothing more than function generators (if they are simply driving the servos).


It is a matter of personal opinion, but I don't consider certain things robots:

*Remote controlled devices are simply that, remote controlled devices- I do not consider 'robot wars' to be anything but 'souped up RC car wars'

*Along those lines I only consider something a bot if has a 'self contained' control system.

I say again, subsystem design. I also echo the sentiment that building is a *big* part of the process....the design is where you start your build from (and good design helps!) but it is a dynamic process.

LosT