sBotics Wiki

Tutorial do Simulador usado pela OBR

Ferramentas do usuário

Ferramentas do site


programacao

Programação

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.

Acessando a Tela de Programação

O menu de robôs pode ser acessado através do segundo botão na parte inferior da interface do simulador (HUD).

Menu de Programação

Nesta tela, você pode:

  1. Criar, alterar e excluir programas;
  2. Trocar a linguagem entre BlockEduc, rEduc e C#;
  3. Salvar o programa e enviar para o robô (compilar);
  4. Importar / Exportar arquivos dos programas escritos.

Menu de Programação

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.

Hierarquia de Dificuldades

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:

  1. BlockEduc (Mais fácil)
  2. rEduc (Intermediária)
  3. C# (Mais difícil)

É 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#.

Entendendo a Programação Síncrona (Avançado)

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#)

  • “Enquanto verdadeiro”: Enquanto verdadeiro indiscriminado trava o sBotics, pois ele fica esperando o robô terminar algo que nunca termina para prosseguir executando o simulador.
  • Esperar é importante: Na robótica real, os comandos levam tempo para serem executados. Agora, no sBotics, você precisa usar um comando chamado “esperar” para simular esse tempo de espera. Isso permite que o sBotics continue funcionando enquanto o robô executa suas ações.

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.

Erros Comuns / Crashes

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.

Esgotamento de Memória

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.

Busy Waiting

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”.

Crash Handler

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.

Como Resolvo?

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.

programacao.txt · Última modificação: 2025/04/15 16:34 por 127.0.0.1