Deployed 47dea40 with MkDocs version: 1.6.0

rinobot-team · Apr 25, 2024 · 45e3a24 · 45e3a24
1 parent 3ec48f0
commit 45e3a24
Show file tree

Hide file tree

Showing 6 changed files with 7 additions and 7 deletions.
diff --git a/framework/communication/index.html b/framework/communication/index.html
@@ -155,7 +155,7 @@
 - Inscrever-se em parâmetros de configuração, receber modificados e atualizá-los (<code>parameter_modification</code>)</p>
 <h2 id="canais-assincronos-e-tasks">Canais Assíncronos e Tasks</h2>
 <p>Já que a comunicação lida com I/O (entrada e saída de dados) e está inativo a maior parte do tempo esperando por esse I/O, ela é implementada como um subcomponente assíncrono (usando a <a href="https://tokio.rs/">crate Tokio do Rust</a>) utilizando o paradigma de <a href="https://en.wikipedia.org/wiki/Message_passing">message passing</a>. As partes da comunicação são executadas como tasks (tarefas) assíncronas que são conectadas via canais de passagem de mensagem. O seguinte diagrama mostra todas as tasks de comunicação como caixas retangulares (exceto as threads dos cyclers, que podem ou não ser vistas como tasks):</p>
-<p><img title="Diagrama de Tasks e mensagens assíncronas" alt="O diagrama mostra a arquitetura de troca de mensagens e tasks entre diferentes módulos do sistema" src="/img/communication_dataflow.drawio.png" width="940" height="508"></p>
+<p><img title="Diagrama de Tasks e mensagens assíncronas" alt="O diagrama mostra a arquitetura de troca de mensagens e tasks entre diferentes módulos do sistema" src="../img/communication_dataflow.drawio.png" width="940" height="508"></p>
 <p>Conexões sólidas representam fluxos de dados implementados com canais. Conexões tracejadas representam o comportamento de inicialização de tasks.</p>
 <h2 id="criacao-de-tasks-e-gerenciamento-de-conexoes">Criação de Tasks e Gerenciamento de Conexões</h2>
 <p>O ponto de entrada é o Runtime de Comunicação, que se trata de uma thread rodando o <a href="https://tokio.rs/tokio/tutorial/async">Runtime Assíncrono do Tokio</a>. Essa thread é iniciada a partir do <a href="../runtime/">Runtime da framework</a>, similarmente ao runtime dos cyclers. O runtime de comunicação da origem à novas tasks e conecta ela por canais:

diff --git a/framework/entry-point/index.html b/framework/entry-point/index.html
@@ -2,7 +2,7 @@
 <html lang="en">
 
 <head>
-        <title>Entry Point dos processos - Docs Tamboerijn  Rinobot-Jaguar</title>
+        <title>Entry Point dos Processos - Docs Tamboerijn  Rinobot-Jaguar</title>
         <meta charset="utf-8">
         <meta http-equiv="X-UA-Compatible" content="IE=edge">
         <meta name="viewport" content="width=device-width, initial-scale=1.0">
@@ -148,7 +148,7 @@
             <!-- block content -->
                 <section class="p-md-5 section-content">
     <article>
-        <p><h1 id="entry-point-dos-processos">Entry Point dos processos</h1>
+        <p><h1 id="entry-point-dos-processos">Entry Point dos Processos</h1>
 <p>O software de controle robótico Tamboerijn pode ser compilado para diferentes plataformas, NAO e Webots. Para cada plataforma há um binário compilado diferente, e um ponto de entrada do programa diferente. Neste documento, vamos explicar o ponto de entrada para cada plataforma. Todos os executáveis definem uma função <code>main()</code> que é o ponto de entrada do programa, veja <code>crates/hulks_nao</code> ou <code>crates/hulks_webots</code> para mais detalhes. Os próximos parágrafos explicam os primeiros passos do programa em ambas as plataformas.</p>
 <h2 id="parametros-de-hardware">Parâmetros de hardware</h2>
 <p>No final da função <code>main()</code>, as interfaces de hardware são criadas. Além do domínio da robótica, a interface de hardware também necessita de alguns parâmetros para inicializar o hardware. Esses parâmetros são lidos de um arquivo JSON que pode ser passado como primeiro argumento na linha de comando do executável. Se omitido, o arquvio padrão <code>etc/parameters/hardware.json</code> é carregado.</p>

diff --git a/framework/nodes/index.html b/framework/nodes/index.html
@@ -150,7 +150,7 @@
     <article>
         <p><h1 id="nodes-nos">Nodes (Nós)</h1>
 <p>Os Nós normalmente contém código de robótica propriamente dito e são intercambiáveis entre cyclers. Cada nó é caracterizado po uma função <code>cycle()</code> que é chamada em cada ciclo. Essa função pega os inputs do nó como parâmetros e retorna os outputs deste node. Além disso, nós possuem um estado que é preservado entre ciclos.</p>
-<p><img title="Diagrama do nó" alt="Funcionamento do nó representado em forma de diagrama, mostra que a entrada e saída de dados na função cicle independe do estado do nó" src="/img/node.drawio.png"></p>
+<p><img title="Diagrama do nó" alt="Funcionamento do nó representado em forma de diagrama, mostra que a entrada e saída de dados na função cicle independe do estado do nó" src="../img/node.drawio.png"></p>
 <p>Nós são structs normais do Rust em que os campos da struct representam o estado, e um método chamado <code>cycle()</code> no <code>impl</code> do nó que representa a função de ciclo. Esse conceito permite escrever os nós na forma mais otimizada para a linguagem Rust. Um nó pode ter multiplos inputs de diferentes tipos que podem ser adicionados ao struct. Aqui está um exemplo de nó, mais informação pode ser encontrada em <a href="../macros/">Macros</a>:   </p>
 <pre><code class="language-rust">pub struct SolePressureFilter { // (1)
     left_sole_pressure: LowPassFilter&lt;f32&gt;,

diff --git a/framework/runtime/index.html b/framework/runtime/index.html
@@ -150,7 +150,7 @@
     <article>
         <p><h1 id="runtime">Runtime</h1>
 <p>O Runtime, ou tempo de execução, é o componente do software que encapsula todos os subcomponentes, como interface de hardware, comunicação, e execução de nós. Aqui está uma imagem mais detalhada do que o Runtime faz:   </p>
-<p><img title="Diagrama do Runtime" alt="Imagem com um diagrama mais detalhado do runtime" src="/img/dataflow.drawio.png"></p>
+<p><img title="Diagrama do Runtime" alt="Imagem com um diagrama mais detalhado do runtime" src="../img/dataflow.drawio.png"></p>
 <p>Essa seção e as subsequentes vão explicar esse diagrama com mais detalhes. Muitas conexões do fluxo de dados não estão representadas para facilitar a compreensão da imagem.</p>
 <p>O Runtime é construído com uma interface de hardware já criada e inicializada pelo código. Ela contém todos os subcomponentes e por isso é responsável por construir e inicializar eles. Subcomponentes precisam ser interconectados entre si. Dessa forma, o runtime cria todos os canais de comunicação necessários, além dos buffers que são compartilhados entre os subcomponentes. Mais detalhes sobre comunicação enter cyclers e comunicação no geral são fornecidas em <a href="../communication/">Comunicação</a>.</p></p>
     </article>

diff --git a/index.html b/index.html
@@ -166,7 +166,7 @@
     <article>
         <p><h1 id="documentacao-do-tamboerijn">Documentação do Tamboerijn</h1>
 <p><em>Disclaimer: This docs are based on the original documentation written by the HULKs team, it has some parts adapted to our team's needs</em></p>
-<p><img title="Bisnaguinha" alt="Imagem do bisnaguinha, nosso robô artilheiro" src="/img/bisnaguinha.jpg" width="320" height="320"></p>
+<p><img title="Bisnaguinha" alt="Imagem do bisnaguinha, nosso robô artilheiro" src="./img/bisnaguinha.jpg" width="320" height="320"></p>
 <h2 id="sobre">Sobre</h2>
 <p>Este respositório tem como objetivo documentar o codebase Tamboerijn, que consiste na adaptação do code realease da equipe alemã HULKs. Ele contém partes traduzidas do inglês para o português, além de algumas adaptações feitas pela equipe para suprir nossos interesses e necessidades internas.</p>
 <p>Ele está sob a licensa GPU 3.0, que pode ser encontrada <a href="./LICENSE">aqui</a>, assim como o repositório original da equipe HULKs, que pode ser encontrado <a href="https://github.com/HULKs/hulk">aqui</a>.</p>

diff --git a/search/search_index.json b/search/search_index.json