RoBeetle

Um microrrobô sem eletrônicos ou bateria, movido à reações químicas de metanol líquido?

Parece interessante.

Mais detalhes neste artigo do sempre interessante IEEE Spectrum.

Agility Robotics Digit

Suas definições de robô colaborativo foram atualizadas.

INMOOV - UM ROBÔ (QUASE TODO) FEITO NUMA IMPRESSORA 3D

Apesar disso não ser robótica industrial (ainda), é mais um exemplo de tecnologias baratas que estão convergindo e que podem/devem ser absorvidas pela indústria.

Se já estão "imprimindo" armas de fogo , é questão de tempo até que as empresas cheguem à conclusão que pode ser possível homologar materiais e tecnologias alternativas para determinadas aplicações. 

Mais detalhes aqui:

http://inmoov.blogspot.com

ROBÓTICA + IPADS?

Particularmente eu prefiro o Android, mas negar que o iPad é a epítome do tablet seria loucura da minha parte. E, mesmo com todas as restrições impostas pela Apple, a gama de usos inusidados dada ao dispositivo nesses dois anos de vida é realmente surpreendente. E, mais cedo ou mais tarde, isso acabaria chegando à indústria da automação.

Me lembro de, em 2010, ter visto uma notícia envolvendo a fabricante americana Adept e os tais iPads, que na época ainda eram novidade. Pouco tempo depois, me deparei com o vídeo abaixo:



E, essa semana, o sempre antenado Samuel Bouchard afirma que um cabeção da Frito-Lay US também manifestou interesse em programar seus robôs com iPads.

Até que faz sentido: anos atrás, as IHMs deixaram de ser hardware especializado para se transformarem em software rodando dentro de PCs comuns (ok, PCs industriais).

Mas fico imaginando como ficaria a parte de segurança. Praticamente nenhum fabricante de robôs industriais aderiu aos TPs sem fio, e imagino que o grande responsável por isso sejam os dispositivos de segurança (botão de emergência + "dead man") contidos no mesmo.

Há ainda a parte de segurança da informação. Se empresas grandes já são especialmente sensíveis em relação a notebooks, o que dizer de dispositivos móveis?

De qualquer modo, da mesma maneira que os PCs foram pouco a pouco sendo introduzidos no mundo automação, imagino que os dispositivos Pós-PC também terão seu lugar ao sol, e será interessante acompanhar essa tendência.

GLOBAL VILLAGE CONSTRUCTION SET

Meio sem querer, acabei esbarrando, nesse projeto pra lá de interessante.

http://opensourceecology.org/gvcs.php

Como já está explicado no site, o objetivo dos caras é bolar, construir e depois disponibilizar os projetos de 50 equipamentos industriais que eles consideram indispensáveis para a manutenção de uma pequena  civilização com um grau mínimo de conforto.

E o que isso tem a ver com a gente?

Bom, entre os 50 equipamentos, há a proposta de se construir um robô industrial. Até agora os caras já conseguiram construir 8 das 50 máquinas (o robô AINDA não está pronto).

Esse vídeo [em inglês] explica melhor o conceito:



O projeto é mantido através de doações.

ROS (ROBOT OPERATING SYSTEM) EM ROBÔS MOTOMAN

Quer dizer, mais ou menos. Leia o artigo (em inglês) e depois volte aqui. Eu te espero.

Já falei do ROS por aqui (e aqui também).

Se você é preguiçoso, eu te ajudo: basicamente, o ROS é uma espécie de Linux* para robôs industriais. Apesar da comparação O ROS ainda não é um sistema operacional per se. É um framework, uma série de bibliotecas e ferramentas opensource para a geração de programas.

A idéia é muito bacana, mas como disse nos posts anteriores, também compartilho(-lhava?) da opinião de Samuel  Bouchard e acredito(-tava?) que os fabricantes, clientes e integradores não iam abrir mão do sigilo, um dos pilares fundamentais dessa Babel tecnológica também conhecida como automação industrial.

Entretanto, se um dos cachorros grandes resolve entrar na dança, é porque aí tem.

O artigo diz que a Motoman vai tentar adaptar o ROS a um modelo específico - um SIA20 - mas acredito que o correto seria dizer que o port será para o controlador NX100.

De qualquer maneira, acho que o ROS será apenas mais um feature, e não vai substituir o sistema da Motoman.

Bom, pelo menos por enquanto.

Deixando de lado o romantismo que normalmente vêm à tona quando o assunto é software livre (fique tranquilo, estou falando de mim mesmo), acredito que um sistema estável e um pouco de crowdsourcing sejam uma alternativa melhor do que desenvolver sistemas proprietários por conta própria, ou utilizar sistemas proprietários de outras empresas (KUKA+Windows Embedded). O que dá dinheiro aos fabricantes é o hardware, e não o software. E no final das contas a parte sigilosa da coisa seria resolvida com os (nem tão) bons e velhos Binary Blobs.

Enfim, estou curioso para ver onde isso vai dar.

*apesar de ser técnicamente correto, ficar escrevendo GNU/Linux é viadagem demais para o meu gosto.

CLOUD ROBOTICS

Tava demorando.

Embora a fonte desse post não se relacione exatamente à robótica industrial, se "a moda pega", com certeza o setor será um dos primeiros a implantar isso.

Já é relativamente comum ter robôs ligados em sistemas de supervisão (através de redes Ethernet, por exemplo), que possibilitam tarefas mais corriqueiras como o monitoramento de status, a administração de backups ou pequenas modificações em programas e arquivos de configuração.

Entretanto, no contexto industrial, deixar todo o processamento dos robôs sendo executado remotamente pode acarretar uma série de problemas. A internet, mesmo nos países desenvolvidos, ainda é um meio instável para os padrões industriais. Pelo menos por enquanto.

Um meio termo seriam linhas robotizadas com controle centralizado. Em vez de uma cpu por equipamento, uma grande cpu localizada nas dependências da fábrica faria às vezes de cérebro da robozada.

A sabedoria popular diz que botar todos os ovos dentro da mesma cesta é perigoso. Entretanto, como o pessoal de TI já está careca de saber, sistemas redundantes (clusters, RAIDs, etc) costumam ser uma boa solução.

De qualquer maneira, em uma linha convencional, quando um robô pára, o restante da linha fica inoperante, visto que, até por motivos econômicos, muito raramente as mesmas são projetadas com meios alternativos, e em muitos casos é difícil fazer um robô assumir as funções de outro.

Entre as vantagens comentadas no artigo, o barateamento do hardware seria o mais interessante para as indústrias manufatureiras.

Uma base de dados mútua também seria interessante, mas duvido muito que fabricantes e fábricas estivessem dispostos a compartilhar informações que invariavelmente são consideradas segredo industrial.

(fonte: GetRobo)

PUNCH LINE

Dia desses meu chapa digital @morevi me enviou esse link.

Se você não está a fim de ler todo o artigo, quebro seu galho: pesquisadores eslovenos estão fazendo testes para tentar ensinar a robôs industriais qual seria o limiar de dor de um ser humano.

O método?

Um samaritano prende o braço em um dispositivo para que um robozinho Epson (um Pro Six PS3, presumo) possa golpeá-lo, lançando mão (hihihi) de dois tipos de ferramentas e várias intensidades de força diferentes.

Se eu concordo com o Morevi que esse experimento específico não é lá muito brilhante e, mais cedo ou mais tarde, VAI dar merda (Ig Nobel? Darwin?), por outro lado também tenho certo apreço por esse tipo de iniciativa - na qualidade de alguém que já foi alvejado mais de uma vez por robôs industriais com payloads que vão de 200kg para cima. Para efeito de comparação, o payload do robozinho do experimento deve estar entre 2 e 5kg.

Robôs industriais já contam com sistemas de verificação de sobrecarga. Mas, nos robôs atuais, a sobrecarga é detectada quando ocorre excesso de torque nos motores das articulações. O excesso de torque, por sua vez, ocorre devido à picos de corrente não previstos, que podem surgir quando os motores precisam de uma corrente maior do que a calculada para aquele trecho específico do programa, ou quando o motor tenta se movimentar e não consegue, porque colidiu com um obstáculo. Normalmente esse "obstáculo" é(ra) um outro robô ou algum outro equipamento que também está confinado dentro da célula, junto com o robô.

Como é dito no final do artigo, não sei se o "limiar de dor" seria uma maneira correta de ensinar aos robôs qual seria o momento de pararem, justamente por - até determinado ponto - ser uma coisa meio subjetiva. Além do mais, o problema tem uma faceta jurídica. O X da questão não é golpear um ser humano de maneira que ele possa suportar (e voltar para te processar depois), mas NÃO golpear um ser humano, em hipótese alguma.

Para mim, a tecnologia ideal seria um híbrido entre o ABB SafeMove e a SawStop.

ABB SafeMove

SawStop

A primeira controla a velocidade e aceleração (e consequentemente, a força) dos robôs baseada em monitoramento visual. A segunda é ativada com a capacitância do corpo humano.

Evidentemente, há percalços técnicos.

Confiar apenas em câmeras pode até ser uma alternativa viável em locais livres de splashs de solda, gases ou outras substâncias que possam danificar as lentes. Contudo, o segmento que mais utiliza robôs industriais (ainda) é a indústria automobilística, principalmente nas áreas de montagem de carrocerias, onde o ambiente costuma ser mais bem mais agressivo do que aquele apresentado no vídeo da ABB.

Em contrapartida, detectar a capacitância específica do corpo humano - em meio a soldas e outros tipos de ruídos eletromagnéticos - é algo que só pode ocorrer em distâncias muito pequenas. E não sei se essa distância seria suficiente para a frenagem de um braço mecânico de mais de 1 tonelada se movendo a 2 m/s.

Há também que se perceber que há uma diferença de objetivos entre o estudo do pessoal da Universidade de Ljubljana e a tecnologia da ABB, que tem contrapartes similares em outros fabricantes.

Em fábricas e outros empreendimentos que façam uso maciço de equipamento automatizado, a integridade do ser humano já é muito bem protegida, por um princípio até simples: o isolamento.

Humanos e robôs NUNCA dividem o mesmo espaço enquanto estão trabalhando. Como pode ser visto no início do vídeo da ABB, quando alguém entra na área de trabalho do robô, algum dispositivo (seja uma grade, uma janela, uma barreira ótica ou um scanner) faz com que o equipamento pare imediatamente, retornando à atividade apenas quando a pessoa está em uma condição segura. E essa pessoa só pode reativar a célula através de determinados mecanismos, que estão localizados fora da área de trabalho do robô.

Tecnologias como o SafeMove visam, antes de tudo, otimizar o processo produtivo, reduzindo necessidade de espaço, gasto de material para construção das células e tempo para restabelecimento do ciclo automático.

Já estudos como o do robozinho "invocado", mesmo que por vias tortas, tentam garantir ainda mais a segurança das pessoas.

De qualquer maneira, a interação homem-máquina já é um assunto antigo no ramo da automação, e dentro em breve devemos ouvir falar de outras soluções interessantes.

RUN TO THE HILLS!

O nome científico desse cara aí em cima é SDA10D mas, para os amigos, ele é conhecido com Dexter. 

Tem perfil no Linkedin, fan page no Facebook, e quando vi um parente próximo fazendo hamburgueres numa feira japonesa uns anos atrás, até achei a família simpática.

Mas na última semana meu amigo Luiz Antonio me enviou o link para o vídeo abaixo, e ver nosso amigo Dexter montando um objeto *maior* me deu um puta aperto no coração.

Se liga:

Por que, de cadeiras para um Cyberdine T800 é um pulinho. Cê sabe, né?

(mais fotos aqui)

Outro carinha que, a primeira vista parece inofensivo é o youBot, da KUKA. 

Vendo asim, parece até bonitinho.

Mas imaginem quando ele crecer, ficar do tamanho de um TITAN e for colocado em cima de um omniMove turbinado!

Sim, sim, eu sei que já postei por aqui mesmo um vídeo de robôs industriais montando outros robôs industriais, mas a imagem mental evocada por um equipamento confinado dentro de uma célula é bem diferente da de equipamentos que começam a se parecer mais com você ou que podem te perseguir enquanto você GRIIIIIIIIITTTTTTAAAAA!!!

E isso porque tô falando só de coisas que JÁ estão no mercado. Pode começar a ter pesadelos essa noite.

[PARA OS DESAVISADOS: as notícias são reais, os comentários são brincadeira]

HELI TRAINER

Vi o link hoje.

O HELI TRAINER parece um desdobramento natural do KUKA 4D (um Robocoaster anabolizado), que, por sua vez, é um descendente do SUPRA.

Aprender a pilotar em um KR 500 deve ser MESMO menos perigoso do que em um helicóptero de verdade. Além disso, a experiência proporcionada pelos graus de liberdade (como odeio esse termo) deve ser mesmo bem mais próxima do real do que aquela proporcionada por simuladores mais tradicionais.

Uma coisa que acho engraçada nisso tudo: os robôs industriais foram criados justamente para EVITAR o contato de seres humanos com determinadas atividades. Mas isso se resumia a atividade fabril. Como outras tecnologias, a robótica [industrial] acabou extrapolando muito seu escopo inicial.

Gostaria ver a cara de George Devol recebendo uma notícia dessas.

VIRTOBOT

Num artigo recente do site da revista inglesa New Scientist, li sobre o Virtobot (que, sabe-se lá porque, é chamado de VirtIbot durante todo o texto).

O Virtobot é um dos alicerces de uma técnica que vem sendo paulatinamente adotada na medicina legal de alguns países: as virtópsias.

A virtópsia consiste em três etapas:

Primeiro, um robô industrial escaneia o corpo da vítima com uma câmera capaz de gerar um modelo 3D da superfície do mesmo.

Depois, o corpo é posto dentro de um tomógrafo computadorizado, que, através de raios-X, gera imagens do interior.

Por fim, amostras de tecido e fluídos são coletadas através de biópsias feitas com agulha.

Isso evita que o corpo sofra maiores danos - o que pode ser desconcertante para algumas famílias (obviamente, isso se aplica apenas a mortes não violentas). Também há um ganho de precisão no processo. Por último - e, talvez, o motivo mais importante - avirtópsia é gravada e pode ser consultada o número de vezes que for necessário, por diversos patologistas diferentes.

A princípio, não há diferença gritante entre o Virtobot e algumas aplicações utilizadas na indústria, como medição a laser ou sistemas de visão.

O texto deixa bem claro, mas é sempre bom lembrar: o Virtobot é um robô industrial normal, e não um desses robôs-cirurgiões que estamos cada vez mais acostumados a ver por aí.

Um robô-cirurgião é uma extensão das mãos do médico que o opera. Ele não trabalha através de programas ou rotinas, ou seja, ele só se movimenta quando o médico ordena. É uma ferramenta para dar mais precisão às mãos do cirurgião.

Já o Virtobot, após ter definidos alguns pontos de calibração, trabalha sozinho, executando trabalhos repetitivos, como seus primos da indústria.

De qualquer forma, fiquei curioso para saber mais detalhes sobre o robô utilizado.

Abaixo há um vídeo de 30 segundos - que pode ser desconcertante para alguns - onde se mostra a virtópsia do crânio de uma vítima de suicídio.

ROBOT OPERATING SYSTEM

Na edição 283 da revista INFO (Setembro/2009), uma matéria curtinha me chamou a atenção.

Falava sobre o ROS (Robot Operating System), uma tentativa dos cientistas criarem um sistema operacional que poderá ser utilizado por qualquer pessoa que queira desenvoler qualquer tipo de robô. Ambicioso, não?

Obviamente, o âmbito da reportagem é a robótica acadêmica, de pesquisa, onde as particularidades tanto do software como do hardware são muito mais acentuadas do que em nosso ramo de trabalho.

Contudo, não deixa de ser interessante imaginar as possibilidades que esse tipo de ferramenta poderia trazer ao chão de fábrica.

Embora não seja a maioria dos casos, em determinadas situações linhas ou até mesmo células são montadas com robôs de fabricantes diferentes. Comissionar esse arranjo de equipamentos, dependendo do caso, pode ser trabalhoso, justamente por ter que se levar em conta as idiossincrasias de dois ou mais tipos de máquinas, o que, evidentemente, pode comprometer a produtividade das equipes envolvidas.

Mas, e se fosse possível utilizar os mesmos programas e configurações, independente do hardware?

Sinceramente, acho que a probabilidade de isso acontecer é, tipo assim, nula. De qualquer jeito, sonhar não custa nada.

Detalhe: se você for corajoso e quiser experimentar, esteja avisado que, por enquanto, o software só roda em filhotes do Unix (leia-se: Ubuntu e Mac OS X).