Rodando Python no Lego Mindstorm

Quem já tentou fazer programação com blocos sabe que chega um ponto em que a produtividade deixa a desejar. Por isso é interessante fazer a programação dos kits Lego Mindstorm usando Python.

Nesse sentido a documentação oficial para fazer isso é bem ampla mas me pareceu possuir algumas lacunas para quem está começando. Foi pensando nisso que eu escrevi esse post.

Caixa de kit lego com o código 31313
Caixa do kit Lego utilizado

Hardware utilizado:

  • 1kit Lego Mindstorm EV3
  • 1 cabo USB
  • 1 notebook
  • 1 cartão microSD de 2GB

Instalando o Python no cartão SD

A documentação oficial diz que o cartão SD deveria ser de, no mínimo, 4GB mas eu utilizei – com sucesso – um cartão de 2GB.

O primeiro passo é baixar a imagem que contém o software necessário para rodar Python no Lego. Essa imagem na verdade é um Linux modificado. No momento da escrita desse texto o link para download é https://education.lego.com/en-us/support/mindstorms-ev3/python-for-ev3.

Tentei usar o software Balena Etcher para gravar a imagem porém ao final o programa mostrava um erro mas não dava mais detalhes do motivo do erro. Talvez seja pelo tamanho do cartão SD. Não fiz um teste com um cartão com maior capacidade.

Para contornar esse erro do Etcher fiz a gravação com o comando dd do Linux. Veja abaixo a linha de comando completa:

cat ev3-micropython-v2.0.0-sd-card-image.img | sudo dd bs=4M of=/dev/sda

Como esse não é um tutorial de Linux, não vou entrar em detalhes, mas resumidamente o comando acima pega o arquivo da imagem e faz a cópia no dispositivo /dev/sda. No meu caso esse era o cartão SD. Confira muito bem se esse é o seu caso pois se você usa um disco rídigo então /dev/sda pode ser um pendrive ou até mesmo o seu disco rígido dependendo dos dispositivos de armazenamento conectados e o comando dd apaga todo o conteúdo anterior do dispositivo. Mesmo se /dev/sda for o seu cartão note que você perderá arquivos que estiverem nele.

Após o comando encerrar, desmonte a unidade e retire o cartão do computador.

Agora insira o cartão no computador Lego e ligue o mesmo. Se der tudo certo após uns 10-15 segundos deverão “correr” letras pequenas na tela do computador Lego.

O vídeo abaixo mostra essa parte do processo. Note que essa inicialização pode demorar. No meu caso a inicialização em si demorou 45 segundos pois a imagem Linux que está no cartão precisa fazer a detecção do hardware entre outras verificações.

Programando com Python

Se a inicialização ocorreu conforme esperado então agora começa a parte mais divertida.

Documentei os passos com as imagens abaixo.

1º Instale a extensão “EV3 Micropython” no Visual Code.

2º Depois que a extensão tiver sido instalada aparece uma opção nova do EV3 Micropython no menu lateral do Visual Code

3º Clicando nessa opção abre um menu um pouco mais pra direita com opções de “Criar um projeto novo”, “Explorar projetos de exemplo” ou “Abrir o guia do usuário”.

4º Clicando em explorar projetos de exemplo vários subtópicos, cada um com vários exemplos aparece na coluna da direita.

5º Depois de clicar em um dos exemplos o menu lateral vai mudar mostrando alguns arquivos. O que nos interessa, por padrão, tem o nome de main.py
Esse é o arquivo do seu exemplo/programa.

6º Clicando no arquivo main.py na coluna principal o código vai ficar disponível para você editar.

7º Uma vez que você criou o seu programa (ou carregou um dos exemplos). É hora de passar o código para o Lego. Conecte o cabo USB no computador e no kit LEGO e verifique a opção “EV3DEV Device Browser” na parte inferior do menu lateral.

8º Fiz alguns testes usando o ambiente Windows e o ambiente Linux (Pop OS! 20.04) e enquanto a detecção ocorreu automaticamente no Windows, no Linux foi necessário desconectar e conectar algumas vezes o cabo USB e clicar em “Click here to connect to a device”. Como eu usei dois notebooks diferentes não sei se o problema é do notebook ou do sistema operacional.

No Linux depois de clicar na opção de conectar, foi preciso escolher o dispositivo em uma menu no centro.

9º Depois do passo anterior (que não foi preciso no Windows) o dispositivo aparece com um ícone verde no menu lateral. O botão redondo, quando está com a cor verde, representa que o dispositivo está pronto para receber o seu código.

10º (Quase lá) Agora é preciso efetivamente passar o código para o EV3. Existe um ícone na extensão que parece com um ícone de download, e que ao passar o mouse mostra o texto “Send workspace to device”. Clicando no ícone o seu código será transferido para o Lego.

11º Se tudo deu certo uma mensagem “Download to ev3dev complete” vai aparecer na parte inferior direita da tela conforme a imagem abaixo.

12º Por via das dúvidas antes de desconectar o cabo USB eu cliquei com o botão direito no dispositivo e cliquei em desconectar. Não diz no manual que isso é necessário mas achei bom garantir para prevenir que corrompimento dos dados.

13º Agora é só dar play no dispositivo e ver a “mágica” acontecer.

Desligando o robô

Se deu tudo certo talvez você fique em dúvida: “como eu desligo o Lego corretamente sem correr o risco de corromper o sistema de arquivos?”

Para fazer isso aperte o botão de “Voltar” e várias opções vão aparecer. Uma delas é desligar “Power Off” o robô. Selecione essa opção e aguarde alguns segundos até o computador desligar.

Rodando o simulador flatland

O que é o flatland? É um “simulador de robôs bidimensional com foco na performance e compatível com ROS”[1].

O vídeo abaixo mostra o flatland em ação:

Fiz a instalação e alguns testes preliminares no Pop! OS 20.04 e usando a versão noetic do ROS. Para outras versões pode ser necessário adaptar algum comando.

Como instalar?

1º) Fazer a instalação do ROS versão Noetic (versão base)

Mais detalhes em http://wiki.ros.org/noetic/Installation/Ubuntu

2º) Instalar as dependências

Precisei instalar as dependências a seguir para o simulador funcionar. Eles englobam vários pacotes e pode ser que alguns deles já estejam instalados no seu sistema. As dependências podem ser instaladas através do apt:

sudo apt install ros-noetic-tf ros-noetic-tf2 ros-noetic-tf2-geometry-msgs ros-noetic-interactive-markers libyaml-cpp-dev qtbase5-dev liblua5.3-dev

3º) Instalar o simulador em si

Seguir o tutorial “Create Plugin Tutorial”: https://flatland-simulator.readthedocs.io/en/latest/flatland_tutorials/create_plugin.html

Até esse ponto, usando o comando roslaunch (último comando do tutorial) deve abrir o simulador sem nada muito interessante

4º) Rodar o modelo básico

Uma vez instalado o flatland é possível criar um modelo básico que pode interagir com o mapa

Para isso siga o tutorial “Quick start”: https://flatland-simulator.readthedocs.io/en/latest/quick_start.html

Se tudo deu certo agora você pode mandar mensagens nos tópicos do ROS controlando o robô.

Se você não entendeu o parágrafo acima e/ou o que é o ROS vale a pena visitar o site do projeto antes de mais nada: https://www.ros.org/

Se você já sabe o que é o ROS e o que é um tópico pode mandar mensagens do tipo Twist para controlar o robô via linha de comando da seguinte maneira

rostopic pub -1 /cmd_vel geometry_msgs/Twist ‘{linear: {x: 1.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}’

O comando acima faz o robô andar para a frente. Se o valor de x for negativo ele vai andar para trás. Para girar o robô modifique o valor de z da velocidade angular.

5) Controlando o robô via Python

Fiz um programa em Python bem básico que faz o robô ser controlável pelo teclado: ‘a’ e ‘z’ fazem o robô andar para frente e para trás respectivamente e ‘s’ e ‘x’ para girar o robô. A tecla ‘q’ faz o robô parar e encerra o programa.

O código está disponível abaixo.

Script em Python para controlar um robô via ROS

Se o ROS estiver corretamente instalado o programa abaixo deve funcionar sem precisar de nenhuma instalação adicional.

Referências:

[1] Site do flatland https://flatland-simulator.readthedocs.io/en/latest/index.html

[2] Site do ROS https://www.ros.org/

E-mail: alguém ainda te ama, ou: Comparando e-mail e Whatsapp

Sugestão de trilha pra ler esse texto: Queen – Radio Gaga

Corro o risco desse texto envelhecer mal mas acho que ainda assim vale a pena listar alguns motivos pelos quais acredito que o e-mail é uma tecnologia que ainda tem seu espaço.

Principalmente considerando que eu tenho visto uma ampla adoção do Whatsapp como principal meio de comunicação online, alguns dos argumentos abaixo se aplicam mais em comparação com relação ao Whats mas tentarei escrever de modo suficientemente genérico.

Muitas das vantagens são decorrentes de e-mail ser uma tecnologia aberta E bem consolidada mas achei interessante deixar explícito esses argumentos mesmo assim.

E-mail permite você filtrar mensagens

Com e-mail você consegue selecionar e filtrar mensagens baseado em vários critérios: assunto, texto, remetente, destinatário, tamanho da mensagem, data de envio. Tente encontrar uma mensagem antiga com Whatsapp. Boa sorte!

E-mail permite que você selecione várias mensagens

Essa é diretamente relacionada com o anterior. Como você consegue filtrar a maioria (todos) os clientes permitem que você selecione facilmente várias mensagens. E aí você pode fazer o que achar pertinente com as mensagens: copiar, salvar, encaminhar, etc. Tente selecionar centenas de mensagens com o Whatsapp.

E-mail te dá os meios para respeitar sua privacidade

Embora muita gente não use corretamente os campos cc e bcc (relembrando: o ideal quando não quiser que os destinatários saibam uns dos outros é sempre usar o campo bcc – de BLIND carbon copy) as ferramentas estão ali. E na pior das hipóteses alguém vai saber teu e-mail. No Whatsapp a sua informação de contato é o seu número de telefone! Ou seja, as pessoas podem passar teu número para outras e alguém pode te ligar!?! (o que em 2022 é praticamente uma gafe, salvo exceções).

Além disso ninguém sabe quando você está online, quando e se visualizou uma mensagem.

E-mail é um padrão aberto

Como e-mail é um padrão aberto isso permite que o padrão seja adotado por ferramentas de diferentes fornecedores que vão concorrer entre si, teoricamente entregando produtos melhores. Diferente do Whatsapp que é um padrão fechado. Qualquer ferramenta ou mudança no Whatsapp tem que passar pelo crivo da empresa.

E-mail permite separar conversas por assuntos

Os grupos no Whatsapp são uma grande bagunça. Tente procurar algo de meses atrás. Em comparação o nosso querido e-mail permite agrupar as mensagens por assuntos.

Não repudio

Uma vez que alguém te mandou uma mensagem de e-mail ela está com você. Diferente do Whatsapp que alguém pode mandar uma mensagem e depois deletá-la. E aí quando você precisar daquela mensagem meses depois não tem mais.

A mesma mensagem gera múltiplas notificações

Se uma pessoa mandar uma mesma mensagem para vários grupos em que você está você vai receber várias notificações daquela mensagem como se fossem conteúdos diferentes!

Teria mais argumentos mas acho já defendi meu ponto. Vamos usar mais e-mail? Quem está comigo? Deixe nos comentários se eu tiver esquecido algum motivo importante para usar e-mail ao invés de Whatsapp.

Claro que e-mail não é perfeito e tem vários defeitos. Enquanto não surge um e-mail 2.0 (com as vantagens acima) ainda acho que o e-mail é mil vezes preferível, principalmente quando comparado com o Whatsapp.

Bônus 1

Não sei se é um problema que só ocorre no Brasil mas como as operadoras de celular reutilizam os números caso sua linha seja cancelada outra pessoa pode ter acesso a informações suas e se passar por você!?!?! Leia abaixo um assustador relato disso:

https://threadreaderapp.com/thread/1565788165595594754.html

Bônus 2

Uma outra coisa que me irrita no Whatsapp (decorrente do fato de ser um padrão fechado) é que você só pode fixar duas mensagens (Porque exatamente duas e não quantas eu quiser?)

Começando o Projeto Ágora (PrAgora) ou: Escolhendo um framework PHP para um projeto novo

Esse post marca o anúncio público do Projeto Ágora (apelidado de PrAgora por questões de Google Fu). A idéia desse projeto nasceu da minha desilusão com a política. Minha curta experiência em política partidária me indicou que não existe democracia interna em organizações brasileiras, especialmente partidos políticos.

Será que as organizações não implementam esses processos por falta de vontade ou de condições tecnológicas? Se for por ausência de condições tecnológicas talvez seja algo em que eu possa dar alguma contribuição, ainda que modesta. Pensei então que poderia haver um sistema que servisse de base tecnológica para organizações que quisessem democratizar seus processos internos.

De maneira objetiva quero implementar principalmente dois módulos:

  • Um de proposições, em que seja possível “positivar” as proposições de maneira que, ao atingir certa quantidade de upvotes a proposição seja discutida/debatida nas lideranças da organização – evitando que as lideranças deixem certas propostas “debaixo do tapete”;
  • Outro de votações, em que seja possível votar em propostas, e que, mediante configuração, seja possível visualizar quem votou no que, proporcionando transparência ao sistema;

Propositalmente não irei implementar funcionalidades que já existem em outros espaços tais como:

  • Sistema de comunicação por tópicos (já existente em sistemas de fóruns ou grupos de e-mail);
  • Comunicação rápida (já existente em sistemas como Whatsapp ou Telegram);

Fiz questão que o primeiro commit fosse em um simbólico 7 de setembro. Mas desde lá não havia escrito uma linha de código pois estava maturando a idéia.

Decidi então que hoje pode ser um momento propício para mais alguns passos.

O primeiro passo foi escolher a tecnologia. (In)felizmente hoje existe uma infinidade de possibilidades tecnológicas então existe o risco da paralisia por indecisão diante desses múltiplos caminhos.

Para me ajudar defini alguns princípios para o projeto. Como eu quero que o projeto seja usado por organizações de muitos tipos ele tem que ser:

  • Fácil de instalar e de usar
  • Baseado em tecnologias baratas, se possível gratuitas e livres

Inicialmente escolhi a linguagem PHP pois um ambiente PHP é algo relativamente simples de configurar e amplamente disponível em hospedagens compartilhadas por aí. Além disso, como eu estou atualmente trabalhando como professor de Programação Web achei que seria interessante me inteirar um pouco melhor do ecossistema PHP.

Bom, até mesmo por esse ser um side project, achei que não seria pertinente fazer um projeto totalmente do zero então o próximo passo foi escolher um framework PHP.

Após algumas leituras: “10 Best PHP Frameworks To Use in 2021” e especialmente “Os Frameworks PHP mais Populares para Usar em 2022” separei principalmente Codeigniter, Cakephp, Slim e Fuelphp esses por terem menos dependências segundo o segundo link citado.

Também considerei em alguns momentos anteriores usar o Laravel mas olhei o site do Laravel e achei a documentação básica muito ruim: ela primeiro explica, em detalhes, cada conceito do framework ao invés de ser mais direto ao ponto. Não acho essa uma boa abordagem para frameworks web. Ou seja, antes de mostrar as vantagens ele tenta entrar nos meandros do mesmo. Também procurei fontes alternativas ao site oficial mas aparentemente a documentação introdutória do Laravel, se existe, é principalmente em vídeos, o que eu não considero o ideal.

Fiz uma busca no Google Trends para ter uma idéia de popularidade também, afinal se o objetivo é que o projeto seja popular acho que esse aspecto não pode ser desprezado.

O resultado foi o da imagem abaixo:

Quem quiser refazer essa pesquisa com outros parâmetros pode fazê-la no seguinte link: https://trends.google.com.br/trends/explore?q=%2Fm%2F02qgdkj,%2Fm%2F09t3sp,Slim%20php,Fuel%20PHP,Laravel%20php

Adicionei o Laravel na pesquisa acima mais para ter um parâmetro. Confesso que eu achava que o Laravel tivesse um destaque bem maior nessa pesquisa. Segundo essa fonte o CodeIgniter está com uma popularidade semelhante ao Laravel.

Também consultei essa página do Slant: https://www.slant.co/topics/1183/~best-php-frameworks que mostra o Slim PHP como o preferido dessa comunidade.

Embora o primeiro lugar do Slant esteja diferente do Google Trends, o Fuel está mal posicionado em ambos e acabei descartando o Fuel por esses critérios.

Restou então nesse ponto CodeIgniter, Cakephp e Slim. Dei uma olhada na documentação dos três e embora as três parecem bem melhores do que a do Laravel me chamou atenção positivamente no Slim uma informação bem destacada de como fazer o deploy de uma aplicação.

Porém, consultando a própria documentação vi que tanto CodeIgniter quanto Slim não possuem um módulo de autenticação integrado ao framework. Esse funcionalidade é provida através de plugins de terceiros. Talvez isso faça sentido para algumas aplicações porém não é o meu caso então considerei um parâmetro importante.

Nesse ponto, pelos motivos expostos acima, eu já estava mais inclinado a escolher o Cakephp. Também preciso ser intelectualmente honesto e dizer que eu já tive uma experiência prévia com Cakephp e que a experiência na ocasião foi relativamente positiva. Digo relativamente pois na época eu vinha do mundo Rails e usar Cakephp, na época, me pareceu um downgrade pessoal. Em minha defesa, foi um projeto em equipe e não uma EUquipe como é o caso, nesse momento, do PrAgora.

Pretendo fazer outras postagens sobre o PrAgora mas quem quiser acompanhar com mais detalhes pode seguir o projeto pelo Github: https://github.com/viniciusalveshax/PrAgora

Deixo a pergunta pra você que chegou até aqui: o que você achou do processo descrito acima? O que faria diferente? O que achou interessante?

PS: No commit sobrecitado o nome do repositório consta como democracyOS. Optei por renomear o projeto por vários motivos: primeiro que democracyOS, por si, é um pouco clichê. Sem mencionar que eu não estou desenvolvendo um Sistema Operacional. Além disso nesse período refleti um pouco e acho que o que eu queria tentar reproduzir é uma espécie de Ágora grega (pelo menos na versão romantizada que a palavra remete – não sou especialista em história da Grécia, desculpem). Por último, mas não menos importante, achei divertido que Ágora tem uma grafia semelhante com a palavra Agora do português. E esse urgência de algo que precisa ser feito hoje, e não amanhã também condiz com a minha visão para o projeto.

Linguagens interpretadas e linguagens compiladas

Existe um número enorme de linguagens de programação. Mesmo levando em consideração somente as principais elas podem ser contadas em centenas: https://en.wikipedia.org/wiki/List_of_programming_languages. Portanto é natural que existam diversas maneiras de classificar as linguagens de programação.

Uma das classificações possíveis e que pode gerar dúvidas para iniciantes é quanto ao modo em que as linguagens são implementadas. Existem duas principais maneiras de implementar uma linguagem de programação: através de um compilador ou através de um interpretador.

Esse texto busca esclarecer esses conceitos e as diferenças entre eles. Dependendo qual foi a primeira linguagem que você aprendeu ou pretende aprender um dos dois pode parecer ser mais “natural” para você.

Programa compilado

Uma das linguagens de programação mais antigas, o Fortran, usava o caminho da compilação e pode-se dizer que durante muitos anos esse caminho foi o dominante no projeto de linguagens. Linguagens como C e C++ que por décadas dominaram o mercado usaram esse método.

Qual é a proposta da compilação?

A idéia é ter um programa, chamado de compilador, que irá ler um arquivo escrito em uma linguagem de alto nível (C, C++, Fortran, etc) e irá transformar esse resultado em código binário executável.

Esse código geralmente é um programa independente que pode ser executado mesmo que o compilador seja, por exemplo, desinstalado.

Veja, por exemplo, a imagem abaixo, na qual um programa (escrito na linguagem C) é compilado com o gcc (gcc é a sigla para Gnu C Compiler) e depois que o programa final é gerado (essa etapa da geração se chama compilação) podemos simplesmente executar o arquivo “programa” que foi gerado.

Nesse caso mesmo que o programa “gcc” fosse desinstalado, o programa final poderia ser executado sem problemas. Da mesma maneira poderíamos copiar o programa para outro computador e o mesmo também funcionaria (desde que o ambiente disponível para EXECUÇÃO estivesse disponível). Poderíamos até mesmo deletar o arquivo fonte original exemplo.c e o programa continuaria executando.

Ou seja: na implementação via compilador temos duas etapas bem separadas e relativamente independentes: a COMPILAÇÃO, na qual o programa é gerado, e a EXECUÇÃO do programa.

Essa separação tem algumas vantagens e algumas desvantagens.

Vantagens:

Como o programa gerado é um código binário pronto a etapa de execução tem uma performance maior. Não é preciso usar o processador do computador para decidir como o programa irá se comportar. Certo ou não (dependendo se o programa tem bugs), o seu comportamento já está definido. Esse aumento de performance é significativo e em muitos sistemas nos quais o desempenho é algo MUITO importante pode ser mais interessante usar linguagens compiladas. Por isso que quase todos os sistemas operacionais são gerados a partir do processo de compilação (na verdade existem alguns detalhes adicionais mas isso pode ser tema para outro texto).

O programa, uma vez gerado, não precisa do compilador instalado. Isso permite economia de disco pois em ambientes de produção não precisamos ter o compilador instalado. Em certas circunstâncias isso pode até melhorar a segurança geral de um sistema afinal nunca é recomendável deixar compiladores em sistemas que podem ser alvos de atacantes.

Desvantagens:

O processo de desenvolvimento acaba sendo um pouco mais tedioso pois o desenvolvedor precisa, enquanto está desenvolvendo e testando o sistema, realizar duas etapas: compilar e executar ao invés de uma. Claro que certas automatizações podem ser feitas mas isso leva a outro problema do método de compilação.

A demora na compilação: dependendo da complexidade e tamanho do programa a compilação pode levar vários minutos. Então o desenvolvedor manda o programa compilar e precisa aguardar, às vezes um tempo considerável, até o programa concluir a compilação. Para não mencionar que alguns programas podem consumir algum tempo e nem terminar de compilar, por algum erro de programação por exemplo.

Programa interpretado

Algumas das linguagens mais usadas atualmente são interpretadas: Python, Javascript, Ruby, PHP, etc.

Aqui o processo de desenvolvimento é diferente. Vejamos esse exemplo de um programa em Python.

Observe que aqui, ao invés de compilar o programa o executamos chamando “python3 programa.py”. O que está acontecendo aqui? python3 é um programa que chamamos de interpretador. Ao invés de transformar o arquivo fonte programa.py em um arquivo binário o interpretador lê o arquivo citado, uma linha por vez, e na medida do possível – se não houver erros – vai executando o arquivo.

Esse processo de leitura do arquivo-fonte e interpretação do mesmo é feito a cada execução do programa. Ou seja, o nosso programa python precisa do interpretador e do arquivo fonte em cada uma das suas execuções. Se deletássemos o arquivo programa.py, ao tentar executar novamente a linha “python3 programa.py” resultaria em um erro.

As vantagens e desvantagens são praticamente o inverso de um programa compilado.

Vantagens:

O desenvolvimento é um pouco mais rápido: não é preciso realizar duas etapas para ver o resultado do programa. Além disso o interpretador começa a executar mais rapidamente e assim que um erro é detectado a interpretação para. Em geral, erros simples acabam sendo detectados em menos tempo pois não é preciso esperar o término da compilação.

Desvantagens:

Como o programa é sempre lido e interpretado existe uma perda de performance devido ao retrabalho considerando múltiplas execuções. Além disso o próprio interpretador precisa de um tempo para executar e tomar decisões. Em programas compilados pode-se dizer que a maioria dessas decisões são tomadas na compilação tornando a execução mais rápida.

O interpretador precisa estar disponível senão o programa não funciona. Isso pode levar a um aumento do uso de disco rígido.

Caminhos intermediários

Claro que a divisão acima é essencialmente teórica. Existem inclusive propostas híbridas sendo a de maior destaque a linguagem Java. Em java existe a etapa da compilação porém o resultado da mesma não é um código binário diretamente executável mas sim um código simplificado chamado de bytecode. Esse código, por ser simplificado executa muito rapidamente mas ainda precisa de um tipo de interpretador, que no caso da linguagem Java é chamado de Java Virtual Machine (JVM) ou Máquina Virtual Java.

O Java foi implementado dessa maneira para ter um interpretador mais eficiente porém com a possibilidade de compartilhar código para diversos hardwares (a proposta inicial do Java era escrever um único código e executar o mesmo – através da jvm – em diversos hardwares diferentes, como por exemplo aparelhos celulares).

Hoje muitas linguagens adotam uma solução próxima da linguagem Java. Inclusive muitas linguagens foram adaptadas para gerar bytecode e portanto utilizar a eficiente jvm mesmo que o código-fonte seja criado em outras linguagens.

Uma solução intermediária ligeiramente diferente é rodar código interpretado durante o desenvolvimento e gerar uma espécie de bytecode (usar um compilador) somente no ambiente de produção com o código já plenamente desenvolvido e teoricamente testado.

Conclusão

De maneira geral podemos resumir que devido à melhoria do hardware a implementação via interpretador ganhou força ao longo do tempo. A estratégia da compilação ainda persiste mais utilizada em ambientes nas quais a performance precisa ser extraída ao máximo como, por exemplo sistemas operacionais e jogos. Em outros ambientes nos quais a velocidade de desenvolvimento e alteração dos sistemas tem uma importância maior acaba favorecendo linguagens interpretadas.

Dito isso é importante notar que na verdade nada impede que, na teoria, uma linguagem projetada para ser compilada seja executada através de um interpretador ou que uma linguagem originalmente interpretada não possa ser compilada. Mas, na prática, isso não é muito comum já que linguagens acabam sendo mais adotadas ou em um contexto de compilação, interpretação ou em uma mistura de ambos, caso da linguagem Java.

Resolvendo problema de compatibilidade entre java e javac

Me deparei (sic) com um problema ao tentar executar um código Java.

Primeiro eu compilei o programa normalmente com javac. Porém ao tentar executar o programa apareceu a mensagem de erro abaixo:

Transcrição de parte do erro:

“Error: A JNI error has occurred, please check your installation and try again
Exception in thread “main” java.lang.UnsupportedClassVersionError: Aleatorios has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0″

Usando os comandos which e ls descobri que javac apontava para /usr/lib/jvm/java-11-openjdk-amd64/bin/javac e java apontava para /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, claramente versões diferentes do Java, o que era condizente com o erro acima. Lembro vagamente de ter alterado a versão do runtime Java (não me lembro o motivo) mas eu acreditava que o javac mudava junto. Parece que não.

Bom, com o comando

sudo update-alternatives --config java

Selecionei a versão mais recente do Java (mesma versão do javac).

E aí agora tudo voltou a funcionar. Espero ter ajudado alguém.

Referência utilizada: https://aboullaite.me/switching-between-java-versions-on-ubuntu-linux/

Palestra Tchelinux Live 2021 – Detecção de objetos com imagens usando Keras e Python

Link da palestra:

Alguns links de referência para quem assistiu a palestra

Apresentação no Tchelinux 2020

Artigos do prof. Ricardo:

https://ricardomatsumura.medium.com/material-de-apoio-para-aulas-de-intelig%C3%AAncia-artificial-e-aprendizado-ce43543e886d

Site do PinguimBots:

http://www.pinguimbots.com/


Artigo no qual baseamos a versão inicial do nosso código:

Código no GitHub

https://github.com/viniciusalveshax/object-detection-2021

Palestra Tchelinux Live 2020 – Introdução à IA e Aprendizado de Máquina com Ferramentas Livres

Para quem assistiu a palestra do Tchelinux Live deixo algum material complementar.

Ted Talk – The first 20 hours – Josh Kaufmann:

Trailer do filme Robocop (envelheceu bem):

Robôs da Boston Dynamics (assista com ceticismo):

Dataset utilizado:

Descrição: PALECHOR, Fabio Mendoza; DE LA HOZ MANOTAS, Alexis. Dataset for estimation
of obesity levels based on eating habits and physical condition in individuals from
Colombia, Peru and Mexico. Data in brief, v. 25, p. 104344, 2019.

Onde baixar: https://archive.ics.uci.edu/ml/datasets/Estimation+of+obesity+levels+based+on+eating+habits+and+physical+condition+

Arquivos da apresentação (incluindo o código):

https://github.com/viniciusah/conteudos_diversos/tree/main/tchelinux-live-2020

Para saber mais sobre IA e robótica acesse:

Agradecimentos

Ao prof. Ricardo (http://www.ricardoaraujo.net/) e ao grupo PinguimBots (http://www.pinguimbots.com/) pelo grande aprendizado que proporcionou essa palestra;

A organização do evento Tchelinux Live, especialmente Leo Vaz, Diego Costa e Rafael Jeffman;

A todo mundo que prestigiou a palestra e esse texto, incluindo você 🙂

Olá, mundo!

Começando então um novo projeto que eu pretendo utilizar para centralizar conteúdos interessantes que tenham relação com computação e TI