This is the 3rd project in the Robotics Software Engineer Nanodegree Program by Udacity.

In this project, I learned several aspects of robotic software engineering with a focus on ROS:

1. Create a ROS package that launches a custom robot model in a custom Gazebo world
2. Utilize the ROS AMCL package and the Tele-Operation / Navigation Stack to localize the robot
3. Explore, add, and tune specific parameters corresponding to each package to achieve the best possible localization results

First, launch the simulation:

$ roslaunch my_robot world.launch

In a new terminal, launch the amcl launch file:

$ roslaunch my_robot amcl.launch

There are two options to control my robot while it localize itself here:

• Send navigation goal via RViz
• Send move command via teleop package.

Click the 2D Nav Goal button in the RViz toolbar, then click and drag on the map to send the goal to the robot. It will start moving and localize itself in the process.

Open another terminal and launch the teleop script:

$ rosrun teleop_twist_keyboard teleop_twist_keyboard.py

1. Basic Navigation Tuning Guide: ROS wiki
2. base_local_planner does not follow the global plan accurately: The Construct
3. Confusion about TF frames used #300: GitHub > googlecartographer/cartographer_ros

Onboard is an extensible framework for visual programming. Onboard allows you to create a node editor from the browser. You can define nodes and events that allow you to create instructions to process data in your editor.

Onboard is based on d3.js.

• No canvas.
• Based on d3.js.

• Connectors.
• Autopositioning.
• minimap.

• Export/Import JSON.
• Events.
• Node Connector.
• Pin protection.
• Control: Input
• Control: Label.
• Avoid cyclic connections.
• Demo website.

import { Editor, NodeComponent, Pin } from "./Onboard";
import * as Connector from "./Onboard/extensions/connectors.ext";

const root = "#root";

const Node1 = new NodeComponent({ title: "Node1" });
const Node2 = new NodeComponent({ title: "Node2" });
const Node3 = new NodeComponent({ title: "Node3" });

const editor = new Editor({
    name: "schema1",
    root,
    nodes: [Node1, Node2, Node3]
});

Node1.addInput(new Pin("out1", "Output 1"));

Node2.addInput(new Pin("in1", "Input 1"));
Node2.addInput(new Pin("in2", "Input 2"));
Node2.addOutput(new Pin("out1", "Output 1"));

Node3.addInput(new Pin("in1", "Input 1"));
Node3.addOutput(new Pin("out1", "Output 1"));
Node3.addOutput(new Pin("out2", "Output 2"));
Node3.addOutput(new Pin("out3", "Output 3"));

editor.install(Connector);

1. Clone
2. npm install
3. npm run start
4. Open http://localhost:1234

License

MIT

You are free to contribute to this project. 🙂

Fractal is a Go package that makes it easy to work with dynamic and nested data types, with encoding/decoding support.

• Nested data type
• Dot path support
• JSON encoding/decoding
• Simple template replacement
• Inplace update
• Common data type support: Struct, Map…

go get -u github.com/ddliu/fractal

Work with struct

data := myStruct {
    Key1: "Value1",
    Key2: anotherStruct {
        Key3: "Value3"
    }
}

// Create context
ctx := fractal.New(data)
println(ctx.String("Key2.Key3"))
// output: Value3

Work with json

ctx := fractal.FromJson([]byte(`{"key1": "value1", "key2": {"key3": "value3"}}`))
println(ctx.String("key2.key3"))

Or with JSON unmarshal

var ctx fractal.Context
json.Unmarshal([]byte(`{"key1": "value1", "key2": {"key3": "value3"}}`), &ctx)
println(ctx.String("key2.key3"))

Work with map

ctx := fractal.New(map[string]interface{
    "key1": "value1",
    "key2": "value2",
})

Update:

ctx.SetValue("key2.new_key", 3)

Simple template:

tpl := `Author: ${author.name}; License: ${license}; `

c := New(nil)
c.SetValue("author", map[string]string{
    "name":  "Dong",
    "email": "test@example.com",
})

c.SetValue("license", "MIT")

println(c.Tpl(tpl))

// output: Author: Dong; License: MIT; 

• a.b: Notation access
• a.b.1: Array index
• a.b.length(): Length of array or object

SQL query builder for NodeJS

This query builder is compatible with following Database Management Systems.

• MySQL via mysql/mysql2
• MariaDB via mariadb
• PostgreSQL via pg

You can install by run this command inside your project by using terminal.

npm i @skuyjs/query-builder

Type this following lines in your .js file and you can run it.

const Database = require('@skuyjs/query-builder');
const db = new Database({
  dialect: 'mysql',
  username: 'root',
  password: 'root',
  database: 'test',
});

console.log(db.getDialect());

It will give you mysql (your dialect) as output.

As dialect you choose, it have to installed first.

Example:

• npm install mysql for mysql
• npm install mysql2 for mysql2
• npm install mariadb for mariadb
• npm install pg for pg

Getting all data (select query) can do by use following lines.

...
db
  .table('users')
  .all()
  .then(console.log)
  .catch(console.log);

// prints all data in users table

Getting all data with specific column(s), see following example.

...
db
  .table('users')
  .get('fullname', 'email', 'password')
  .then(console.log)
  .catch(console.log);

// prints all data in users table, but
// only fullname, email, and password columns

Inserting a data can do by use following lines.

...
db
  .table('users')
  .insert([null, 'my fullname', 'example@email.top', 'mypass123'])
  .then(console.log)
  .catch(console.log);

// inserting data into users table
// prints insertion result

Inserting a data with specific column(s) can do by use following lines.

...
db
  .table('users')
  .insert({
    fullname: 'my fullname',
    email: 'example@email.top',
    password: 'mypass123'
  })
  .then(console.log)
  .catch(console.log);

// inserting data into users table
// prints insertion result

Updating all data(s) can do by use following lines.

db
  .table('users')
  .update({ fullname: 'aye' })
  .then(console.log)
  .catch(console.log);

// updating all data in users table
// prints update result

Updating data(s) with specific row(s) can do by use following lines.

db
  .table('users')
  .where({ id: 1 })
  .update({ fullname: 'aye' })
  .then(console.log)
  .catch(console.log);

// updating data(s) with 1 as id in users table
// prints update result

Deleting all datas can do by use following lines.

db
  .table('users')
  .del()
  .then(console.log)
  .catch(console.log);

// deleting all data in users table
// prints deletion result

Deleting data(s) with specific row(s) can do by use following lines.

db
  .table('users')
  .where({ id: 1 })
  .del()
  .then(console.log)
  .catch(console.log);

// deleting data(s) with 1 as id in users table
// prints deletion result

[EN]

This is a two person network chat application.

The application is made in ultra low level C++, the graphics library used is WXwidgets C++ and the communication part is handled by winsock2.

The network communication system uses a blocking socket and each user is able to send/retrieve data.

You must download the WXwidgets libraries and put the lib and included directories in the solution directory. Choose the LIBDebug or LIBRelease configuration to compile because the program only uses static libraries. Download Libraries: https://www.wxwidgets.org/downloads/ You can download the source code and compile the libraries yourself or download the precompiled .lib files.

At the moment, the application is still in the development, no release is available.

[FR]

Ceci est une application réseaux de chat à deux personnes.

L’application est programmée en C++ ultra bas niveau, la bibliothèque graphique utilisé est WXwidgets C++ et la partie communication est assurée par winsock2.

Le système de communication réseaux utilise un socket bloquant et chaque utilisateur est capable d’envoyer/récupérer des données.

Vous devez impérativement télécharger les bibliothèques WXwidgets et mettre les répertoires lib et inclue dans le répertoire de la solution. Choisissez les configuration LIBDebug ou LIBRelease pour compiler car le programme utilise des bibliothèques statiques. Télécharger les bibliothèques : https://www.wxwidgets.org/downloads/ Vous pouvez télécharger le code source et compiler les bibliothèques vous-même où télécharger les fichiers .lib précompilés.

Pour l’instant, l’application est encore en phase de développement, aucune release n’est disponible.

(non definitive / non deffinitif)

• CApp: main entry point of the application
• CMain: Management of the main window with events, message list and content display
• CSettings: Stores the application settings and manages a window for the user to enter them
• CContent: Stock the data of a message (text, username, date and time, files attached) and organize them in a panel.
• CImagePanel: Class allowing the display of an image in a panel

• CApp : point d’entrée principale de l’application
• CMain : Gestion de la fenêtre principale avec évènements, liste de message et affichage du contenu
• CSettings : Stock les paramètres de l’application et gère aussi une fenêtre pour que l’utilisateur puisse les saisir
• CContent : Stock les données d’un message (texte, nom d’utilisateur, date et heure, fichiers joints avec le message) et les organise dans un panneau.
• CImagePanel : Class permettant l’affichage d’une image sous forme de panneau

[EN]

This is a two person network chat application.

The application is made in ultra low level C++, the graphics library used is WXwidgets C++ and the communication part is handled by winsock2.

The network communication system uses a blocking socket and each user is able to send/retrieve data.

You must download the WXwidgets libraries and put the lib and included directories in the solution directory. Choose the LIBDebug or LIBRelease configuration to compile because the program only uses static libraries. Download Libraries: https://www.wxwidgets.org/downloads/ You can download the source code and compile the libraries yourself or download the precompiled .lib files.

At the moment, the application is still in the development, no release is available.

[FR]

Ceci est une application réseaux de chat à deux personnes.

L’application est programmée en C++ ultra bas niveau, la bibliothèque graphique utilisé est WXwidgets C++ et la partie communication est assurée par winsock2.

Le système de communication réseaux utilise un socket bloquant et chaque utilisateur est capable d’envoyer/récupérer des données.

Vous devez impérativement télécharger les bibliothèques WXwidgets et mettre les répertoires lib et inclue dans le répertoire de la solution. Choisissez les configuration LIBDebug ou LIBRelease pour compiler car le programme utilise des bibliothèques statiques. Télécharger les bibliothèques : https://www.wxwidgets.org/downloads/ Vous pouvez télécharger le code source et compiler les bibliothèques vous-même où télécharger les fichiers .lib précompilés.

Pour l’instant, l’application est encore en phase de développement, aucune release n’est disponible.

(non definitive / non deffinitif)

• CApp: main entry point of the application
• CMain: Management of the main window with events, message list and content display
• CSettings: Stores the application settings and manages a window for the user to enter them
• CContent: Stock the data of a message (text, username, date and time, files attached) and organize them in a panel.
• CImagePanel: Class allowing the display of an image in a panel

• CApp : point d’entrée principale de l’application
• CMain : Gestion de la fenêtre principale avec évènements, liste de message et affichage du contenu
• CSettings : Stock les paramètres de l’application et gère aussi une fenêtre pour que l’utilisateur puisse les saisir
• CContent : Stock les données d’un message (texte, nom d’utilisateur, date et heure, fichiers joints avec le message) et les organise dans un panneau.
• CImagePanel : Class permettant l’affichage d’une image sous forme de panneau

Tap2Pix ❤️ Super App Wallet 100% Tupiniquim for IOS & Android

Este projeto Android implementa um serviço de emulação de cartão NFC (Host-based Card Emulation, HCE), que permite ao dispositivo simular um cartão NFC e responder a comandos APDU (Application Protocol Data Units). A aplicação emula um cartão NDEF, permitindo a interação com leitores NFC compatíveis. O principal uso é fornecer informações como mensagens de texto ou URLs via NFC.

A proposta da Tap2Pix.org destaca-se como um Super App Wallet soberano, 100% tupiniquim, disponível em multiplataformas (iOS e Android – IPhone, Google e Samsung)

Que permite a iniciação automática dos pagamentos pela aproximação do celular via NFC ou através da leitura de QR Code.

Além disso, é o único que oferece ambas as jornadas de pagamento, com e sem redirecionamento. Permitindo uma gradual adaptação dos usuários.

O mais impressionante é que tudo isso é conduzido sob a governança e total controle dos associados no consórcio!

NfcFCardEmulation é um serviço Android que utiliza a tecnologia Host-based Card Emulation (HCE) para emular um cartão NFC e transmitir mensagens NDEF, como textos ou URLs, para leitores NFC. Ele é ideal para aplicações que precisam simular cartões NFC e responder a comandos APDU.

Veja mais em: https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation

O Banco Central do Brasil, por meio do Grupo de Trabalho de Padronização e Requisitos Técnicos, propôs uma padronização para pagamentos com PIX por Aproximação + APP Iniciador de Pagamentos no contexto do Open Finance, utilizando a Jornada Sem Redirecionamento (JSR).

O fluxo proposto consiste no envio, por meio do comando APDU, de uma URI padronizada por terminais de pagamento (maquininhas, smartphones ou pin pads), seguindo o seguinte formato:

pix://<hostname>?qr=<uri-encoded-emv-qr-string>&sig=<signature>

• “pix://”: 🟥 Permite o uso do deeplink, que oferece uma camada de segurança fraca. Contudo, qualquer aplicativo poderia utilizar esse deeplink. Quando combinado com o parâmetro "&sig=<signature>", seria possível criptografar o valor do parâmetro "qr=<uri-encoded-emv-qr-string>", aumentando a segurança, mas criando redundância, pois o “copie e cole” do Pix já possui criptografia suficiente.

• “<hostname>?”: 🟩 Permite o uso do domínio (Universal Link) https://tap2pix.app, com um certificado RSA, garante a camada de segurança necessária para comprovação de propriedade e execução exclusiva dos aplicativos instantâneos.

• “qr=<uri-encoded-emv-qr-string>”: 🟩 Este é o elemento central da interoperabilidade proposta pelo Banco Central. O QR code precisa estar em formato URI encode, para que os aplicativos bancários possam filtrar e absorver as informações transmitidas via GET. A informação contida no “copie e cole” é essencial para a realização da transação, enquanto as demais informações apenas compõem a personalização dos aplicativos e seus formatos de leitura.

• Emulação de cartão NFC (HCE): O dispositivo Android atua como um cartão NFC emulado.
• Resposta a comandos APDU: O serviço interpreta e responde a comandos APDU, como a seleção de aplicação, container de capacidade e arquivos NDEF.
• Envio de mensagens NDEF: Permite o envio de mensagens NDEF contendo texto ou URLs para dispositivos/leitores NFC.
• Suporte a mensagens dinâmicas: O serviço pode gerar mensagens NDEF com base em URLs fornecidas via Intent.

A principal classe do projeto é Tap2PixApduService, que herda de HostApduService e implementa a lógica de resposta aos comandos NFC.

• onCreate(): Inicializa o serviço, preparando uma mensagem NDEF padrão.
• onStartCommand(): Atualiza a mensagem NDEF com base nos dados recebidos via Intent.
• processCommandApdu(): Lida com os comandos APDU recebidos, respondendo com dados NDEF ou informações do container de capacidade.
• onDeactivated(): Reseta os estados quando o serviço NFC é desativado.

Os comandos APDU são usados para selecionar diferentes arquivos e responder com as informações correspondentes:

• Selecionar Aplicação: Seleciona a aplicação NDEF emulada.
• Selecionar Container de Capacidade: Seleciona o arquivo de capacidade NDEF.
• Selecionar Arquivo NDEF: Seleciona o arquivo que contém a mensagem NDEF.

A mensagem NDEF pode conter:

• Texto: Uma string em formato de texto (padrão).
• URL: Uma URL passada por Intent para emular um redirecionamento.

• Android Studio
• Um dispositivo Android com suporte a NFC e Host-based Card Emulation (HCE)

O formato padrão da URL para ser transmitido no Tap2Pix é o seguinte:

https://tap2pix.app/?qr=encodeURI(copie&cole)

A URL tap2pix.app foi configurada para garantir a segurança da aplicação, sendo compatível com os aplicativos instantâneos da Apple (App Clip) e Android (Instant App). O uso de Universal Links garante que apenas o domínio tap2pix.app inicie esses apps instantâneos, além de estar alinhado à proposta enviada pelo Banco Central do Brasil (BCB).

Abaixo está um exemplo de como seria a transmissão da URL do Tap2Pix com um QR code estático:

See demo  IOS/Apple: APP Clip

See demo Android/Google: Instant APP

Ou… Se estiver no desktop, faça a leitura do QR Code (IOS ou Android)

a

Essa estrutura segue as diretrizes de segurança e padronização exigidas pelo Banco Central, garantindo a eficácia e segurança do Tap2Pix em diferentes cenários de uso.

Para listar seu app no Tap2Pix, é necessário entrar em contato e fornecer os schemes do seu app. Vale lembrar que o Tap2Pix aceitará apps de BaaS e Bancos Sociais. Esses apps não são obrigatórios para o Open Finance na Jornada SEM Redirecionamento, que será lançada em fevereiro de 2025. Contudo, apps de BaaS, Bancos Sociais e de exchanges (optantes pelo OFF Ramp) podem solicitar inclusão via Jornada COM Redirecionamento.

É necessário fornecer os schemes do app junto com o Universal Link. Exemplo:

	"name": "BANCO-A",
	"brand": "https://static.eb.tech/img/BANCO-A.png",
	"universal_link": "https://www.BANCO-A.com.br/",
	"links": {
		"android": "BANCO-A://transferenciapix",
		"ios": "BANCO-A://transferenciapix"
	}

O Tap2Pix mapeia os apps instalados nos smartphones dos clientes [ Já desenvolvido para IOS ]. Checamos se os apps estão instalados no Smartphone (IOS e Android) dos clientes.

E iremos checar de 20 à 30 dad instituições mais utilizadas no Brasil estão presentes no Smartphone [ Estamos mapeando os universal link e schemes ].

Caso não estejam presente no Smartphone, os links dos apps serão removidos da listagem, garantindo que apenas os apps instalados [ A checagem dos 20 a 30 apps ] sejam exibidos.

A ordenação será feita com base nos últimos 3 apps utilizados pelo cliente [ Em desenvolvimento ], armazenando essa informação para que sejam listados primeiro, proporcionando uma experiência mais simples e eficaz.

O Pix já é um sucesso para pagamentos online e de serviços. No entanto, no uso presencial, ele ainda enfrenta obstáculos devido à fricção envolvida.

Em testes de laboratório, observamos que a jornada com QR Code exige de 8 a 12 interações (taps), resultando em um tempo total entre 20 e 50 segundos.

O Tap2Pix busca reduzir essa fricção nos pagamentos presenciais com Pix, proporcionando uma experiência mais simplificada.

• Na proposta do Tap2Pix COM redirecionamento, a jornada varia de 3 a 6 interações. A melhor experiência de UX foi alcançada com 3 taps, e, entre os bancos testados, o Mercado Pago apresentou 4 taps, com tempo de transação variando entre 6 e 15 segundos em média.

• Na proposta SEM redirecionamento, estimamos que o processo envolverá 2 cliques laterais + 1 ou 2 taps. Considerando que haverá mais um PSP intermediando a transação, acreditamos que a latência do JSR será ligeiramente maior devido às verificações de fraude, levando de 10 a 15 segundos em média.

• A experiência com a Wallet da Apple demonstrou ser extremamente eficiente, exigindo apenas 2 cliques laterais, com tempo médio de 5 a 10 segundos.

Para substituir a Wallet da Apple, outras wallets precisarão de 2 cliques laterais + 1 tap para ativar a leitura do NFC, levando de 10 a 15 segundos. No entanto, para que essas wallets sejam competitivas, é essencial que ofereçam uma UX superior à da Apple, para motivar os clientes a usá-las. Outros pontos identificados foram:

• Necessidade de atualização dos smartphones dos clientes para iOS 18.1 ou superior;
• Competição direta com a Wallet da Apple;
• Necessidade de interação para ativar a leitura do NFC;
• Competição com bandeiras de cartão de crédito;
• Instalação de um novo aplicativo de wallet;
• Limitação no suporte a NFCs de serviços, como cartão vacinal do governo, cartões de embarque, tickets de transporte, passaportes da Disney, entre outros.

O projeto Tap2Pix busca a democratização do Pix por Aproximação. Além de estar totalmente preparado para a Jornada SEM Redicionamento, ele também mantém a Jornada COM Redirecionamento.

• Disponibilidade do Pix por Aproximação antes do lançamento do JSR com o Open Finance (Fevereiro de 2025)
• A proposta do Tap2Pix não conflita com as bandeiras;
• Não competirá com Apple Pay ou Wallet no duplo clique lateral;
• Sua ativação é automática e instantânea;
• Compatível com iOS 15 e Android 12
• Prevê a jornada COM e SEM redirecionamento;
• Utiliza QR Code, NFC ou Link para ativação do SuperApp Wallet;
• Não requer instalação prévia;
• Tem menos de 100KB;
• Não necessita de autorização ou cadastro prévio dos clientes;
• Facilita a adaptação da usabilidade para os clientes;
• Não requer cadastro dos bancos (apenas mapeamento do Universal Link e sessão do Pix);
• Não precisa de modificações nos aplicativos bancários;
• Abrange BaaS e Bancos Sociais e não obrigatórios do #JSR;
• É um Super App Wallet multiplataforma (iOS e Android);
• Mantém todo o legado de segurança do método tradicional;
• Está 100% em conformidade com a regulamentação e a LGPD;
• É uma solução pioneira em nível mundial, desenvolvida por um grupo de empresas com uma proposta de padronização aberta para o uso de pagamentos via NFC, visando superar as limitações existentes;
• Entrará em produção (com a Jornada COM Redirecionamento) até o início de outubro de 2024.

Os aplicativos instantâneos estão em constante evolução, e a equipe do Tap2Pix já realizou todas as adaptações necessárias, continuando seu desenvolvimento contínuo.

Atualmente, o Tap2Pix está em fase de pré-lançamento, com os participantes do consórcio e as suas equipes de desenvolvimento trabalhando junto para alinhar o processo de onboarding, a listagem e os fluxos operacionais.

É importante destacar que, após a integração dos parceiros do consórcio, o Tap2Pix avançará para a criação da sua associação e estruturação de sua governança.

Abaixo, detalhamos os desafios encontrados e as soluções instantâneas adotadas para iOS e Android.

Ambos os sistemas de aplicativos instantâneos (iOS e Android) possuem documentação limitada, mas as recentes atualizações feitas pelas plataformas mostram que estão em constante evolução (Principalmente a do Android, que como descrito anteriormente. Ainda não suporta a sua inicialização direta pelo NFC. Necessitando assim haver uma pagina web, que antecede e faz a sua chamada.

Vale ressaltar, que nenhum dos participantes do Tap2Pix precisará se preocupar com o desenolvimento dos aplicativos instantâneos para plugarem ao Tap2Pix, toda a jornada e adpação necessária já foi feita pela equipe do Tap2Pix.

Os aplicativos instantâneos precisaram ser desenvolvidos utilizando a linguagem nativa das plataformas, como Kotlin no Android e Swift no IOS.

O IOS possui um app instantâneo com ótima UX, onde exibe um card mesmo com Iphone bloqueado. A limitação que encotramos junto ao APP CLIP da Apple foi no que diz respeito a sua invocação através do link. A Apple ainda não permite a ativação do app instantâneo utilizando o universal link (dominio tap2pix.app).

See demo IOS/Apple: APP Clip

O Android possui a sua limitação na invocação do app instantâneo através do NFC (O Google tem atualizado bastante o seu Instant APP e a comunidade tem exigido bastante essa invocação pelo NFC). O subterfúgio encontrado, foi em levar o cliente para o navegador e ao clicar em abrir ele executará o app instantâneo.

See demo Android/Google: Instant APP

1 - Padronização do QR Code com logo Tap2Pix;
2 - Criação do Fingerprint;
3 - Criação do Tap2Crypto (P2P de Stablecoin ou com OFF Ramp para Pix)
4 - Criação e consolidação do Consócio Tap2Pix
5 - Implementação da JSR com OpF;
6 - Incorporação de uma ID e One Click Buy (Estilo Click2Pay da Visa e Mastercard)

Sugestão dos nomes para a Associação Tap2Pix: ABTAP – Associação Brasileira de Transações por Aproximação OU APAW – Associação de Pagamentos por Aproximação e Wallet

Vamos unir forças para demonstrar que, por meio da colaboração coletiva, que podemos não apenas estabelecer um novo padrão, mas também transformar a maneira como os brasileiros realizam pagamentos contactless utilizando o Pix? Entre em contato!

Contato via Whatsapp

Email: hi@tap2pix.org

Veja mais em https://www.tap2pix.org

A AGPL-3.0 (Affero General Public License) é uma licença de software livre que protege desenvolvedores ao garantir que qualquer modificação ou uso do software seja compartilhado com a comunidade, mesmo quando ele é oferecido como um serviço remoto, como em aplicações web. Ela estende os princípios da GPL, incluindo a exigência de que, se alguém modificar o software para oferecer um serviço, deve disponibilizar o código-fonte modificado a todos os usuários desse serviço, se solicitado. Isso impede que empresas ou indivíduos utilizem o software para lucrar ou oferecer serviços sem compartilhar as melhorias ou adaptações feitas. Assim, a AGPL-3.0 assegura que todo trabalho colaborativo e aberto seja mantido público, promovendo um ciclo contínuo de melhorias e garantindo que os benefícios e inovações sejam acessíveis a toda a comunidade de desenvolvedores.

Open-source – veja mais em: AGPL License

Copyright © tap2pix.org 2024

Tap2Pix ❤️ Super App Wallet 100% Tupiniquim for IOS & Android

Este projeto Android implementa um serviço de emulação de cartão NFC (Host-based Card Emulation, HCE), que permite ao dispositivo simular um cartão NFC e responder a comandos APDU (Application Protocol Data Units). A aplicação emula um cartão NDEF, permitindo a interação com leitores NFC compatíveis. O principal uso é fornecer informações como mensagens de texto ou URLs via NFC.

A proposta da Tap2Pix.org destaca-se como um Super App Wallet soberano, 100% tupiniquim, disponível em multiplataformas (iOS e Android – IPhone, Google e Samsung)

Que permite a iniciação automática dos pagamentos pela aproximação do celular via NFC ou através da leitura de QR Code.

Além disso, é o único que oferece ambas as jornadas de pagamento, com e sem redirecionamento. Permitindo uma gradual adaptação dos usuários.

O mais impressionante é que tudo isso é conduzido sob a governança e total controle dos associados no consórcio!

NfcFCardEmulation é um serviço Android que utiliza a tecnologia Host-based Card Emulation (HCE) para emular um cartão NFC e transmitir mensagens NDEF, como textos ou URLs, para leitores NFC. Ele é ideal para aplicações que precisam simular cartões NFC e responder a comandos APDU.

Veja mais em: https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation

O Banco Central do Brasil, por meio do Grupo de Trabalho de Padronização e Requisitos Técnicos, propôs uma padronização para pagamentos com PIX por Aproximação + APP Iniciador de Pagamentos no contexto do Open Finance, utilizando a Jornada Sem Redirecionamento (JSR).

O fluxo proposto consiste no envio, por meio do comando APDU, de uma URI padronizada por terminais de pagamento (maquininhas, smartphones ou pin pads), seguindo o seguinte formato:

pix://<hostname>?qr=<uri-encoded-emv-qr-string>&sig=<signature>

• “pix://”: 🟥 Permite o uso do deeplink, que oferece uma camada de segurança fraca. Contudo, qualquer aplicativo poderia utilizar esse deeplink. Quando combinado com o parâmetro "&sig=<signature>", seria possível criptografar o valor do parâmetro "qr=<uri-encoded-emv-qr-string>", aumentando a segurança, mas criando redundância, pois o “copie e cole” do Pix já possui criptografia suficiente.

• “<hostname>?”: 🟩 Permite o uso do domínio (Universal Link) https://tap2pix.app, com um certificado RSA, garante a camada de segurança necessária para comprovação de propriedade e execução exclusiva dos aplicativos instantâneos.

• “qr=<uri-encoded-emv-qr-string>”: 🟩 Este é o elemento central da interoperabilidade proposta pelo Banco Central. O QR code precisa estar em formato URI encode, para que os aplicativos bancários possam filtrar e absorver as informações transmitidas via GET. A informação contida no “copie e cole” é essencial para a realização da transação, enquanto as demais informações apenas compõem a personalização dos aplicativos e seus formatos de leitura.

• Emulação de cartão NFC (HCE): O dispositivo Android atua como um cartão NFC emulado.
• Resposta a comandos APDU: O serviço interpreta e responde a comandos APDU, como a seleção de aplicação, container de capacidade e arquivos NDEF.
• Envio de mensagens NDEF: Permite o envio de mensagens NDEF contendo texto ou URLs para dispositivos/leitores NFC.
• Suporte a mensagens dinâmicas: O serviço pode gerar mensagens NDEF com base em URLs fornecidas via Intent.

A principal classe do projeto é Tap2PixApduService, que herda de HostApduService e implementa a lógica de resposta aos comandos NFC.

• onCreate(): Inicializa o serviço, preparando uma mensagem NDEF padrão.
• onStartCommand(): Atualiza a mensagem NDEF com base nos dados recebidos via Intent.
• processCommandApdu(): Lida com os comandos APDU recebidos, respondendo com dados NDEF ou informações do container de capacidade.
• onDeactivated(): Reseta os estados quando o serviço NFC é desativado.

Os comandos APDU são usados para selecionar diferentes arquivos e responder com as informações correspondentes:

• Selecionar Aplicação: Seleciona a aplicação NDEF emulada.
• Selecionar Container de Capacidade: Seleciona o arquivo de capacidade NDEF.
• Selecionar Arquivo NDEF: Seleciona o arquivo que contém a mensagem NDEF.

A mensagem NDEF pode conter:

• Texto: Uma string em formato de texto (padrão).
• URL: Uma URL passada por Intent para emular um redirecionamento.

• Android Studio
• Um dispositivo Android com suporte a NFC e Host-based Card Emulation (HCE)

O formato padrão da URL para ser transmitido no Tap2Pix é o seguinte:

https://tap2pix.app/?qr=encodeURI(copie&cole)

A URL tap2pix.app foi configurada para garantir a segurança da aplicação, sendo compatível com os aplicativos instantâneos da Apple (App Clip) e Android (Instant App). O uso de Universal Links garante que apenas o domínio tap2pix.app inicie esses apps instantâneos, além de estar alinhado à proposta enviada pelo Banco Central do Brasil (BCB).

Abaixo está um exemplo de como seria a transmissão da URL do Tap2Pix com um QR code estático:

See demo  IOS/Apple: APP Clip

See demo Android/Google: Instant APP

Ou… Se estiver no desktop, faça a leitura do QR Code (IOS ou Android)

a

Essa estrutura segue as diretrizes de segurança e padronização exigidas pelo Banco Central, garantindo a eficácia e segurança do Tap2Pix em diferentes cenários de uso.

Para listar seu app no Tap2Pix, é necessário entrar em contato e fornecer os schemes do seu app. Vale lembrar que o Tap2Pix aceitará apps de BaaS e Bancos Sociais. Esses apps não são obrigatórios para o Open Finance na Jornada SEM Redirecionamento, que será lançada em fevereiro de 2025. Contudo, apps de BaaS, Bancos Sociais e de exchanges (optantes pelo OFF Ramp) podem solicitar inclusão via Jornada COM Redirecionamento.

É necessário fornecer os schemes do app junto com o Universal Link. Exemplo:

	"name": "BANCO-A",
	"brand": "https://static.eb.tech/img/BANCO-A.png",
	"universal_link": "https://www.BANCO-A.com.br/",
	"links": {
		"android": "BANCO-A://transferenciapix",
		"ios": "BANCO-A://transferenciapix"
	}

O Tap2Pix mapeia os apps instalados nos smartphones dos clientes [ Já desenvolvido para IOS ]. Checamos se os apps estão instalados no Smartphone (IOS e Android) dos clientes.

E iremos checar de 20 à 30 dad instituições mais utilizadas no Brasil estão presentes no Smartphone [ Estamos mapeando os universal link e schemes ].

Caso não estejam presente no Smartphone, os links dos apps serão removidos da listagem, garantindo que apenas os apps instalados [ A checagem dos 20 a 30 apps ] sejam exibidos.

A ordenação será feita com base nos últimos 3 apps utilizados pelo cliente [ Em desenvolvimento ], armazenando essa informação para que sejam listados primeiro, proporcionando uma experiência mais simples e eficaz.

O Pix já é um sucesso para pagamentos online e de serviços. No entanto, no uso presencial, ele ainda enfrenta obstáculos devido à fricção envolvida.

Em testes de laboratório, observamos que a jornada com QR Code exige de 8 a 12 interações (taps), resultando em um tempo total entre 20 e 50 segundos.

O Tap2Pix busca reduzir essa fricção nos pagamentos presenciais com Pix, proporcionando uma experiência mais simplificada.

• Na proposta do Tap2Pix COM redirecionamento, a jornada varia de 3 a 6 interações. A melhor experiência de UX foi alcançada com 3 taps, e, entre os bancos testados, o Mercado Pago apresentou 4 taps, com tempo de transação variando entre 6 e 15 segundos em média.

• Na proposta SEM redirecionamento, estimamos que o processo envolverá 2 cliques laterais + 1 ou 2 taps. Considerando que haverá mais um PSP intermediando a transação, acreditamos que a latência do JSR será ligeiramente maior devido às verificações de fraude, levando de 10 a 15 segundos em média.

• A experiência com a Wallet da Apple demonstrou ser extremamente eficiente, exigindo apenas 2 cliques laterais, com tempo médio de 5 a 10 segundos.

Para substituir a Wallet da Apple, outras wallets precisarão de 2 cliques laterais + 1 tap para ativar a leitura do NFC, levando de 10 a 15 segundos. No entanto, para que essas wallets sejam competitivas, é essencial que ofereçam uma UX superior à da Apple, para motivar os clientes a usá-las. Outros pontos identificados foram:

• Necessidade de atualização dos smartphones dos clientes para iOS 18.1 ou superior;
• Competição direta com a Wallet da Apple;
• Necessidade de interação para ativar a leitura do NFC;
• Competição com bandeiras de cartão de crédito;
• Instalação de um novo aplicativo de wallet;
• Limitação no suporte a NFCs de serviços, como cartão vacinal do governo, cartões de embarque, tickets de transporte, passaportes da Disney, entre outros.

O projeto Tap2Pix busca a democratização do Pix por Aproximação. Além de estar totalmente preparado para a Jornada SEM Redicionamento, ele também mantém a Jornada COM Redirecionamento.

• Disponibilidade do Pix por Aproximação antes do lançamento do JSR com o Open Finance (Fevereiro de 2025)
• A proposta do Tap2Pix não conflita com as bandeiras;
• Não competirá com Apple Pay ou Wallet no duplo clique lateral;
• Sua ativação é automática e instantânea;
• Compatível com iOS 15 e Android 12
• Prevê a jornada COM e SEM redirecionamento;
• Utiliza QR Code, NFC ou Link para ativação do SuperApp Wallet;
• Não requer instalação prévia;
• Tem menos de 100KB;
• Não necessita de autorização ou cadastro prévio dos clientes;
• Facilita a adaptação da usabilidade para os clientes;
• Não requer cadastro dos bancos (apenas mapeamento do Universal Link e sessão do Pix);
• Não precisa de modificações nos aplicativos bancários;
• Abrange BaaS e Bancos Sociais e não obrigatórios do #JSR;
• É um Super App Wallet multiplataforma (iOS e Android);
• Mantém todo o legado de segurança do método tradicional;
• Está 100% em conformidade com a regulamentação e a LGPD;
• É uma solução pioneira em nível mundial, desenvolvida por um grupo de empresas com uma proposta de padronização aberta para o uso de pagamentos via NFC, visando superar as limitações existentes;
• Entrará em produção (com a Jornada COM Redirecionamento) até o início de outubro de 2024.

Os aplicativos instantâneos estão em constante evolução, e a equipe do Tap2Pix já realizou todas as adaptações necessárias, continuando seu desenvolvimento contínuo.

Atualmente, o Tap2Pix está em fase de pré-lançamento, com os participantes do consórcio e as suas equipes de desenvolvimento trabalhando junto para alinhar o processo de onboarding, a listagem e os fluxos operacionais.

É importante destacar que, após a integração dos parceiros do consórcio, o Tap2Pix avançará para a criação da sua associação e estruturação de sua governança.

Abaixo, detalhamos os desafios encontrados e as soluções instantâneas adotadas para iOS e Android.

Ambos os sistemas de aplicativos instantâneos (iOS e Android) possuem documentação limitada, mas as recentes atualizações feitas pelas plataformas mostram que estão em constante evolução (Principalmente a do Android, que como descrito anteriormente. Ainda não suporta a sua inicialização direta pelo NFC. Necessitando assim haver uma pagina web, que antecede e faz a sua chamada.

Vale ressaltar, que nenhum dos participantes do Tap2Pix precisará se preocupar com o desenolvimento dos aplicativos instantâneos para plugarem ao Tap2Pix, toda a jornada e adpação necessária já foi feita pela equipe do Tap2Pix.

Os aplicativos instantâneos precisaram ser desenvolvidos utilizando a linguagem nativa das plataformas, como Kotlin no Android e Swift no IOS.

O IOS possui um app instantâneo com ótima UX, onde exibe um card mesmo com Iphone bloqueado. A limitação que encotramos junto ao APP CLIP da Apple foi no que diz respeito a sua invocação através do link. A Apple ainda não permite a ativação do app instantâneo utilizando o universal link (dominio tap2pix.app).

See demo IOS/Apple: APP Clip

O Android possui a sua limitação na invocação do app instantâneo através do NFC (O Google tem atualizado bastante o seu Instant APP e a comunidade tem exigido bastante essa invocação pelo NFC). O subterfúgio encontrado, foi em levar o cliente para o navegador e ao clicar em abrir ele executará o app instantâneo.

See demo Android/Google: Instant APP

1 - Padronização do QR Code com logo Tap2Pix;
2 - Criação do Fingerprint;
3 - Criação do Tap2Crypto (P2P de Stablecoin ou com OFF Ramp para Pix)
4 - Criação e consolidação do Consócio Tap2Pix
5 - Implementação da JSR com OpF;
6 - Incorporação de uma ID e One Click Buy (Estilo Click2Pay da Visa e Mastercard)

Sugestão dos nomes para a Associação Tap2Pix: ABTAP – Associação Brasileira de Transações por Aproximação OU APAW – Associação de Pagamentos por Aproximação e Wallet

Vamos unir forças para demonstrar que, por meio da colaboração coletiva, que podemos não apenas estabelecer um novo padrão, mas também transformar a maneira como os brasileiros realizam pagamentos contactless utilizando o Pix? Entre em contato!

Contato via Whatsapp

Email: hi@tap2pix.org

Veja mais em https://www.tap2pix.org

A AGPL-3.0 (Affero General Public License) é uma licença de software livre que protege desenvolvedores ao garantir que qualquer modificação ou uso do software seja compartilhado com a comunidade, mesmo quando ele é oferecido como um serviço remoto, como em aplicações web. Ela estende os princípios da GPL, incluindo a exigência de que, se alguém modificar o software para oferecer um serviço, deve disponibilizar o código-fonte modificado a todos os usuários desse serviço, se solicitado. Isso impede que empresas ou indivíduos utilizem o software para lucrar ou oferecer serviços sem compartilhar as melhorias ou adaptações feitas. Assim, a AGPL-3.0 assegura que todo trabalho colaborativo e aberto seja mantido público, promovendo um ciclo contínuo de melhorias e garantindo que os benefícios e inovações sejam acessíveis a toda a comunidade de desenvolvedores.

Open-source – veja mais em: AGPL License

Copyright © tap2pix.org 2024

This repo contains information and examples of Packer templates for creating images of both Linux and Windows.

Packer is an open source tool for creating identical machine images for multiple platforms from a single source configuration. Packer is lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel. Packer does not replace configuration management like Chef. In fact, when building images, Packer is able to use tools like Chef to install software onto the image.

A machine image is a single static unit that contains a pre-configured operating system and installed software which is used to quickly create new running machines. Machine image formats change for each platform. Some examples include AMIs for EC2, VMDK/VMX files for VMware, OVF exports for VirtualBox, etc.

The configuration file used to define what image we want built and how is called a template in Packer terminology. The format of a template is simple JSON. JSON struck the best balance between human-editable and machine-editable, allowing both hand-made templates as well as machine generated templates to easily be made.

The Chef Client Packer provisioner installs and configures software on machines built by Packer using chef-client. Packer configures a Chef client to talk to a remote Chef Server to provision the machine.

The provisioner will even install Chef onto your machine if it isn’t already installed, using the official Chef installers provided by Chef.

The example below is fully functional. It will install Chef onto the remote machine and run Chef client.

{
  "type": "chef-client",
  "server_url": "https://mychefserver.com/"
}

The following example shows how to run the chef-client provisioner in local mode, while passing a run_list using a variable.

# Machine's Chef directory
export PACKER_CHEF_DIR=/var/chef-packer
# Comma separated run_list
export PACKER_CHEF_RUN_LIST="recipe[apt],recipe[nginx]"

Set the necessary Packer variables using environment variables or provide a var file.

"variables": {
  "chef_dir": "{{env `PACKER_CHEF_DIR`}}",
  "chef_run_list": "{{env `PACKER_CHEF_RUN_LIST`}}",
  "chef_client_config_tpl": "{{env `PACKER_CHEF_CLIENT_CONFIG_TPL`}}",
  "packer_chef_bootstrap_dir": "{{env `PACKER_CHEF_BOOTSTRAP_DIR`}}" ,
  "packer_uid": "{{env `PACKER_UID`}}",
  "packer_gid": "{{env `PACKER_GID`}}"
}

Make sure we have the correct directories and permissions for the chef-client provisioner. You will need to bootstrap the Chef run by providing the necessary cookbooks using Berkshelf or some other means.

{
  "type": "file",
  "source": "{{user `packer_chef_bootstrap_dir`}}",
  "destination": "/tmp/bootstrap"
},
{
  "type": "shell",
  "inline": [
    "sudo mkdir -p {{user `chef_dir`}}",
    "sudo mkdir -p /tmp/packer-chef-client",
    "sudo chown {{user `packer_uid`}}.{{user `packer_gid`}} /tmp/packer-chef-client",
    "sudo sh /tmp/bootstrap/bootstrap.sh"
  ]
},
{
  "type": "chef-client",
  "server_url": "http://localhost:8889",
  "config_template": "{{user `chef_client_config_tpl`}}/client.rb.tpl",
  "skip_clean_node": true,
  "skip_clean_client": true,
  "run_list": "{{user `chef_run_list`}}"
}

The reference of available configuration options is listed below. No configuration is actually required.

• chef_environment (string) – The name of the chef_environment sent to the Chef server. By default this is empty and will not use an environment.

• config_template (string) – Path to a template that will be used for the Chef configuration file. By default Packer only sets configuration it needs to match the settings set in the provisioner configuration. If you need to set configurations that the Packer provisioner doesn’t support, then you should use a custom configuration template. See the dedicated “Chef Configuration” section below for more details.

• encrypted_data_bag_secret_path (string) – The path to the file containing the secret for encrypted data bags. By default, this is empty, so no secret will be available.

• execute_command (string) – The command used to execute Chef. This has various configuration template variables available. See below for more information.

• guest_os_type (string) – The target guest OS type, either “unix” or “windows”. Setting this to “windows” will cause the provisioner to use Windows friendly paths and commands. By default, this is “unix”.

• install_command (string) – The command used to install Chef. This has various configuration template variables available. See below for more information.

• json (object) – An arbitrary mapping of JSON that will be available as node attributes while running Chef.

• knife_command (string) – The command used to run Knife during node clean-up. This has various configuration template variables available. See below for more information.

• node_name (string) – The name of the node to register with the Chef Server. This is optional and by default is packer-{{uuid}}.

• policy_group (string) – The name of a policy group that exists on the Chef server. policy_name must also be specified.

• policy_name (string) – The name of a policy, as identified by the name setting in a Policyfile.rb file. policy_group must also be specified.

• prevent_sudo (boolean) – By default, the configured commands that are executed to install and run Chef are executed with sudo. If this is true, then the sudo will be omitted. This has no effect when guest_os_type is windows.

• run_list (array of strings) – The run list for Chef. By default this is empty, and will use the run list sent down by the Chef Server.

• server_url (string) – The URL to the Chef server. This is required.

• skip_clean_client (boolean) – If true, Packer won’t remove the client from the Chef server after it is done running. By default, this is false.

• skip_clean_node (boolean) – If true, Packer won’t remove the node from the Chef server after it is done running. By default, this is false.

• skip_clean_staging_directory (boolean) – If true, Packer won’t remove the Chef staging directory from the machine after it is done running. By default, this is false.

• skip_install (boolean) – If true, Chef will not automatically be installed on the machine using the Chef omnibus installers.

• ssl_verify_mode (string) – Set to “verify_none” to skip validation of SSL certificates. If not set, this defaults to “verify_peer” which validates all SSL certifications.

• trusted_certs_dir (string) – This is a directory that contains additional SSL certificates to trust. Any certificates in this directory will be added to whatever CA bundle ruby is using. Use this to add self-signed certs for your Chef Server or local HTTP file servers.

• staging_directory (string) – This is the directory where all the configuration of Chef by Packer will be placed. By default this is “/tmp/packer-chef-client” when guest_os_type unix and “$env:TEMP/packer-chef-client” when windows. This directory doesn’t need to exist but must have proper permissions so that the user that Packer uses is able to create directories and write into this folder. By default the provisioner will create and chmod 0777 this directory.

• client_key (string) – Path to client key. If not set, this defaults to a file named client.pem in staging_directory.

• validation_client_name (string) – Name of the validation client. If not set, this won’t be set in the configuration and the default that Chef uses will be used.

• validation_key_path (string) – Path to the validation key for communicating with the Chef Server. This will be uploaded to the remote machine. If this is NOT set, then it is your responsibility via other means (shell provisioner, etc.) to get a validation key to where Chef expects it.

Peng Wang, Yichun Shi

Project Page | Paper | Demo

This part is the same as original MVDream-threestudio. Skip it if you already have installed the environment.

Clone the modelcard on the Huggingface ImageDream Model Page under ./extern/ImageDream/release_models/

In the paper, we use the configuration with soft-shading. It would need an A100 GPU in most cases to compute normal:

export PYTHONPATH=$PYTHONPATH:./extern/ImageDream
image_file="./extern/ImageDream/assets/astronaut.png"
ckpt_file="./extern/ImageDream/release_models/ImageDream/sd-v2.1-base-4view-ipmv.pt"
cfg_file="./extern/ImageDream/imagedream/configs/sd_v2_base_ipmv.yaml"

python3 launch.py \
    --config configs/$method.yaml --train --gpu 0 \
    name="imagedream-sd21-shading" tag="astronaut" \
    system.prompt_processor.prompt="an astronaut riding a horse" \
    system.prompt_processor.image_path="${image_file}" \
    system.guidance.ckpt_path="${ckpt_file}" \
    system.guidance.config_path="${cfg_file}"

For diffusion only model, refer to subdir ./extern/ImageDream/
Check ./threestudio/scripts/run_imagedream.sh for a bash example.

• This code is forked from threestudio and MVDream for SDS and 3D Generation.

1. Place the object in the center and do not make it too large/small in the image.
2. If you have an object cutting image edge, in config, tuning the parameters range of elevation and fov to be a larger range, e.g. [0, 30], otherwise, you may do image outpainting and follow tips 1.
3. Check the results with ImageDream diffusion model before using it in 3D rendering to save time.

• Since there is some randomness in diffusion model and time costly to get baseline results. We put our pre-computed results for reproducing Tab.1 in the paper in a hugging face dataset card

If you find ImageDream helpful, please consider citing:

@article{wang2023imagedream,
  title={ImageDream: Image-Prompt Multi-view Diffusion for 3D Generation},
  author={Wang, Peng and Shi, Yichun},
  journal={arXiv preprint arXiv:2312.02201},
  year={2023}
}