No sBotics, a programação do robô é a principal atividade a ser realizada pelo usuário. Esta página explora as funcionalidades do menu de programação, os tipos de programas que você pode fazer e os conceitos importantes para a programação de robôs.
O menu de robôs pode ser acessado através do segundo botão na parte inferior da interface do simulador (HUD).
Nesta tela, você pode:
Dica! Caso seu programa escrito (que não seja BlockEduc) fique muito grande (+700 linhas), recomendamos que use o vscode para programar no simulador, basta ver o botão “Trocar Modos” com o símbolo do vscode para trocar. O vscode é mais eficiente para códigos muito grandes e evita que o simulador fique muito lento com seu código.
As lingugens do sBotics seguem uma hierarquia de dificuldades. Toda programação pode ser convertida para níveis maiores de dificuldade.
Isto é, dada a hierarquia abaixo:
É sempre possível programando a partir de uma linguagem mais fácil converter seu código para uma linguagem mais difícil utilizando a função de trocar linguagem no topo da tela de programação.
Isto é, BlockEduc é um conversor/facilitador de rEduc que é um conversor/facilitador de C#. Todo código feito em BlockEduc é convertido em rEduc que é convertido em C# para ser executado pelo simulador (que internamente só processa C#).
Não pretendemos fazer conversores para linguagens mais fáceis pois o intuito do sBotics é iniciar pessoas a educação de robótica, e queremos que o usuário esteja progredindo em dificuldade e habilidade.
No geral, sempre aconselhamos utilizar o rEduc para seus programas, porém caso não tenha familiaridade com programação em texto ou já saiba programação avançada, não há problemas em utilizar BlockEduc e C#, basta entender que cada uma das linguagens vai trazer vantagens e desvantagens, como menor controle das rotinas no caso do BlockEduc e uma curva de aprendizado difícil no caso do C#.
Imagine que o sBotics é como um palco onde o robô executa suas ações. Em um robô tradicional, ele é o seu próprio palco, onde ele faz as coisas dele sem se preocupar muito com o que pode acontecer com o programa. Se o programa for ineficiente e fizer a memória esgotar, o robô vai apenas desligar ou parar. É importante entender que o sBotics e o seu robô compartilham do mesmo palco. Uma função ineficiente no seu robô pode deixar o sBotics inteiro lento, ou até mesmo esgotar a memória do programa como um todo.
Para pessoas mais estudadas de programação: O sBotics roda na mesma “thread” que o programa do usuário pelo Unity. Antigamente utilizávamos programação em múltiplas threads mas era extremamente ineficiente e causava muitos memory leaks.
Como isso afeta a programação? (em C#)
No rEduc/BlockEduc, o uso de esperar é opcional, já que todas as estruturas de repetição do rEduc / BlockEduc quando convertidas já dispõem de um esperar embutido.
Para os estudados: Busy-waiting não é uma opção, o sBotics não permite que você trave a thread com verificações infinitas e ineficientes, você precisa esperar em algum momento de suas estruturas de repetição para deixar espaço para o simulador “respirar”. Quanto menos espaços forem dados para o simulador respirar, mais lenta será a performance do simulador.
Esta forma de processar tudo no mesmo “palco” (thread) faz com que alguns problemas possam ocorrer caso o usuário não tenha cuidado com o seu próprio código.
Existem alguns erros que podem parecer do simulador, mas são inteiramente causados pela programação do usuário afetando a plataforma de simulação em si.
Quando o simulador fecha aleatóriamente sem nenhuma explicação, muito provavelmente é por que o simulador consumiu mais memória do que é permitido e a aplicação foi encerrada a força. Verifique o uso indiscriminado de variáveis e considere reutilizar variáveis que não estão sendo utilizadas mais. Além disso, o simulador vai ficando pesado conforme o usuário vai utilizando então é sempre recomendável reiniciar o programa pelo menos 1x por hora.
Caso o programa “pare de responder”, e fique com a infame frase “sBotics não está respondendo”, é muito provavelmente pois alguma estrutura de repetição foi utilizada ou de forma indevida (no C# sem nenhum esperar) ou simulador não foi capaz de concluir os comandos da estrutura de repetição no tempo padrão do loop do simulador (pois seu programa está muito pesado). Neste caso, considere colocar um
%esperar%
de 100ms nas suas estruturas de repetição para dar mais tempo para o programa “respirar”.
Caso você veja uma janela como a do lado com este símbolo ou o símbolo do sBotics, é porque o simulador estava prestes a ter um crash / fechar (por um dos motivos já citados) e o “gerenciador de crashes” foi ativado. Porém muito provavelmente indica apenas um esgotamento de memória ou programa muito pesado.
Para resolver problemas com seu código, separe seu código sempre em tarefas, funções e blocos que você pode comentar ou retirar para testar casos isoladamente. Assim você poderá ter uma melhor noção do que está acontecendo e aonde. Na grande maioria dos casos, problemas que resultam em crashes vêm de programação ineficiente, que está com muitos loops e cálculos desnecessários. Verifique as suas estruturas de repetição (enquanto, para, repetir, etc) e se certifique que as funções sendo realizadas estão eficientes, e caso uma funcionalidade seja muito pesada considere sempre colocar um ou mais “esperar
” dentro daquela repetição.