|
Super Lloyd wrote: For how long is it going to be the exclusive realm of a select few?
It's not a select few: it's the few that didn't fall for the shiny webpops things. Those who actually studied math because they didn't believe "only basic math is useful to a programmer", those who took some electronic course and know at least basically what a transfer function is, what is a feedback control system and a finite state machine.
That is, many many people who just "learn how to Java" aren't prepared to manage moving parts. Just think of the extreme prejudice against writing pieces of software in Assembler (whatever flavor you need): each person professing that prejudice can't do serious robotics - they can play with Arduino and DIY robots but only at half power.
All the programmers who rely heavily on frameworks because "that is done by the framework" and do not even try to reinvent the wheel are seriously hampered in robotics and embedded systems, as most probably that is one of a kind or one of a very restricted family, so no framework and no wheel does precisely what is needed.
All that I say from my current experience in Industrial Automation and past experience in Robotics.
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"When you have eliminated the JavaScript, whatever remains must be an empty page." -- Mike Hankey
modified 13-Oct-15 7:56am.
|
|
|
|
|
This, imho, is exactly the point for today's environment. Maybe not so much in the future...
"Programming" is...well, not easy, exactly, but fairly simple compared to the real world. At the highest level where users see "Hello, World!", a computer is a computer is a computer. Compilers take care of the rest, and hide all those ugly choices like "add r0,r0,r1" vs "add r0,r1" at the assembler level.
Once you start dealing with the outside (of a computer), things get very complicated. The software for a Roomba won't work on a Cyberdyne T-101, and vice versa. Even if the computers were compatible, the task "get rid of that crud" has to be carried out completely differently, mechanically, on each system, which means that low-level commands would have to be different, thus the math, ad nauseum. 
It might be different if robotic platforms (and their manufacturers) settle on the equivalent of "frameworks" for both the computational side and the manipulator/motivator side. Kits and microcontrollers like the Arduino, Lego Robotics, etc. are all a move in the right direction, but your industrial automobile welder is still a world away from a home made robotic arm, even though they might perform the same tasks.
Until then, though, it's going to take a lot of low-level work in both software, hardware, and in-between to get even the most basic robotics project up. Some people love this--I'm working on a homemade trirotor drone made out of $5 of sheet metal from Lowe's and pop-rivets--and they will keep it up.
For the average developer, no matter how brilliant, it is usually too much of an investment of time and labor that, in the short run, doesn't really pay off much, even if the pay off is just seeing something move.
vuolsi così colà dove si puote
ciò che si vuole, e più non dimandare
--The answer to Minos and any question of "Why are we doing it this way?"
|
|
|
|
|
Robots are nice and remove a lot of the dirt work as they are already adjusted to move at their max speed given a certain specs on weight into the clamping system but, they are not precise (therefore the offline trajectory/points programming is always something that is half backed) and when you want to program them you need to go deep into the specific software the manufacturer gives the operator/engineer that need to program it.
This means that you have a subset of variables and functions that are somehow limited, depending on the brand you use bad documented and with a bad technical support too.
Anyway, the best thing of programming robots and special machines is to "see" your work moving something real.
Being a roboticist is usually easy if your environment has companies that are working on that field, of course, studying at the university some robotics help to get in touch with companies that are interested in that world. Anyway, there is something you have to be aware of: there are plenty of companies that search for "robot programmers" which at the end of the day means somebody to move the robot at different positions to store trajectories. Coming from the IT world the nice job is the one that implies maths, 3D trigonometry... to make special and nice things with those arms.
When I do need people in my department I usually search for guys/gals who have studied something related to robotics in the University, but even if they have not, I want people with IT knowledge... It's easier to explain what a piston is than what a pointer is... But this is also an important factor when searching for people: I've seen plenty of programmers that have made all their programming job thinking the mechanics are instantaneous and of course this won't work... When programming with sensors and actuators you need to change a little bit the way of working and getting used to that can take time.
|
|
|
|
|
Not quite sure how you mean "not precise" as the robots in the automobile industry seem to be more precise than the humans doing the same job. But with your signature line and you being a roboticist, you know more than I do as I was relying on co-workers information.
Note: I learned to program a CNC machine in college and only did it once at work (with supervision), but have only the basic idea of robotics. I know enough to consider momentum and that is about it. 
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
This is a quite typical misconception on the robotics field: robots have a good repeatability but an awful precision.
After years of working with them I've learnt to expect a 0,3mm precision in all the working envelope as the best case scenario and only in certain robot arms (the smallest ones). And of course after a very expensive recalibration process that can take a couple of days per robot.
You can easily see Absolut/High accuracy robot variants in all the robot brands out there and in those "special" much more precise systems they are offering +-1mm of precision.
when you move a robot to a certain position and store the point you are simply correcting the precision error without even noticing it, but don't try to copy one program from one robot to another one... even in the same conditions the program will be executed in a different position...
A CNC machine is always more precise than a robot (of course if it has been constructed as it should), but the way the motors and the physical conception of a robot is made it is easy to understand the big kind of errors a robot have.
|
|
|
|
|
That's good info and a point well made. But "...but don't try to copy one program from one robot to another one... " doesn't hold for many cases, especially when the robot is integrated with sensory and other features that give it the ability to correct where needed. With that environment in place, I can move the software and its specific operating scripts from one unit to another and get the needed performance. Glad you mentioned CNC machinery (a large part of automation and AI that is not in the forefront of the IT news).
|
|
|
|
|
It all depends on your needs of course, usually this is not needed and sensors can help to correct the robot programs. In our case (we always make strange things) we need to allow the end-user to program the trajectories in order to be able to create different programs depending on the different parts the machine will have to grind or polish.
When this happens, given the fact the robot precision errors are not constant in position nor orientation, then we need to go the re-calibration way.
If you take a look at our EMERALD machine range you'll see why I speak about copying one program from one robot to another one.
Anyway, if we forget our strange needs you are right. 
|
|
|
|
|
Nice!
Not sure there ae many robotic opportunities in Australia.... but gonna investigate!
Thanks for your inspiring email!
+ on top of year of IT experience I study physics, which is a nice and meaningful background to have in that topic, I bet! :P
|
|
|
|
|
Be aware that you will have to spend nights and plenty of stress on the deadlines... programming is done while the project is growing up, but the final tests and set up is done at the end, when all the money has been spent and usually being late at the starting point.
It's fun and nice, but this is the worst part of it.
Sure it can help.
|
|
|
|
|
"...they are not precise ..."
Consider the Motoman HP20-6, within it's range of motion repeatability is +-.06MM, industrial robots - love'em. If you want to be involved with robotics, vision, sensors and creating the software to drive and integrate them, get into manufacturing.
regs
ron o.
|
|
|
|
|
Hello bojammis,
See my other answer here[^].
Precision is not the same than repeatability. A lot of years ago I learned that the hard way.
And then, it comes when the repeatability sphere changes it's physical position depending on the motors temperature... 
I've still never used Motoman, but I've used ABB and KUKA extensively (since 1999) and now I've started using Stäubli (because of a customer preference). Soon it is possible I'll have a Motoman to play with... let's see if they work as well as I heard and let me cross fingers to pray for a software base that looks like the one installed in ABB.
+-0.06 is not precise by any means, any of our tailor made CNC machines is at least 10 times better in precision than that.
Don't misunderstand me, I love robots: they are really flexible and allow making things that are impossible or super expensive if you have to do them in a CNC/PLC tailor made machine. We've made very special things with them, extensive math, processes that recalculate the trajectories at runtime, calibrating robots, artificial vision, force control sensors, offline programming... we even have some patents related to robotics... Feel free to take a look at our web page (see my signature) and some videos in our Youtube channel.
Which sector are you in? which kind of machines do you create at your company?
Best regards!
|
|
|
|
|
I'm making this comment after I replied to the (answer)link you sent me so it may seem they are out of sync. I worked with CNC equipment for 25 years. Very use to the idea of +=.0002 inch accuracy with .00004 repeatability. I don't meet many people who have had the experience and back ground that you sport( in automation). My experience with CNC equipment was end user at the time. Now I work with automation for micro circuits(chips). I write software that would manage/coordinate a number of robots (in atmosphere and in high vacuum) along with heaters, gas analyzers, cryogenic doDads, digital IO devices, devices that communicate using sockets, the list goes on. These are machine specific to the needs of the company. But it's great fun.
|
|
|
|
|
bojammis wrote: But it's great fun.
Indeed it sounds fun, once you enter the physical world it's difficult to go back to program "normal" programs. 
|
|
|
|
|
You might want to check out Instructables. There you can do a search on Robots, Raspberry PI, Audrino, Intel Edison, and (my fav) Segway. This site is perfect for DIYers. Truly a great place to start fishing for ideas and learning how other people make things.
Hope it helps.
Phil Delay
|
|
|
|
|
|
|
When my better half bought an iRobot Roomba, it came with an invitation to develop new programs for it. It's fun to watch one of these when you first get it, in part because there are just a few easily identified floor coverage algorithms. And they're way different than anything I expected.
Maybe all it can be programmed for is movement patterns, but for 400 USD it might be fun and you would see some tangible results.
|
|
|
|
|
|
A bishop moves "diagonally" -- that's good one-word description.
Is there a generally accepted one-word description of how a rook moves? "Horizontally", "vertically", and "perpendicularly" don't seem correct. "Straight" seems too vague.
P.S. I'm going with "orthogonal".
modified 14-Oct-15 23:10pm.
|
|
|
|
|
I've seen horizontally, vertically mentioned in the same breath, as Ive seen 'forwards, backwards and to the sides', and then 'horizontally and vertically both forwards and backwards' - so if you want one word, horizontally and vertically arnt too bad
Perpendicularly .. hmmmm
|
|
|
|
|
Garth J Lancaster wrote: horizontally and vertically
But I seek one word that covers both.
|
|
|
|
|
|
Yes, a very good word for this situation.
The pieces cross the divisions of the board at right angles to them.
|
|
|
|
|
Over yonder!
New version: WinHeist Version When you have eliminated the JavaScript, whatever remains must be an empty page. Unknown
|
|
|
|
|
That sounds more like a shuffle board term. You've been in Florida too long.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
