TTY​

Teletype
(https://en.wikipedia.org/wiki/Teleprinter)

Teletype é uma typewriter elétrica com o propósito de enviar e receber dados.

Tenha em mente que estamos falando de uma época que inicialmente não possuia monitores (onde o meio de comunicação principal era papel) e de uma máquina que mudou bastante durante o tempo... Não espere precisão de mim.

• Originalmente substituiu os tradutores de morse code, pois elas conseguiam ler e escrever morse code.
• Com o tempo elas evoluiram para ler e escrever punched tapes, que eram a maneira de computadores armazenarem dados na época (antes de HD/SSD).
• Consequentemente evoluiram para quando conectadas a um computador (na época antes de monitores aparecerem) serem capazes de ler e escrever a ele.

Não existe melhor maneira de entender do que ver pessoas que restauraram esse tipo de ferramenta:
https://www.youtube.com/watch?v=S81GyMKH7zw

É baseado nessa ferramenta que TTY em linux existe, infelizmente ainda não terminei o estudo de como funciona e o que faz:
https://www.linusakesson.net/programming/tty/

Terminal​

(https://en.wikipedia.org/wiki/Computer_terminal)

Teletypes originalmente eram conhecidas como "hard-copy terminals" por usarem papel, mas com a vinda de telas nós formamos uma nova ideia de terminal nas nossas cabeças (a tela preta).

Terminal não possui armazenamento de dados, da mesma maneira que teletypes apenas eram responsáveis por ler e escrever do computador, ou seja, a lógica ainda estava no computador. Alguns terminais possuiam um pouco de lógica neles porém nada comparado ao computador.

Se você viu o video da sessão anterior então já deve ter ganhado uma ideia do que é um terminal, pois nele é mostrado uma teletype lendo e escrevendo para um terminal.
Mas caso queira outro video mostrando melhor um terminal:
https://www.youtube.com/watch?v=UNdu0YQfvF0

Terminal Emulator​

(https://en.wikipedia.org/wiki/Terminal_emulator)

Hoje em dia usamos o termo terminal para representarmos emuladores de terminais.

Diferentemente de terminais, estes estão fortemente ligados a computador e não são máquinas separadas da lógica. Basicamente estamos falando da janela que finge ser um terminal (GNOME terminal).

Shell​

(https://en.wikipedia.org/wiki/Shell_script)

Um programa responsável por ficar em loop esperando comandos do usuário para serem executados.

Comandos podem ser:

• Programas
  • echo
  • ls
  • touch
  • mkdir
  • Buscados em lugares pré definidos (/bin, /usr/bin, ...)
    • Use echo $PATH para ver a lista de lugares a se olhar
• Comandos do próprio shell
  • type
  • which
  • help
  • man
  • Estes existem dentro do shell e não precisam ser buscados.
• Shell functions
• Aliases
  • Comandos definidos por nós, construido de outros comandos

Existem variações e alternativas de shell:

• Bash
• Zsh
• Fish

CLI​

Command-line interface
(https://en.wikipedia.org/wiki/Command-line_interface)

É uma interface, ou seja, maneira do programa dar mais controle ao usuário sobre o programa.

Está interface se basea no usuário passar flags e mais informações em conjunto ao comando, dessa maneira mudando o comportamento do commando. Por exemplo, o programa ls disponibiliza diversas flags para alterar o comportamento:

• ls
  • Lista tudo no diretório atual mas ignora os começando com .
• ls -a
  • Lista tudo no diretório atual e não ignora os começando com .
• ls -l
  • Lista tudo no diretório atual mas com mais detalhes

Fique bem claro que é o programa te dando opções de como interagir com ele, não o shell ou terminal, então resta ao programa implementar comportamentos para certas flags.

TUI​

Terminal user interface
(https://en.wikipedia.org/wiki/Text-based_user_interface)

Novamente é uma interface, ou seja, maneira do programa dar mais controle ao usuário sobre o programa. Porém está foca em dar uma interação mais visual e continua.

Diferente de CLI's onde toda a interação começa e termina em um comando só, TUI's continuam esperando mais interações do usuário até um dos dois decidirem terminar.

Um exemplo bem comum é top que providência uma visão dos programas/processos/threads em execução do sistema, uma vez inicializado ele esperar por mais interações do usuário. Se você apertar q ele termina, se você apertar h ele fornece a lista de comandos, etc.

Note que a TUI's ainda podem providênciar flags para alterar o comportamento (top --help).

GUI​

Graphical user interface
(https://en.wikipedia.org/wiki/Graphical_user_interface)

Novamente é uma interface, ou seja, maneira do programa dar mais controle ao usuário sobre o programa. Porém não está limitada a usar texto para a visualização, pois tem a capacidade de desenhar na tela.

Hoje em dia é o meio mais popular de se usar uma aplicação, quando se abre VSCode, Google Chrome, Discord... Todos são GUI's pois utilizaram a capacidade de desenhar para dar uma interface ao usuário.

Mesmo programas focados em GUI's podem aceitar flags (VSCode: code --help).

References​

• https://en.wikipedia.org/wiki/System_console
• https://www.linusakesson.net/programming/tty/
• https://linuxcommand.org/lc3_lts0010.php
• https://linuxcommand.org/lc3_lts0060.php
• https://www.youtube.com/watch?v=wIjgZhAjQS4
• https://www.youtube.com/watch?v=ztsOwk1zB3o
• https://www.youtube.com/watch?v=SYwbEcNrcjI
• https://www.youtube.com/watch?v=byMwNPj47X8
• https://www.youtube.com/watch?v=S81GyMKH7zw

Durante o post C/C++ Libs escrevi sobre usar bibliotecas no Linux e nunca imaginaria que teria novamente a dor de cabeça de ver o assunto quando fosse fazer o mesmo no Windows.

.lib (library)​

Basicamente idêntico ao .a do Linux, uma biblioteca estática (static library).

.dll (dynamic-link library)​

Seria o próximo do .so do Linux, servindo o mesmo propósito de uma biblioteca compartilhada (shared library) porém o Windows possui uma implementação própria deles (dynamic-link library).

A grande diferença que precisamos saber é que durante a criação de bibliotecas compartilhadas, três formatos de arquivos são criados: .dll, .lib e .exp (vamos ignorar este último).

Onde o arquivo .lib NÃO é o mesmo que o gerado durante a biblioteca estática! Porém ainda é necessário para a utilização da biblioteca compartilhada.

Project from Zero​

Seguiremos a mesma ideia do post no Linux. Apenas tendo o nosso código:

project/
└── src/
    ├── main.c
    └── ...

cl src\main.c

Agora com um header:

project/
├── include/
│   └── header.h
└── src/
    ├── main.c
    └── ...

cl src/main.c /Iinclude

.lib​

project/
├── include/
│   └── header.h
├── lib/
│   └── name.lib
└── src/
    ├── main.c
    └── ...

cl src/main.c /Iinclude lib/name.lib

.dll​

Dessa vez vamos separar em duas etapas: compilar o código para .obj e depois linkar (gerar o .exe), isso torna mais fácil adicionar explicações no meio.

project/
├── include/
│   └── header.h
├── lib/
│   └── name.lib
└── src/
│   ├── main.c
│   └── ...
└──  name.dll

Lembre que bibliotecas dinâmicas no Windows utilizam um arquivo .dll e um .lib (por isso temos os dois no projeto).
Windows busca os arquivos .dll na mesma pasta do executável, por isso ele não está na pasta lib.

cl src/main.c /c /Iinclude /Dexample

/c é justamente para pausar antes de linkar.
/Dexample é uma maneira de adicionar uma definição no início do código, equivalente a

#define example

Por que precisamos definir? Em bibliotecas do Windows, muitas vezes pode se encontrar código como o seguinte:

#if defined(EXPORT_DLL)
    #define LIB_API __declspec(dllexport)
#elif defined(IMPORT_DLL)
    #define LIB_API __declspec(dllimport)
#else
    #define LIB_API
#endif

Onde LIB_API é substituido por:

• __declspec(dllexport) quando criando uma biblioteca dinânmica
• __declspec(dllimport) quando importando uma biblioteca dinâmica
• nada quando é uma biblioteca estática

Não entendo bem do assunto então não pretendo entrar no assunto, mas é a maneira do windows lidar com bibliotecas dinâmicas.

Biblitoecas geralmente requerem que você passe essa definição para que ela adicione o contexto certo ao código durante a criação do objeto (para fazer name mangling corretamente?).

link /LIBPATH:lib name.lib main.obj

É durante a etapa de linkar que o arquivo .lib é finalmente utilizado!

Lembrando novamente que o executável vai buscar o .dll na pasta do executável, então bote ambos juntos.

Forward And Backward Reaching Inverse Kinematics (FABRIK) é a última kinematic que veremos. É utilizada para cadeias de ossos também mas apenas precisamos de uma iteração para definir o estado final (diferentemente da CCD).

Forward And Backward Reaching​

A idéia é duas caminhadas na cadeia de ossos, a primeira irá mover os ossos em direção ao alvo (forward) e a segunda vai voltar o osso a base (backward).

A operação importante a se entender durante as duas etapas é ação de alcançar um outro ponto (reaching). Vamos utilizar ela durante as duas etapas então é bom entender isto primeiro.

Reaching​

Alcançar um alvo é dividido em 2 etapas, olhar para o alvo e mover até o alvo.

Na primeira etapa podemos utilizar a mesma lógica do look at ou usar a função que sua game engine disponibilizar para rotacionar até um ponto.

Para mover até o ponto é preciso usar o tamanho do osso e calcular onde seria o novo ponto da base do osso. Visualizar onde seria é algo bem simples:

Calcular isso envolve conseguir criar um vetor que represente o osso. Primeiro precisamos saber o vetor em que o osso se encontra, o vetor do ponto inicial dele até o alvo.

Vetor = Posição do alvo - Posição do osso

Com isto podemos calcular a proporção desse vetor com o vetor do osso. Em outras palavras, qual o tamanho do vetor do osso em relação a esse vetor? É duas vezes o tamanho deste? É três vezes o tamanho? É metade desse vetor?

Tamanho do vetor = √(Vetor.x² + Vetor.y²)
Proporção = Tamanho do osso / Tamanho do vetor

Utilizando essa proporção podemos criar um vetor do tamanho do osso.

Vetor osso = Vetor * Proporção

A última coisa é calcular o novo ponto onde o osso deve inciar. Basta pegar o ponto do alvo e reduzir pelo vetor do osso.

Posição do osso = Posição do alvo - Vetor osso

Pronto, sabemos onde botar o osso e podemos mover ele para lá (caso você já não tenha movido ele na última operação)

Forward​

A primeira caminhada pela cadeia de ossos envolve fazer cada osso andar em direção (forward) ao osso seguinte. No caso da ponta da cadeia, ela irá mover em direção ao alvo.

O ponto vermelho irá representar onde globalmente o início do osso atual está, nós usamos ele para decidir onde o osso seguinte vai alcançar.

Estou pausando aqui para lembrar que movimentar e rotacionar um osso afeta todos os filhos, por isto os ossos filhos são movimentados e rotacionados de forma a ficarem "piores" (mais longe do alvo).

O osso seguinte irá utilizar o osso anterior como referência, seguimos essa tática para cada um dos ossos.

O ponto azul representa a base da cadeia e é um ponto de referência que usaremos na próxima caminhada.

Backward​

Nós focaremos agora a mover os ossos em direção a base, ou seja, eles caminharam para tráz (backward). Dessa vez não precisamos nos preocupar em rotacionar, apenas mover para o final do osso anterior.

Iteration​

Ao final de uma iteração podemos ter algo errado como visto acima, mas se repetirmos mais vezes vamos começar a caminhar para algo melhor.

O que acontece se começarmos outra iteração? Vamos começar novamente rotacionando o osso da ponta.

Se você der zoom na imagem, vai notar que o último osso passou do ponto alvo. Mas a etapa seguinte é mover de forma que o ponto final do osso bata com a posição do alvo.

Bem, agora o osso seguinte está incorreto... Mas se continuarmos repetindo o processo...

Aos poucos os ossos vão indo para uma posição melhor, mas eu não pretendo mostra-lo uma segunda iteração pois eu fiz estes desenhos a mão. 🤣

Conclusion​

O código simplificado em GDScript (linguagem do Godot):

for i in iterations:
    _apply_forwards()
    _apply_backwards(base_global_position)


func _apply_forwards() -> void:
    # O osso da ponta vai morar no alvo, os seguintes vão tratar o anterior como alvo.
    var target_global_position: Vector2 = target.global_position

    # Esse array leva da ponta até a base.
    for bone in chain:
        # Rotaciona em direção ao alvo.
        bone.look_at(target_global_position)

        # Evita calcular ratio como infinito.
        if target_global_position == bone.global_position:
            continue
        
        # Calcula a nova posição do osso.
        var stretch: Vector2 = target_global_position - bone.global_position
        var ratio: float = bone.get_bone_length() / stretch.length()
        bone.global_position = target_global_position - stretch * ratio
        
        # Define o alvo do osso seguinte.
        target_global_position = bone.global_position


func _apply_backwards(base_global_position: Vector2) -> void:
    # Esse array leva da ponta até a base, então agora precisamos caminhar ao contrário.
    for i in range(chain.size() - 1, -1, -1):
        var bone: Bone = chain[i]
        
        bone.global_position = base_global_position
        
        # Calcula a posição do osso seguinte.
        var direction := Vector2(cos(bone.global_rotation), sin(bone.global_rotation))
        base_global_position = bone.global_position + direction * bone.get_bone_length()

References​

• https://sean.cm/a/fabrik-algorithm-2d/

Cyclic Coordinate Descent Inverse Kinematic (CCDIK) é diferente das lógicas anteriores, pois nós não sabemos qual o estado final que desejamos para os ossos. A ideia é fazer diversas iterações até que chegue em um resultado aceitável.

Em outras palavras, CCDIK se trata da jornada e não do resultado final.

Cyclic Coordinate Descent​

Para cada osso temos que calcular a rotação para a ponta chegue mais perto do ponto desejado.

Dependendo da direção que você caminhar pela cadeia de ossos o movimento pode ser diferente. Nesse exemplo iremos fazer de tráz para frente (osso mais perto da ponta até osso mais longe da ponta).

E com isto fizemos a primeira iteração. Vamos começar a segunda iteração.

Cada iteração se aproximando mais do ponto desejado.

O único cálculo que precisamos fazer toda iteração é o ângulo da ponta até o alvo.

Negative Scale​

Recomendo ler no Two Bone sobre escala negativa. O que importa é que o mesmo se aplica neste caso, se uma das escalas for negativa, precisamos rotacionar na direção oposta.

Conclusion​

Em GDScript o código seria algo como:

for bone in chain:
    var angle_to_target: float = bone.global_position.angle_to_point(target.global_position)
    var angle_to_tip: float = bone.global_position.angle_to_point(tip.global_position)
    var angle_diff: float = angle_to_target - angle_to_tip
    
    # Escala negativa ou não.
    if bone.global_scale.sign().x == bone.global_scale.sign().y:
        bone.rotate(angle_diff)
    else:
        bone.rotate(-angle_diff)

References​

• https://www.ryanjuckett.com/cyclic-coordinate-descent-in-2d/

Faz um mês desde que escrevi sobre inverse kinematic look at. Talvez eu esteja enrolando para falar desta pois foi por ela que eu comecei a ver inverse kinematics... e sofri muito.

Two bone inverse kinematic! Dado que queremos a mão em uma devida posição, como os dois ossos responsáveis pelo braço devem se encontrar?

Note que não vamos ditar onde a mão vai estar, porém onde desejamos que ela estivesse. Isso é importante pois o calculo muda dependendo se a mão alcança ou não a posição desejada.

Two Bone​

O que você faz quando tenta alcançar algo longe de você?
Estica o máximo possível.

O que você faz quando tenta alcançar algo perto de você?
Curva o braço de forma que sua mão acabe na posição desejada.

Primeira coisa a se fazer é descobrir se está fora ou dentro do alcance 🤣.
Em outras palavras, a base do braço até o ponto desejado é maior ou menor que o braço todo?

Podemos descobrir a distância entre dois pontos se calcularmos o vetor entre eles e depois usarmos a clássica formúla para distância. Resumidamente:

• P2-P1
• √(x²+y²)

Sabendo disso podemos calcular as seguintes distâncias:

• A -> T
  • Distância até posição desejada
• A -> B
  • Tamanho do osso 1
• B -> C
  • Tamanho do osso 2

Agora podemos verificar justamente se está dentro ou fora do alcance!

Distância até posição desejada > (Tamanho do osso 1 + Tamanho do osso 2)

Out of Range​

Acontece que estender o braço em uma direção é apenas tornar o ângulo global dos ossos equivalentes ao da direção.

Já vimos em IK Look at como fazer um osso/vetor apontar para uma direção e isso é tudo que precisamos fazer aqui também.

• Apontar osso 1 para posição desejada
• Apontar osso 2 para posição desejada

Fim.

In range - Triangle​

Espero que este desenho já deixe claro como utilizaremos trigonometria com braços curvados.

Neste caso o ponto onde desejamos posicionar a mão está dentro do alcance dela, então irá acabar sendo exatamente a posição da mão (utilizaremos C mas poderia ser T).

Já calculamos os lados do triângulo, então agora vamos focar no seus ângulos internos (utilizaremos α β γ).

Sabendo todos os lados do triângulo podemos utilizar leis do cossenos para descobrir cada ângulo interno:

a² = b² + c² - 2bc*cos(α)
b² = a² + c² - 2ac*cos(β)
c² = a² + b² - 2ab*cos(γ)

Sabendo os lados e sabendo os ângulos internos nós conseguimos dizer como o braço precisa estar dobrado. O problema é que ele ainda pode estar dessa forma de diversas maneiras 🤣:

In range - Two Angles​

Existem dois ângulos que estamos buscando descobrir, rotacionando eles conseguiremos os ossos exatamente onde queremos:

Nessa imagem o braço estava esticado em direção ao eixo X, rotacionamos osso 1 por θ1 e osso 2 por θ2 para obter o braço no formato que queriamos.

Como podemos obter θ1?

Se você estava pensando "é só calcular o ângulo do eixo X até o osso 2 que você consegue o θ1", deixe-me lembra-lo que o braço vai começar de forma desconhecida.

Mesmo se estivesse esticado no eixo X, o osso 2 não vai estar na posição desejada ainda!

Mas sabe o que podemos fazer? Calcular o ângulo do eixo X até o ponto desejado (T).

Sabe o porque eu chamei ele de α'? Porque ele está relacionado com α!

Acontece que para obter o ângulo desejado, podemos rotacionar até a direção de T e depois remover a rotação interna do triângulo (α).

Não precisamos literalmente rotacionar, podemos calcular o ângulo e depois rotacionar: α' - α

Como podemos obter θ2?

Felizmente o osso 2 não rotacionado faz um ângulo de 180º com o osso 1.

Se rotacionarmos por 180º e diminuirmos pelo ângulo interno (β), obtemos justamente o ângulo que queriamos.

Novamente não precisamos literalmente rotacionar, podemos calcular o ângulo e depois rotacionar: 180º - β

No final chegamos aos ângulos graças aos ângulos internos do triângulo:

θ1 = α' - α
θ2 = 180º - β

In range - Bend Direction​

Mas se nós quisermos que o braço fique curvado para o outro lado?

Acontece que mesmo curvando para o outro lado, os valores internos do triângulo não se alteram.

Então todo o calculo se mantém até a última etapa, onde precisamos mudar o sinal da rotação interna.

θ1 = α' + α
θ2 = 180º + β

In range - Negative Scale​

Quando você escala qualquer um dos eixos por negativo, você também está dizendo que a direção para qual ele está rotacionando trocou:

Se agora escalarmos o eixo Y negativamente, a rotação irá voltar a ser igual o início.
Cada vez que você escala um eixo negativamente, você troca a direção das rotações.

Como isso afeta nossos calculos?

Apenas o ângulo que utiliza o eixo X como referência é afetado (pois o eixo X nunca é escalado negativamente)

Agora não queremos reduzir do ângulo α', mas sim acrescentar:

θ1 = α' + α

Mas se quisermos o osso curvado para a outra direção? É, então queremos novamente reduzir...

θ1 = α' - α

Err... basicamente estamos bricando de jogo do troca, dependendo da situação queremos rotacionar para diferentes direções.

Conclusion​

Este é o meu código escrito em GDScript (linguagem do Godot):

var flip_bend: bool = false
var target_distance: float = bone_one.global_position.distance_to(target.global_position)
var bone_one_length: float = bone_one.get_bone_length()
var bone_two_length: float = bone_two.get_bone_length()
var angle_to_x_axis: float = (target.global_position - bone_one.global_position).angle()

# Fora do alcance.
if target_distance > bone_one_length + bone_two_length:
  bone_one.global_rotation = angle_to_x_axis
  return

# Lei dos cossenos.
var angle_0: float = acos(
  (target_distance ** 2 + bone_one_length ** 2 - bone_two_length ** 2) / (2 * target_distance * bone_one_length)
)

var angle_1: float = acos(
  (bone_two_length ** 2 + bone_one_length ** 2 - target_distance ** 2) / (2 * bone_two_length * bone_one_length)
)

# Direção da curva do braço.
if flip_bend:
  angle_0 = -angle_0
  angle_1 = -angle_1

# Escala negativa ou não.
if bone_one.global_scale.sign().x == bone_one.global_scale.sign().y:
  bone_one.global_rotation = angle_to_x_axis - angle_0
else:
  bone_one.global_rotation = angle_to_x_axis + angle_0

bone_two.rotation = PI + angle_1

Extra - Negative Scale in Godot​

Este é extra pois depende muito da ferramenta que está utilizando, no meu caso Godot em 2D.

Godot representa translação, rotação e escala utilizando matriz. Entenda mais sobre transforms na documentação do Godot, aqui iremos direto ao assunto.

Matriz identidade representa um transform sem alteração nenhuma (translação, rotação e escala)

A desvantagem de utilizar uma matriz para armazenar todas essas informações é que algumas são impossíveis de extrarir corretamente. Olhe a matriz após escalar X por -1:

Agora olhe a matriz após rotacionar por 180º e escalar Y por -1:

Exatamente a mesma matriz... Se você der essa matriz para Godot, ele vai assumir que você fez a segunda opção (rotacionou e escalou Y por -1).

Como isso afeta nossa Inverse Kinematic?

Não afeta se você utilizou funções que já levam esse problema em conta, porém se vc operou diretamente sobre os transforms... Você talvez note alguns problemas.

References

• https://www.alanzucconi.com/2018/05/02/ik-2d-1/
• https://docs.godotengine.org/en/stable/tutorials/math/matrices_and_transforms.html

Não bastava meu sofrimento com utilização de bibliotecas, agora tive mais dor de cabeça por elas virem do package manager (apt).

Meu sofrimento foi enquanto tentava usar a biblioteca GTK em C.

Installing​

Duas opções:

• Instalar o pacote pronto da minha distribuição
• Baixar e compilar o código fonte

Como eu ainda tenho algum amor por mim mesmo, fui pela primeira opção:

$ sudo apt install libgtk-4-1 libgtk-4-dev

E podemos descobrir os arquivos que estes pacotes trouxeram com:

$ dpkg -L libgtk-4-1 libgtk-4-dev

O que nos mostra que o pacote responsável por desenvolvimento (libgtk-4-dev) trouxe muitos headers files e uma biblioteca compartilhada (/usr/lib/x86_64-linux-gnu/libgtk-4.so).

Code​

Qual será o grande código utilizado durante este post???

#include <gtk/gtk.h>

int main() { return 0; }

Exatamente! Estou cagando para o código, apenas quero acessar a biblioteca!

¿Donde esta la biblioteca?

Includes​

Talvez seja meio óbvio mas o código não vai ser executado com um simples

$ clang -o my_project main.c

Pois o compilador não irá encontrar a biblioteca.

$ clang -o my_project main.c
main.c:1:10: fatal error: 'gtk/gtk.h' file not found
#include <gtk/gtk.h>
         ^~~~~~~~~~~
1 error generated.

Existe duas maneiras de adicionar headers ao seu código:

• #include "biblioteca.h"
  • Dentro do seu diretório atual, busque o arquivo biblioteca.h.
• #include <biblioteca.h>
  • Dentro dos diretório padrões, busque o arquivo biblioteca.h.

Qual o diretório padrão para bibliotecas? /usr/include

Lembra quando vimos a lista dos arquivos que o pacote trouxe? Muitos headers foram justamente para o diretório padrão.

...
/usr/include/gtk-4.0/gtk/gtkshortcutmanager.h
/usr/include/gtk-4.0/gtk/gtkshortcutsgroup.h
/usr/include/gtk-4.0/gtk/gtkshortcutssection.h
/usr/include/gtk-4.0/gtk/gtkshortcutsshortcut.h
/usr/include/gtk-4.0/gtk/gtkshortcutswindow.h
...

Perfeito então, podemos alterar nosso código para usar #include <gtk-4.0/gtk/gtk.h>

#include <gtk-4.0/gtk/gtk.h>

int main() { return 0; }

E vai dar tudo cert.... ei...

$ clang -o my_project main.c
In file included from main.c:1:
/usr/include/gtk-4.0/gtk/gtk.h:29:10: fatal error: 'gtk/css/gtkcss.h' file not found
#include <gtk/css/gtkcss.h>
         ^~~~~~~~~~~~~~~~~~
1 error generated.

Nope!

Packages​

Está é a organização do desenvolvedor da biblioteca:

project/
├── gdk
├── gsk
├── gtk
└── unix-print

Para eles realmente é #include <gtk/gtk.h> por isso outras partes do código deles utiliza assim!
E não é como se eles fossem ficar alterando em todos os arquivos do projeto para referênciar o caminho com versão mais recente do projeto.

Queremos é dizer ao compilador os diretórios a procurar os arquivos...
Pera, nós já fizemos isso no post anterior, usando a flag -I.

#include <gtk/gtk.h>

int main() { return 0; }

Agora basta executar utilizando a flag e sucess... ei...

$ clang -o my_project main.c -I/usr/include/gtk-4.0
In file included from main.c:1:
In file included from /usr/include/gtk-4.0/gtk/gtk.h:29:
/usr/include/gtk-4.0/gtk/css/gtkcss.h:29:10: fatal error: 'glib.h' file not found
#include <glib.h>
         ^~~~~~~~
1 error generated.

Você esqueceu que está biblioteca pode usar outras bibliotecas e precisamos adicionar o diretório delas também!

Dependecies​

Existe um programa justamente para ajudar a descobrir as depêndencias de um módulo.

$ pkg-config --cflags gtk4
-I/usr/include/gtk-4.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu -I/usr/include/graphene-1.0 -I/usr/lib/x86_64-linux-gnu/graphene-1.0/include -mfpmath=sse -msse -msse2 -pthread

$ pkg-config --libs gtk4
-lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0

Mas como se descobre qual o nome do módulo da minha biblioteca? Não sei, se você souber, me conte!

Graças a este programa podemos gerar facilmente as flags e finalmente executar o código!

$ clang `pkg-config --cflags gtk4` -o my_project main.c `pkg-config --libs gtk4`

Language Server​

Sabe aquela ferramenta responsável por completar o código, avisar de errors, te levar à definições...
Bem, ela está reclamando e não queremos deixar ela assim né?.

#include <gtk/gtk.h> // 'gtk/gtk.h' file not found

int main() { return 0; }

Estamos passando diversas informações para nosso compilador (clang) sobre diretórios para utilizar mas não estamos passando nada para o language server (clangd). Podemos fazer um teste rápido para ver o que clangd acha do nosso arquivo com:

$ clangd --check=main.c
...
E[01:35:13.895] [pp_file_not_found] Line 1: 'gtk/gtk.h' file not found
...

Project Dependencies​

Poderiamos pesquisar e descobrir os argumentos a se passar ao clangd mas isso é algo que varia de projeto a projeto e última coisa que queremos é ficar configurando no Visual Studio os argumentos para cada projeto.

Por isso que clangd por padrão sempre procura configurações do projeto em certos arquivos do projeto como compile_commands.json! Poderiamos escrever este arquivo na mão... mas não queremos então vamos utilizar um programinha amigo chamado bear!

Ele recebe o comando que você está utilizando para criar o executável e cria o compile_commands.json:

$ sudo apt install bear
$ bear -- clang `pkg-config --cflags gtk4` -o my_project main.c `pkg-config --libs gtk4`

Pronto, conseguimos o arquivo de configuração para o clangd.

my_project/
├── compile_commands.json
├── main.c
└── my_project

Basta dar um tempo (ou reniciar o editor de texto) e seu language server deve perceber que está tudo certo!

Fim!
Código funciona!
Language server funciona!
Você está pronto para desenvolver com GTK!
Não se sente uma nova pessoa com todo esse conhecimento?

Bem, você não é a primeira pessoa a achar tudo isso desnecessariamente complicado para começar a programar... Outras pessoas criaram ferramentas para ajudar nisso!

Então continue lendo se quiser jogar tudo que viu até aqui no lixo e descobrir uma maneira mais fácil!

Meson!​

GTK adora falar do Meson e como já estou sofrendo mesmo... Por que não parar pra ver?
Instalando!

$ sudo apt install meson ninja-build

Claro que se vamos testar outra ferramenta, precisamos testar do zero! Apenas com o nosso querido arquivo main.c:

my_project/
└── main.c

Setuping​

$ meson init

Isso cria o arquivo de configuração chamado meson.build, nele tem diversas informações mais sofisticadas sobre o projeto:

project('my_project', 'c',
  version : '0.1',
  default_options : ['warning_level=3'])

executable('my_project',
           'main.c',
           install : true)

Viu?
Ele não é apenas "estou rodando um código".
Ele é "estou criando um ⭐projeto⭐".

Como ele é um projeto sério, ele vai guardar todas as informações dele em um pasta separada para não sujar o seu projeto ❤️!

Então diga para ele onde botar os arquivos dele (eu escolhi builddir):

$ meson setup builddir

Seu projeto deve acabar com a estrutura:

my_project/
├── builddir/
├── main.c
└── meson.build

Project Dependencies​

Sim! Em toda ferramenta é necessário que você a biblioteca que quer usar!
Você não quer que ela ande por todos os diretórios do seu computador procurando a sua biblioteca, né?
Imagina se pega a errada por acidente!

Fazemos isso pelo meson.build!

project('my_project', 'c',
  version : '0.1',
  default_options : ['warning_level=3'])

executable('my_project',
           'main.c',
           install : true,
           dependencies: dependency('gtk4'))

executable('my_project',
           'main.c',
           install : true,
           dependencies: [dependency('gtk4')])

Compiling​

Pronto! Você está pronto para ter seu projeto compilado sem erro! _{Talvez warnings coff coff...}

Entre no diretório de configuração do Meson (no meu caso builddir) e execute o comando de compilação:

$ cd builddir
$ meson compile

$ meson compile -C builddir

"clangd está reclamando novamente de 'gtk/gtk.h' file not found!"
Não se desespere pois se você olhar os arquivos criados após compilação, um deles é bem útil.

my_project/
├── builddir/
│   ├── ...
│   ├── compile_commands.json
│   └── my_project
├── main.c
└── meson.build

Olha lá arquivo que o clangd quer!
E o seu executável mas isso era de se esperar...

Copie ele para a raiz do seu projeto e pronto, seu clangd deve parar de chorar erro!

my_project/
├── builddir/
│   ├── ...
│   ├── compile_commands.json
│   └── my_project
├── compile_commands.json
├── main.c
└── meson.build

Conclusion​

Meson possui uma etapa de configuração, mas tirando isso os comandos depois ficam bem mais sensatos!

Compilando com clang e atualizando compile_commands.json:

$ clang `pkg-config --cflags gtk4` -o my_project main.c `pkg-config --libs gtk4`
$ bear -- clang `pkg-config --cflags gtk4` -o my_project main.c `pkg-config --libs gtk4`

Compilando com meson e atualizando compile_commands.json:

$ meson compile
$ cp compile_commands.json ../compile_commands.json

Se eu descobrir uma maneira de após compilação já copiar o arquivo compile_commands.json, tudo vai ficar perfeito!

References​

• https://docs.gtk.org/gtk4/compiling.html
• https://linuxcommand.org/lc3_lts0040.php
• https://github.com/rizsotto/Bear
• https://mesonbuild.com/Tutorial.html

• Durante a faculdade eu aprendi C

  • Abri Visual Studio
  • Escrevi código em C
  • Executei

• Recentemente eu usei C++ no projeto Godot

  • Segui instrução do Godot para configurar o VSCode
  • Escrevi código em C++
  • Executei

Em ambos os casos eu nunca aprendi direito sobre bibliotecas... Notei claramente quando segui as instruções de projeto para Build from Source e não sabia mais o que fazer com os arquivos .a e .so gerados.

Eu sabia que poderia compilar C/C++ com GCC ou Clang, mas meu conhecimento se resumia a compilar projetos 100% meus.

gcc main.c -o main

Bem, vamos entender cada um dois formatos primeiro.

.a (archive)​

Se trata de uma biblioteca estática (static library), ou seja, podemos ver como um conjunto de funções/variáveis que seram anexadas ao seu executável durante a etapa de compilação (na etapa do linker).

Ótimo quando você quer que seu programa tenha toda a lógica.

.so (shared object)​

Se trata de uma biblioteca compartilhada (shared library), ou seja, podemos ver como um executável que será utilizado por qualquer programa que precise dele (ainda é preciso avisar ao linker da existencia da biblioteca).

Ótimo pois ocupa menos espaço do computador da pessoa com a mesma lógica.

GCC 4 Steps​

Eu já mencionei linker duas vezes, para entender o que ele é precisamos olhar para cada etapa do GCC.

Um resumo seria:

• Preprocessor
  • Responsável por fazer pré processamentos, o mais popular é a substituição de #include pelo código dentro dos headers (.h).
  • A saída dessa etapa é conhecida como translation unit (ainda é código C).
• Compiler
  • Responsável por converter o código C para código assembly.
• Assembler
  • Responsável por converter o código assembly para um object code, ele é formado de código de máquina (código especifico para rodar naquela máquina) e "referências" a serem encontradas.
    • Por exemplo, você pode referênciar a função void do_it() mas ela não estar neste arquivo .c.
• Linker
  • Responsável por encontrar as referências de um arquivo e linkar elas, a saída é justamente o executável final.

Project from Zero​

Começamos com uma estrutura bem vazia de projeto:

project/
└── src/
    ├── main.c
    └── ...

Apens possuimos código nosso, então tudo que precisamos fazer para criar o executável é

gcc src/main.c -o main

Algum momento do nosso projeto decidimos usar bibliotecas de terceiro e não queremos misturar ela com o nosso código então resolvemos sempre separar os arquivos dela em outros diretórios.

O primeiro tipo de arquivo que bibliotecas trazem junto são os headers, utilizados justamente para o compilador conseguir determinar o que exatamente tem que buscar nas bibliotecas.

project/
├── include/
│   └── header.h
└── src/
    ├── main.c
    └── ...

Podemos adicionar um diretório onde se buscar headers com o argumento -I seguido pelo diretório (não é separado por espaço):

gcc src/main.c -o main -Iinclude

Agora podemos adicionar #include <header.h> sem o compilador reclamar que header.h não foi encontrado.

Se tentarmos chamar uma função que está no header.h ainda teremos erro pois não temos a função, apenas a assinatura dela. Nós precisamos do código da função, que pode estar em um .so ou .a.

.a​

Novamente não vamos querer misturar este arquivo com os do nosso projeto, então vamos deixar a biblioteca na pasta lib.

project/
├── include/
│   └── header.h
├── lib/
│   └── libname.a
└── src/
    ├── main.c
    └── ...

Podemos passar ao compilador diretório onde as nossas bibliotecas se encontram com o argumento -L seguido pelo diretório (não é separado por espaço):

gcc src/main.c -o main -Iinclude -Llib

Precisamos especificar as que desajamos usar e isso é feito com o argumento -l seguido pelo nome base da biblitoeca (não é separado por espaço):

gcc src/main.c -o main -Iinclude -Llib -lname

.so​

Segue basicamente a mesma lógica do .a, deixar a biblioteca no diretório lib.

project/
├── include/
│   └── header.h
├── lib/
│   └── libname.so
└── src/
    ├── main.c
    └── ...

Passar ao compilador diretório onde as nossas bibliotecas se encontram com o argumento -L seguido pelo diretório (não é separado por espaço):

gcc src/main.c -o main -Iinclude -Llib

No caso de bibliotecas compartilhadas este diretório pode possuir centenas de bibliotecas, então faz sentido você ter que especificar as que você quer usar. Novamente usamos o argumento -l seguido pelo nome base da biblitoeca (não é separado por espaço):

gcc src/main.c -o main -Iinclude -Llib -lname

Durante a execução do código o sistema operacional vai buscar a biblioteca em lugares predefinidos (linux busca em lugares como /usr/lib).

Mas se nossa biblioteca não for estar em um destes lugares predefinidos? Ainda é possível adicionar lugares onde se buscar durante a execução.

Podemos passar argumentos ao linker com -Wl seguido pelos argumentos que ele deve receber, no caso -Rlib (argumentos separados por virgula):

gcc src/main.c -o main -Iinclude -Llib -lname -Wl,-Rlib

Nosso executável agora vai sempre tentar buscar a biblioteca na pasta lib que estiver no mesmo diretório que ele.

References​

• https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Design
• https://en.wikipedia.org/wiki/Preprocessor
• https://en.wikipedia.org/wiki/Linker_(computing)
• https://stackoverflow.com/questions/25160245/clang-linking-with-a-so-file
• https://stackoverflow.com/questions/31176747/how-to-use-a-library-with-headers-and-so-files
• https://stackoverflow.com/questions/480764/linux-error-while-loading-shared-libraries-cannot-open-shared-object-file-no-s
• https://www.youtube.com/watch?v=or1dAmUO8k0
• https://www.youtube.com/watch?v=pLy69V2F_8M
• https://www.youtube.com/watch?v=Wt4dxDNmDA8
• https://tree.nathanfriend.io/

Dado que já refleti sobre forward kinematics, está na hora de falar sobre inverse kinematics (por mais que eu esteja com preguiça de fazer isso).

Vamos começar por algo que eu até me questiono se seria inverse kinematic: Look at.

Ser capaz de fazer uma mão apontar para uma posição ou a cabeça olhar para uma direção.

Look At​

Lembrando que articulações sempre possuem as suas informações locais e que as informações globais são facilmente calculáveis, nossa tarefa é descobrir como queremos alterar qualquer uma delas para alcançar nosso objetivo.

No caso, nosso objetivo é fazer com que o vetor da articulação aponte para X.

Na primeira parte da imagem, temos o vetor já apontando em direção do X.
Na segunda parte da imagem, o X se encontra a 90º graus do vetor.

Olhando a imagem nós conseguimos saber que para continuar apontando para X temos que rotacionar por 90º, mas como conseguir este ângulo matemáticamente?

Talvez você já tenha notado mas vamos fazer isto usando trigonometria (se prepare que IK é triângulo para tudo que é lado).

0º ~ 90º​

Um bom começo é sabermos calcular o ângulo para uma posição, sem se preocupar com detalhes como global e local.

Funções trigonométricas são o segredo para trabalhar com triângulos (seno, cosseno e tangente) e neste caso tangente é justamente o que procuramos.

tan θ = cateto oposto / cateto adjacente

Agora nós temos o valor da tangente para qualquer posição (x,y).

• (1,1)
  • tan(θ) = 1
• (3,2)
  • tan(θ) = 2/3
• (4,7)
  • tan(θ) = 7/4

Se você bem se lembra, existem funções trigonométricas inversas que são justamente quem vão nos dar o ângulo que chega ao valor que temos.

• (1,1)
  • tan(θ) = 1
    • atan(1) = θ
      • 45
• (3,2)
  • tan(θ) = 2/3
    • atan(2/3) = θ
      • 33.690067526
• (4,7)
  • tan(θ) = 7/4
    • atan(7/4) = θ
      • 60.255118703

0º ~ 360º​

Um problema que cedo ou tarde iriamos notar é que dos valores da tangete não é possível definir qual quadrante se trata.

atan(1) pode ser 45º ou 225º
atan(-1) pode ser 135º ou 315º

Única maneira de saber exatamente o quadrante é sabendo o sinal dos eixos.

• (positivo,positivo)
  • atan(θ) + 0º
• (negativo,positivo)
  • atan(θ) + 90º
• (negativo,negativo)
  • atan(θ) + 180º
• (positivo,negativo)
  • atan(θ) + 270º

É por isso que em muitas bibliotecas matemáticas existe a função atan(v) e a função atan2(x, y).
A segunda utiliza os eixos para saber o real ângulo.

Rotating​

Agora que sabemos como obter o ângulo do ponto (0,0) até uma posição qualquer, podemos finalmente rotacionar a articulação.

O próximo problema é que não estamos falando de rotacionar a partir do ponto (0,0) mas sim da posição da articulação.

θ1: Rotação global, usando ponto (0,0) como referência.
θ2: Rotação local, usando a posição da articulação como referência.

Para solucionar isto podemos calcular a posição do ponto em relação a articulação:

posição do ponto relativa à articulação =
        posição global do ponto - posição global da articulação

Exemplo:

Posição global do ponto: (35, 10)
Posição global da articulação: (25, 10)
Posição do ponto relativa à articulação: (10, 0)
Ângulo: 0º

Se movermos o ponto:

Posição global do ponto: (50, 30)
Posição global da articulação: (25, 10)
Posição do ponto relativa à articulação: (25, 20)
Ângulo: 38º

Pronto, agora sabemos qual deveria ser a rotação daquela articulação!

Conclusion​

Você provavelmente não terá que pensar em nada disso pois muitas game engines já possuem métodos para lidar com isto, por exemplo em Godot podemos encontrar algo como:

Node2D.get_angle_to(global_position)

Essa função retorna o ângulo global que falta para estar em direção ao ponto global.

References​

• https://www.youtube.com/watch?v=8Eur16foTMw
• https://cplusplus.com/reference/cmath/atan2/

Ao começar a estudar Rust percebi o quão a relação deste dois são próxima, porém primeiro precisamos rever unions e enums.

Union​

Se trata de utilizar o mesmo espaço de memória para armazenar um entre diversos tipos.

union Content {
    int i;
    float f;
    char c;
};

union Content content;

Nesse exemplo eu declarei um union que pode conter um dos seguintes valores: int, float, char.

Então eu posso escrever qualquer um dos tipos nele:

content.i = 10;
content.f = 5.0;
content.c = 'a';

O valor final de content vai ser a pois foi o último valor que botamos.

Porém a parte importante é justamente o fato de usarmos o mesmo espaço de memória para armazenar qualquer um destes tipos.

content.c = 'a';

printf("%c\n", content.c); // print "a"
printf("%c\n", content.i); // print "a"

Quando você declara uma union, o tamanho dela é definido pelo maior tamanho entre os tipos que ela precisa conseguir armazenar.

No nosso caso o melhor tamanho seria 4 bytes, pois com ele você consegue armazenar o char também.

Nada impede de armazenarmos um char e tentarmos ler aquele espaço da memória como um int.

content.c = 'a';

printf("%c\n", content.c); // print "a"
printf("%c\n", content.i); // print "a"

// O character 'a' é nada mais que o número 97 na memória.
printf("%i\n", content.c); // print "97"
printf("%i\n", content.i); // print "97"

Resta a nós utilizar corretamente o valor daquele espaço de memória.

Afinal não queremos armazenar um char na union e mais tarde no código tentar utilizar como um int, né?

content.c = 'a';

// ...

printf("%i\n", content.i + 5); // print "102"

Não só isso como quando você armazena um valor naquele espaço de memória, ele apenas escreve no espaço que ele usaria.

content.c = 'a';

printf("%i\n", content.c); // print "97"
printf("%i\n", content.i); // print "97"

content.i = -10;
content.c = 'a';

printf("%i\n", content.c); // print "97"
printf("%i\n", content.i); // print "-159"

O que aconteceu aqui?

• Início do programa os 4 bytes de content estão com zero
• Content recebeu no primeiro byte o valor 97 (pois a == 97)
• Printamos utilizando content.c
  • Isto nos faz utilizar um byte
• Printamos utilizando content.i
  • Isto nos faz utilizar 4 bytes
• Content recebeu encheu os 4 bytes para formar o valor de -10
• Content recebeu no primeiro byte o valor 97
• Printamos utilizando content.c
  • Isto nos faz utilizar um byte (primeiro byte está com o valor de 97)
• Printamos utilizando content.i
  • Isto nos faz utilizar 4 bytes (primeiro byte + os outros 3 bytes que não foram limpos)

Podemos confirmar isto settando para zero antes de preenchermos.

content.c = 'a';

printf("%i\n", content.c); // print "97"
printf("%i\n", content.i); // print "97"

content.i = -10;
content.i = 0;
content.c = 'a';

printf("%i\n", content.c); // print "97"
printf("%i\n", content.i); // print "97"

Como podemos ver, é essencial termos uma maneira de identificar qual é o tipo atual na union.

Enum​

Se trata de ligar um identificador a um número único dentro de um agrupamento.

enum Type {
    Integer,
    Floating,
    Character,
};

enum Type type;

Neste caso está ligando:

Isto poupa trabalho de criarmos manualmente uma variável para cada valor, por exemplo:

int Integer = 0;
int Floating = 1;
int Character = 2;

Além de deixarmos claro o tipo de variável durante a criação dela (como um valor dentro daquele agrupamento).

enum Type type = Integer;

printf("%i\n", type); // print "0"

Enfim, a essa altura você pode já ter notado a importância de enum para unions.

Com eles podemos criar ligar um identificador a um tipo, como se fosse uma tag para aquele union.

union content {
    int i;
    float f;
    char c;
} content;

enum Types {
    Integer,
    Floating,
    Character,
} type;

content.f = 5.0;
type = Floating;

Note que precisamos atualizar type sempre que mudarmos o tipo de content, porém ganhamos a capacidade de tratar corretamente a union.

if (type == Floating) {
    printf("%f\n", content.f);
} else if (type == Character) {
    printf("%c\n", content.c);
} else {
    printf("%i\n", content.i);
}

Este tipo de estrutura é tão comum que tem o nome de Tagged Union.

Rust Enum​

Acredito que o enum do Rust seja nada mais que um tagged union.

#[derive(Debug)]
enum Type {
    Integer,
    Floating,
    Character,
}

println!("{:#?}", Type::Integer);

Em outras lugares enum ligaria apenas identificadores a números, porém em Rust você pode armazenar estrutura/tipos juntos aos enums.

#[derive(Debug)]
enum Type {
    Integer(i32),
    Floating(f32),
    Character(char),
}

let content: Type = Type::Floating(5.0);

println!("{:#?}", content);

Isso nos da uma estrutura só que possue a capacidade de fazer o mesmo que tagged union e com menos chance do desenvolvedor cometer um erro.

Por exemplo, não precisamos mais atualizar o tipo armazenado na variável toda vez que alteramos:

// C
content.f = 5.0;
type = Floating;

// Rust
let content: Type = Type::Floating(5.0);

Rust é linguagem que preza bastante segurança, então faria sentido tratar como se fosse uma única estrutura para evitar os problemas de union (embora Rust tenha o tipo union).

Comparison​

C​

union content {
    int i;
    float f;
    char c;
} content;

enum Types {
    Integer,
    Floating,
    Character,
} type;

content.f = 5.0;
type = Floating;

if (type == Floating) {
    // Fazer algo com float
} else if (type == Character) {
    // Fazer algo com char
} else {
    // Fazer algo com int
}

Rust​

#[derive(Debug)]
enum Type {
    Integer(i32),
    Floating(f32),
    Character(char),
}

let content: Type = Type::Floating(5.0);

match content {
    Type::Floating(f) => // Fazer algo com float
    Type::Character(c) => // Fazer algo com char
    Type::Integer(i) => // Fazer algo com int
}

Esses últimos meses eu tenho gastado um grande tempo (mais do que gostaria) vendo o código de inverse kinematics 2D do Godot.

E eu preciso passar a limpo o conhecimento básico que eu possuo, para melhor garantir que não estou cagando tudo no código deles.

Robotic Arms​

É difícil falar de forward kinematics (FK) e inverse kinematics (IK) sem entender braços robóticos, pois foi o primeiro uso destas lógicas.

Para entender melhor um braço, vamos dividi-lo em 4 partes:

• Base
• Limbs (membros)
• Joints (articulações)
• End effector (mão do braço)

• Base, providência estabilidade para o braço
• Limbs, separa as partes entre si
• Joints, são responsáveis por se rotacionar
• End effector, interage com o objeto

A parte que mais damos atenção quando falamos de FK e IK são joints, pois elas providência a lógica de movimentação do braço.

FK & IK​

Se tivessemos que resumir cada assunto, seria algo por parte de:

• Forward kinematics
  • Foca em descobrir o estado da mão, dado que o braço está em certo estado.
• Inverse kinematics
  • Foca em descobrir o estado do braço, dado que deseja a mão em certa estado.

FK​

IK​

Forward Kinematic​

Minha kinematic favorita por ser a mais simples de calcular, onde tudo se resume a um grande somatório.

Adicionei setas nessa imagem para represetarem as rotações locais das joints (articulações), essa rotação se refere ao quanto aquela joint (articulação) se rotacionou.

Agora adicionei uma circuferência mostrando os ângulos clássicos e podemos usar eles como referência para a rotação global, essa rotação é sempre relacionada à direita (eixo X).

Para começar nosso experimento, podemos rotacionar o end effector (mão) por 90 graus e ver o que podemos concluir.

• End effector
  • Rotação local: 90º
  • Rotação global: 90º
• Joint 2
  • Rotação local: 0º
  • Rotação global: 0º
• Joint 1
  • Rotação local: 0º
  • Rotação global: 0º

Podemos ver que rotacionar um ponto localmente não afeta os anteriores (os pais). Também importante notar que rotação local sempre irá afetar a rotação global daquele ponto.

Mas se tivessemos rotacionado a joint 2 por 90 graus?

• End effector
  • Rotação local: 0º
  • Rotação global: 90º
• Joint 2
  • Rotação local: 90º
  • Rotação global: 90º
• Joint 1
  • Rotação local: 0º
  • Rotação global: 0º

Notamos que rotacionar localmente um ponto, afeta a rotação global dos pontos seguintes pela mesma quantidade.

Se rotacionarmos localmente o end effector por -90 graus?

• End effector
  • Rotação local: -90º
  • Rotação global: 0º
• Joint 2
  • Rotação local: 90º
  • Rotação global: 90º
• Joint 1
  • Rotação local: 0º
  • Rotação global: 0º

Nós conseguimos voltar a rotação global do end effector para 0º pois rotacionar localmente sempre afeta o global do mesmo ponto.

Nesse pequeno experimento já podemos começar a notar uma formula bem simples:
Rotação global = Rotação global do ponto anterior + Rotação local

Utilizando o end effector como referência:
Rotação global = 90º + (-90º) = 0º

O que aconteceria se rotacionarmos a joint 1 por 90 graus?

• End effector
  • Rotação local: -90º
  • Rotação global: 90º
• Joint 2
  • Rotação local: 90º
  • Rotação global: 180º
• Joint 1
  • Rotação local: 90º
  • Rotação global: 90º

Podemos ver que afetamos a rotação global de todos os pontos seguintes, aumentando eles por 90 graus.

Conclusion​

Lembra quando falei que forward kinematics "foca em descobrir o estado da mão, dado que o braço está em certo estado". É exatamente esse somatório que nos ajuda a resolver o problema.

Vamos supor que temos 5 pontos (ponto 1 é a base):

• Ponto 5
  • Rotação local: -90º
  • Rotação global: ?
• Ponto 4
  • Rotação local: 0º
  • Rotação global: ?
• Ponto 3
  • Rotação local: 180º
  • Rotação global: ?
• Ponto 2
  • Rotação local: 0º
  • Rotação global: ?
• Ponto 1
  • Rotação local: 90º
  • Rotação global: ?

E que nós queremos descobrir para onde cada ponto está apontando.

Se a gente começar da base, podemos ir calculando a rotação global de cada ponto usando a formula:
Rotação global = Rotação global do ponto anterior + Rotação local

Rotação global do ponto 1: 0º + 90º = 90º
Rotação global do ponto 2: 90º + 0º = 90º
Rotação global do ponto 3: 90º + 180º = 270º
Rotação global do ponto 4: 270º + 0º = 270º
Rotação global do ponto 5: 270º + -90º = 180º

• Ponto 5
  • Rotação local: -90º
  • Rotação global: 180º
• Ponto 4
  • Rotação local: 0º
  • Rotação global: 270º
• Ponto 3
  • Rotação local: 180º
  • Rotação global: 270º
• Ponto 2
  • Rotação local: 0º
  • Rotação global: 90º
• Ponto 1
  • Rotação local: 90º
  • Rotação global: 90º

References​

• Alan Zucconi Blog
• Miloš Černý Animation Video
• Forward Kinematics Wikipedia
• Robot Kinematics Wikipedia