Erros comuns

---

Dentro do mundo da programação e do software, os erros podem se apresentar em muitas formas e tipos diferentes. Ao mapear hardware, há dois erros principais que você pode encontrar. Ambos os erros se enquadram em categorias comuns de erros de software:

Erros de Interface - são erros entre como uma interface deveria funcionar e como ela realmente se comporta.

Erros em Tempo de Execução - são erros que ocorrem quando um programa está sendo executado.

Erro de interface

Os erros de interface ocorrem no SDK quando os parâmetros da interface do SDK não são atendidos. No processo de mapeamento de hardware, o erro de interface mais comum ocorre com a ferramenta de programação Blocks. Como mencionado na seção de Introdução à Programação, o Blocks oculta as complexidades da biblioteca do SDK dos usuários. Uma maneira de fazer isso é criando automaticamente referências ao hardwareMap quando trechos de código para uma unidade de hardware externo são usados.

Para automatizar as chamadas ao hardwareMap, a interface Blocks lê o arquivo de configuração e cria variáveis de hardware com base nas informações encontradas. Por esse motivo, é importante criar um arquivo de configuração antes de tentar codificar.

A imagem abaixo mostra duas versões diferentes da interface Blocks. Na versão sem arquivo de configuração, não há menus suspensos para acessar trechos de código específicos para atuadores ou sensores. Na versão da interface com um arquivo de configuração, os menus suspensos estão presentes e os trechos de código específicos para motores estão acessíveis.

Erros de tempo de execução

Dentro do SDK, erros em tempo de execução ocorrem durante a inicialização ou execução. Um dos erros em tempo de execução mais comuns dentro do REV Control System é exemplificado na imagem abaixo.

Esse erro indica uma inconsistência entre como um dispositivo de hardware é chamado no código e como isso se compara ao nome usado no arquivo de configuração. Existem duas maneiras diferentes de ocorrer esse erro.

A primeira ocorrência desse erro é quando não há um arquivo de configuração encontrado. Isso pode significar que um arquivo de configuração não foi criado, um arquivo foi criado, mas não está ativo, ou o arquivo errado está sendo usado. Quando qualquer uma dessas situações acontece, o código está solicitando um nome e tipo de dispositivo que o hardware map não consegue localizar no arquivo de configuração. O programa para no primeiro nome de dispositivo que não consegue localizar.

Uma referência incorreta ao hardwareMap também pode causar esse erro. Ao contrário do Blocks, OnBot Java e Android Studio exigem que um programador codifique manualmente a chamada ao hardwareMap. Se o nome de referência na chamada não corresponder ao nome do dispositivo no arquivo de configuração (é sensível a maiúsculas e minúsculas), o código será compilado sem falhas, mas o erro em tempo de execução ocorrerá. Vamos usar o arquivo de configuração da seção anterior como exemplo, onde há um sensor de toque chamado "test_touch" e um motor chamado "test_motor".

As aspas indicam que "test_touch" e "test_motor" representam uma variável de string que corresponde aos nomes dos dispositivos na configuração.

public class HR_test extends LinearOpMode{
    private DigitalChannel test_touch;
    private DcMotor test_motor;
    
    @Override
    public void runOpMode(){
        //get the touch sensor and motor from hardwareMap 
        test_touch = hardwareMap.get(DigitalChannel.class, "test_touch");
        test_motor = hardwareMap.get(DcMotor.class, "test_moto");
        
    }
}

Observe no exemplo de linhas de código que o hardwareMap.get() para "test_motor" está escrito como "test_moto" em vez de "test_motor". Quando o código está sendo compilado, não há uma verificação imediata de que o nome solicitado está no hardwareMap. Essa verificação é feita quando o código é executado no robô. Quando a comunicação com o hardwareMap é iniciada, ele procura por "test_moto" e, quando não consegue encontrar, cria o erro em tempo de execução mencionado acima.