Para utilizá-la é simples: o usuário só precisa usar óculos 3D, comandos de voz e as mãos para manipular os objetos. Além disso, todo o sistema usa apenas dispositivos de baixo custo, como o Kinect, e não requer o uso de monitores especiais para a exibição da imagem 3D, ficando ao alcance de todos.

Aplicações

O Fusion4D foi desenvolvido como opção de manipulação direta para o atlas anatômico VIDA, do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab). Este atlas é destinado a aulas de anatomia que usam uma grande quantidade de modelos e órgãos reais, o que torna difícil e caro manter os laboratórios. O projeto representa uma alternativa para complementar o estudo através de peças anatômicas e livros dereferência. Existe ainda o potencial para seu uso fora do ambiente do laboratório, permitindo aos estudantes a visualização dos modelos 3D em casa ou em outras situações de ensino a distância.

Além da aplicação no projeto VIDA para ensino da medicina, o Fusion4D poderá ser usado para outras aplicações médicas e educacionais, bem como em jogos, publicidade, engenharia, navegação em ambientes virtuais ou telepresença, entre outras áreas.

Como funciona?

O Fusion4D utiliza imagens 3D anaglifas e um dispositivo Kinect para detecção do esqueleto e captura de voz do usuário.  O usuário interage com o sistema usando comandos de voz em inglês. Tais comandos permitem que se selecione o objeto a ser manipulado e a maneira de interagir com ele.

Comandos

O comando “grab” seleciona um objeto e permite movimentar, rotacionar ou ampliar o objeto com as mãos até que o objeto seja solto pelo comando “release“.

O comando “explode” permite observar o objeto 3D em detalhes; o comando “show label“ mostra uma etiqueta descritiva do objeto manipulado, e o comando “change model“ permite escolher outros modelos disponíveis no sistema.

Finalmente, o comando “time” permite ver como o objeto seria no passado e no futuro movimentando a linha do tempo com uma das mãos. Se o usuário precisar de ajuda sobre o sistema, o comando “help” mostra uma lista de comandos de voz.

Este projeto foi desenvolvido como trabalho de formatura pelos alunos Keila Keiko Matsumura e Roberto Sonnino, formandos da turma de 2011 do Curso Cooperativo de Engenharia de Computação, e orientado pelos professores Dr. Romero Tori (orientador) e Dr. Ricardo Nakamura (coorientador), membros do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab).

Para mais informações do projeto e dos resultados obtidos e trabalhos futuros, acesse o site do Fusion4D.

Introdução

Logo do Sistema

Conceitos:

• Business Process Management (BPM)

BPM é uma prática de desenvolvimento, execução, análise de desempenho e simulação de Processos de Negócios para trabalhar no na continua otimização e ciclos de vida desses processos.

• Service-Oriented Architecture (SOA)

Uma prática de desenvolvimento de software que emprega disciplinas e linguagens de modelagem para fornecer soluções táticas e estratégicas aos problemas das empresas. Ela defende uma visão total da analise, desenho e arquitetura de todas as entidades organizacionais do software, concebendo-as como recursos de serviços-orientados, isto é, serviços.

Exemplo de Processos Aliados a Serviços

• Processo de Lançamento de Celulares:

Metodologia

• Estudo do Processo

Exemplo de Processo Modelado em Linguagem EPC

• Concepção do Projeto de Software

• Implementação do Projeto

Implementação com a ferramenta webMethods

• Testes e Análise de Performance

• Monitoramento e Manutenção do Processo

Dashboard de Monitoramento do Processo

Resultados Esperados

Parcerias

Parceiros

O cenário vislumbrado para a aplicação publicitária é o de uma vitrine de shopping, na qual as reações expressas pelas características faciais dos passantes são registradas e avaliadas. A partir desta análise, é possível verificar como o design da vitrine e a maneira de exposição das mercadorias afetam as reações dos consumidores, tanto positivamente como negativamente. Constituindo assim uma maneira de se avaliar e comparar os impactos alcançados com diferentes estratégias.

O sistema realiza a aquisição e processamento de uma sequência de imagens obtidas através de uma webcam e possibilita, através da produção de gráficos, a exibição de informações relevantes a um usuário da área de publicidade e propaganda que deseje medir a eficácia de uma campanha publicitária.

Apesar de a ideia do nosso projeto ser bastante simples, o título do projeto ser um pouco obscuro para quem não está familiarizado com estes termos. Vamos começar explicando o título e as coisas ficarão mais claras.

O que é…

… Veículo aéreo não-tripulado?

Um Veículo Aéreo Não-Tripulado, também conhecido pela abreviação VANT, é qualquer tipo de aeronave (como aviões, balões, helicópteros) que não precise de um piloto para ser guiada. No nosso projeto, utilizamos um dirigível cheio de gás hélio para representar o VANT.

… Mensagem CPDLC?

O CPDLC (Controller Pilot Data Link Communications) é uma aplicação utilizada para a comunicação entre os controladores de voo, localizados nas torres de comando, e os pilotos, localizados na aeronave tripulada. Uma mensagem CPDLC é uma mensagem de texto que segue o formato definido na especificação da Organização Internacional de Aviação Civil (ICAO – International Civil Aviation Organization). O piloto recebe e envia mensagens CPDLC utilizando um dispositivo denominado MCDU.

… Controle?

No contexto do nosso projeto, controle significa o envio de comandos, que poderão ser aceitos ou recusados pela aeronave.

O projeto

Agora sim: o nosso projeto trata de controlar um balão a partir do envio de comandos, como virar à direita, subir ou descer e alterar a velocidade, utilizando um protocolo de comunicação já existente e já utilizado na Aeronáutica hoje. Comportando-se como um VANT autônomo, o balão deve tomar decisões sobre estes comandos recebidos, decidindo se pode ou não executá-los, com base em variáveis medidas de um conjunto de sensores embarcados.

Motivação

A ideia do nosso projeto é que ele sirva como uma prova de conceito, ou seja, que ele mostre que é possível, controlar um VANT à distância, apenas através da troca de mensagens CPDLC e que, ainda assim, o voo realizado seja tão ou mais seguro quanto ele seria se existisse um piloto a bordo.

Um dos motivos para isso é que existem diversas situações em que a presença do piloto restringe a duração do voo. Um exemplo disso são voos de monitoramento de áreas de fronteira. Estes voos normalmente são utilizados para coleta de imagens, e não existe uma carga sendo transportada ou um destino específico. É interessante, portanto, não depender de um piloto, que pode ficar exaurido fisica e psicologicamente em um voo muito longo.

Outro motivo é que existem muitos acidentes aéreos causados por falha humana. Um piloto, por ser um ser humano, naturalmente está sujeito a cometer erros, mais ainda se não tiver um treinamento adequado. Se for possível substituí-lo por um sistema computacional devidamente projetado, implementado e testado, o número de acidentes será reduzido, tornando o espaço aéreo um lugar mais seguro.

Implementação

O sistema pode ser dividido em três módulos, mostrados na figura abaixo:

Diagrama de blocos do sistema de controle implementado

ACARS

O ACARS (Aircraft Communications Addressing and Reporting System) é um simulador de código aberto que foi utilizado no projeto, nós fizemos apenas pequenas alterações no código-fonte. O simulador completo que foi utilizado é composto por dois submódulos. O primeiro é o servidor ATC, cuja função é centralizar a comunicação entre o controlador e o piloto, registrando aeronaves e transmitindo para o destinatário (controlador ou piloto) as mensagens que são recebidas. O segundo submódulo possui, entre outras coisas, uma interface, mostrada abaixo, que permite o envio de mensagens CPDLC para as aeronaves – no nosso caso, o balão.

Interface para criação de mensagens no padrão CPDLC

Módulo Python

Idealmente, as mensagens CPDLC seriam enviadas diretamente do servidor do ACARS para o balão. Contudo, o microcontrolador utilizado no projeto (Atmega128 usado no Arduino Uno) possui severas restrições de processamento, tendo apenas 32KB disponíveis para o código-fonte e 1KB para a área de dados. Assim, foi introduzido um módulo que representa parte do sistema que normalmente ficaria na aeronave, mas que roda em um computador em terra. Este subsistema é responsável por receber mensagens CPDLC, traduzi-las para mensagens MBCP (My Blimp Control Protocol) e então transmiti-las ao balão. O MBCP é um protocolo bastante simples desenvolvido especificamente para o projeto.

Abaixo é mostrada a interface que foi desenvolvida para este módulo: ela imita a aparência de um MCDU, mostrando mensagens recebidas pela aeronave (denominadas de uplink, em laranja) e enviadas (de downlink, em verde).

Interface do módulo Python, emulando um MCDU

Módulo embarcado

Finalmente, temos o módulo embarcado. Este é composto pelo programa que roda no Arduino assim como pelos circuitos eletrônicos auxiliares que permitem a leitura dos sensores, o controle dos motores e o envio/recebimento de mensagens MBCP via rádio. Utilizando as leituras dos sensores, o balão consegue inferir qual o seu estado com relação ao ambiente em que se encontra, tomando decisões sobre a possibilidade de execução de um comando, e rejeitando aqueles que puderem colocá-lo em uma situação de risco.

A figura abaixo mostra a gôndola que é presa ao balão, com os três motores à mostra, assim como os três sensores infravermelhos, utilizados para detectar a distância de obstáculos frontais e laterais.

Gôndola que é presa ao balão, com sensores e motores visíveis

Dentro desta gôndola ficam os circuitos descritos acima, e mostrados na figura abaixo. Da esquerda para a direita, temos:

• Arduino: contém o microcontrolador que permite a execução da lógica de controle do balão.
• Placa de cirtuito impresso: projetada e desenvolvida especialmente para o projeto. As três placas menores (duas vermelhas e uma verde) são sensores inerciais – uma IMU (Inertial Movement Unit), um acelerômetro e uma bússola digital.
• Transceptor: permite envio e recebimento de mensagens de rádio.

Circuitos eletrônicos embarcados no balão

Esta foi uma brevíssima descrição do projeto. Quem estiver interessado em conhecer os detalhes pode entrar em contato ou fazer o download da monografia, que em breve estará disponível.

E não percam a demonstração prática, que acontecerá no dia 14 de dezembro, no Galpão da Administração da Poli!

Dennis Ritchie é um pouco (ha-ha) menos conhecido que o Steve Jobs, mas merece uma página de destaque tão grande quanto Steve.

Ritchie é reconhecido por duas grandes criações, que vivem até hoje e revolucionaram a computação. A linguagem de programação C e o sistema operacional UNIX.

Vencedor do prêmio Turing em 1983 pelo seu trabalho com o UNIX. Sistema esse que continua sendo base para uma parte dos sistemas operacionais utilizados nos dias de hoje ( incluindo o MacOS do outro homenageado do mês ).

Tudo que posso dizer é que ele mudou a computação e agradecer por deixar um legado tão importante!

Valeu Ritchie! Break;

Tivemos a participação de 86 colegas respondendo o cargo, o cargo registrado em carteira, tempo te formado, salário bruto e a quantidade de funcionários na empresa. Apesar do relativamente pequeno número de respostas, essa pesquisa nos possibilita ter uma visão razoável de quão aquecido anda o mercado de engenharia de computação no Brasil.Pretendemos fazer essa pesquisa anualmente, incrementando e evoluindo as perguntas conforme os feedbacks recebidos. Continuarei meu árduo trabalho de incentivo, com amor e carinho, para que mais pessoas respondam ao questionário.

A tabela da pesquisa pode ser vista nesse arquivo do Google Spreadsheet, mas, a tabulação e geração dos dados foi feita nesse arquivo de Excel.

Como pode ser observado no formulário de preenchimento, foram definidos intervalos para os salários, portanto, os valores das médias não são exatos (uma pessoas que ganha R$11.000,00 aparecerá nos dados como se ganhasse R$25.000,00) e devem ter gerado certa discrepância. Lição aprendida… ano que vem, deixaremos que cada um coloque o salário exato para melhorar a precisão da pesquisa.

Salário médio

O salário médio dos 86 participantes é de R$6.854,65, um salário muito bom, quando se observa que a média da região metropolitana de São Paulo (a maior do país) é de menos de R$1.700,00, conforme apuração do IBGE.

Cargo

Como o campo de cargo podia ser preenchido livremente, obtivemos respostas bastante diversas (bombeiro?), dificultando um pouco a tabulação dos dados. Foram agrupados cargos que, ao meu ver, pareciam coerentes, mas, ainda assim, obtivemos um “outros” de 14% das respostas.

(clique nas imagens para ampliar)

De todos os cargos preenchidos, as maiores médias salariais foram a de analistas financeiros e de negócios e a de engenheiros de software. As menores médias ficaram com desenvolvedores e analistas de sistema.

Tempo formado

Tivemos uma boa divisão de participantes para cada um dos tempos definidos, nos possibilitando ter uma boa visão.

Seguindo para os resultados, obtivemos o padrão esperado por um engenheiro. Quem se formou há mais tempo, ganha mais, com uma média de R$12.100,00 (observando a minha cagada na hora de criar os valores – 10.000 a 25.000). Quem se formou a menos de um ano ganha uma média de aproximadamente R$4.500,00.

Quantidade de funcionários da empresa

Aqui as respostas foram bem discrepantes com uma maioria esmagadora de politécnicos trabalhando em empresas com mais de 100 funcionários.

Essa discrepância acaba invalidando um pouco a pesquisa, já que pontos fora da curva acabam contando muito quando temos apenas meia dúzia de pessoas em um determinado tamanho de empresa.

Conclusões

A conclusão geral dessa pesquisa é que precisamos fazer mais pesquisas! Os dados obtidos foram satisfatórios, mas, mais respostas, saltos salariais menores e outras perguntas teriam melhorado em muito seu valor.

Concluo que nossa área está quente, mas precisamos “valorizar nosso passe” ainda mais.

Até a próxima, com melhores e perguntas e, se meu “amor e carinho” der certo, mais respostas!

Por isso batizei os Quick_bit[n] (nome pode ser alterado se quiserem!)

Os Quick_bit`s são pequenas informações como notícias de jornais, revistas, blogs + a opinião resumida. Estou me permitindo escapar um pouco do assunto “computação” nessa primeira vez pois o tema foi muito relevante, e muito comentado em todos os lugares.

–

Quick_bit[0] (PILOTO):

http://comentarios.folha.com.br/comentarios?comment=163138&site=folhaonline&skin=folhaonline

Os comentários da folha mostram como as pessoas entendem de energia nuclear, e como reagem a tal situação. Atentem para as comparações do tipo: “Podem multiplicar Tchernobyl por 4″. Isso é o povo, essas pessoas não estudaram quase nada sobre energia para saber do que estão comentando, ou o que estão falando, estão apenas reagindo ao medo gerado pela situação.

Mas o que dizer dos cientistas que argumentam contra a energia nuclear, o que dizer sobre seus pontos, seus dados…

http://www.guardian.co.uk/commentisfree/2011/apr/05/anti-nuclear-lobby-misled-world

Li hoje esse artigo no Guardian, que comenta sobre a desinformação, e a falta de veracidade nos dados que circundam as notícias sobre desastres nucleares.

O autor comenta que números de desastres antigos como os de Tchernobyl são alterados e manipulados para se adaptar ao discurso anti-nuclear, e que muito do que se é dito sobre os acidentes e principalmente sobre os efeitos na saúde não é baseado em fatos.

Acho que é responsabilidade de quem for comentar sobre esses acidentes, procurar se informar sobre cada uma das fontes de informações usadas, para garantir que a informação passada seja a mais correta possível. E cabe a nós pessoas que estudaram (apesar de não termos estudado especificamente o assunto) duvidar, e expor abertamente nossas dúvidas quanto a alegações extraordinárias, e demandar provas para todas essas alegações.

E citando Carl Sagan, lembrar sempre que: “Alegações extraordinárias, demandam provas extraordinárias”.

O que é a Ploobs Engine ?

É uma Engine para criação de jogos e aplicativos gráficos desenvolvida em XNA 4.0, C# .Net 4.0 e HLSL. Criada para ser simples de extender e fácil de usar, mesmo para aqueles que não conhecem com profundidade computação gráfica.

Cena com Reflexão, Refração, Animação, Glow, iluminação e SkyBox

O framework construído é bastante extenso, sendo constituído de diversos módulos responsáveis pelas tarefas mais comuns utilizadas em jogos como: Controle de Entrada, Simulação Física, Renderização Gráfica, Inteligência Artificial e Controle de Recursos.

O foco principal da Engine esta na parte gráfica, que usa a técnica de renderização Deferred Shading, a mesma encontrada em jogos como Startcraft II, Crysis II e KillZone II.

O render construído fez parte do nosso projeto de formatura. Uma explicação bastante profunda do funcionamento da técnica e da nossa implementação pode ser encontrada na nossa tese.

Quais são as Funcionalidades Principais ?

A PloobsEngine suporta praticamente todas as funcionalidades de uma Engine Directx 9c, sendo as principais:

• Deferred Render com suporte a Bump Map, Specular Map, Glow Map e Paralax Map (técnicas usadas para simular materiais e aumentar o realismo dos jogos)
• Sistemas de partículas
• Simulação física
• Som 3D e 2D
• Luzes Dinâmicas com Sombra
• Animação por ossos (Bone Animation)
• Terrenos
• Reflexão e Refração em Tempo Real
• Sistema de GUI (HUD)

Foram utilizados diversos algoritmos e técnicas encontradas em jogos que estão atualmente no mercado, sempre que possível escolhíamos algoritmos que exploravam ao máximo a GPU.

O nosso grande diferencial esta no uso da técnica Deferred Shading ao extremo, nenhuma Engine XNA não comercial utiliza esta técnica desta forma.

Para uma lista bem mais completa das funcionalidades, de uma olhada no site do projeto.

Ambient Scattering, Vegetação e Partículas ao fundo

O que você precisa para começar a usar a Ploobs Engine ?

Para um uso mais simples, somente conhecimento básico de C# é necessário, não é preciso conhecer computação gráfica ou XNA.

Para o desenvolvedor, é necessário instalar a XNA 4.0 SDK, o .Net 4.0 Framework e o Visual Studio 2010 completo ou express. Em termos de hardware é necessário apenas ter uma placa de vídeo compatível com DirectX 10 (Shader Model 3.0).

Por onde que eu começo ??!!

Temos uma seção com tutoriais básicos no site do projeto, além de alguns pacotes com diversos demos de funcionalidades (cerca de 30 demos bastante comentados) .

Estamos trabalhando para criar outros tutoriais e alguns demos reais (pequenos Showcases). Junto com a DLL da Engine, temos um documento (.chm) explicando os conceitos básicos da Engine.

Como que a Engine é distribuída ?

Atualmente existem as seguintes formas de distribuição:

Iluminacao e Lod

• Código Fonte Completo através do nosso repositório Mercurial (este repositório contem apenas a ultima versão estável no branch principal).
• DLL Única contendo todas as dependências e documentação.
• Através dos pacotes de Demos.

A idéia é lançar uma versão estável periodicamente e diversas outras versões betas intermediarias. Caso algum bug crítico seja encontrado, iremos corrigir a versão estável o mais rápido possível. Os Demos e o arquivo de documentação serão atualizados apenas no lançamento de versões estáveis, a documentação do site será atualizada assim que as versões intermediárias forem lançadas. Pretendemos manter compatibilidade com as versões antigas sempre que for possível.

Nosso RoadMap

Num futuro próximo pretendemos melhorar a estabilidade, a  documentação e corrigir os bugs que vão “surgindo”, em um futuro um pouco mais distante pretendemos adicionar suporte a Rede.

Junte-se a nós !!!

Iluminacao avancada

Antes de tudo, o projeto não tem fins financeiros.

Precisamos de pessoas que gostem de computação gráfica (não é necessário nenhum conhecimento prévio, temos diversos materiais para auxiliar no aprendizado do pessoal), principalmente programação de  shaders (código que roda na placa de vídeo).

Precisamos também de pessoas dispostas a fazer demos e Showcases (pessoas que não irão entrar em contato com o core da Engine).

Duvidas ? Quer saber mais ? Deixe um comentário aqui ou mande um email: contato@ploobs.com.br

Time Atual

Thiago Dias Pastor – COOP10

Bruno Duarte Correa – COOP10

Links

XNA 4.0 Alpha Release: http://ploobs.com.br/?p=725

Site do projeto: http://ploobsengine.codeplex.com/

DLL, Documentação e Tutoriais (Xna 3.1 Version): http://sourceforge.net/projects/ploobsengine/files/

Nosso Fórum: ploobs.com.br/forum

Nosso Blog: ploobs.com.br/

Nosso Twitter : @ploobsengine

Agradecimentos

• Toda a galera do COOP10 por ter nos aguentado nesses últimos anos, em especial o Filipão e o Kayatt.
• Ao Professor Ricardo Nakamura, nosso orientador no TCC, e seus conselhos sagazes.
• A nossa Equipe da ImaginCup 2010, a experiência adquirida mudou completamente o desenvolvimento da engine.

ScreenShots

Normalizing latin chars (á, é, ç, …) to ASCII chars (a, e, c, …) in our search index and queries was pretty easy. We changed the text field definition to the following schema:

1
2
3
4
5
6
7
8
9

<fieldType name="text" class="solr.TextField" omitNorms="false">
	<analyzer>
		<charFilter class="solr.HTMLStripCharFilterFactory"/> <!-- strip HTML -->
		<tokenizer class="solr.StandardTokenizerFactory"/>
		<filter class="solr.StandardFilterFactory"/>
		<filter class="solr.LowerCaseFilterFactory"/>
		<filter class="solr.ASCIIFoldingFilterFactory"/> <!-- convert accented chars to ASCII -->
	</analyzer>
</fieldType>

A more difficult problem was to sort accented string fields. By default, the class of the sunspot’s string field is solr.StrField. The string field is used for sorting, but was showing problems to sort accented inputs. For the inputs “árvore”, “bola”, “ano” it was showing the sorted result: “ano”, “bola”, “árvore” (the correct result would be “ano”, “árvore”, “bola”).

The problem with accented chars sorting is that non-ASCII chars are represented as HTML entites (for example, á instead of á) and special chars as “&” goes after alphanumeric chars in a sort.

To solve this, we changed the string field’s class to solr.TextField but making sure that its tokenizer would not create more than one token for each entry. The tokenizer we used was the KeywordTokenizer. The final schema for the string field was:

1
2
3
4
5
6
7

<fieldType name="string" class="solr.TextField" omitNorms="true">
	<analyzer>
		<tokenizer class="solr.KeywordTokenizerFactory"/>
		<filter class="solr.LowerCaseFilterFactory"/>
		<filter class="solr.ASCIIFoldingFilterFactory"/>
	</analyzer>
</fieldType>