Compare commits
14 Commits
6e47328997
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
afcacf6df4 | ||
|
422912b16a
|
|||
| 33f4e5bdaf | |||
|
e29e4eca7c
|
|||
| f6aada604d | |||
| 0420f4026b | |||
|
98c64f6efb
|
|||
|
54b10ec46d
|
|||
|
5fd69861c4
|
|||
|
a8dbcb1645
|
|||
| 8430d99c05 | |||
| 352b2b8a7c | |||
| da825b6082 | |||
| 737059aeab |
3
.gitignore
vendored
Normal file
3
.gitignore
vendored
Normal file
@@ -0,0 +1,3 @@
|
||||
.obsidian/workspace.json
|
||||
.obsidian/workspace.json
|
||||
./Nf
|
||||
16
.obsidian/plugins/webpage-html-export/data.json
vendored
16
.obsidian/plugins/webpage-html-export/data.json
vendored
@@ -10,7 +10,7 @@
|
||||
"postProcess": true,
|
||||
"displayProgress": true,
|
||||
"inlineHTML": false,
|
||||
"exportPath": "/home/kevin/Desktop/test2",
|
||||
"exportPath": "",
|
||||
"filesToExport": [],
|
||||
"useFallbackRenderer": false,
|
||||
"addBodyClasses": true,
|
||||
@@ -196,7 +196,7 @@
|
||||
"alwaysEnabled": false,
|
||||
"hideSettingsButton": true
|
||||
},
|
||||
"relativeHeaderLinks": true,
|
||||
"relativeHeaderLinks": false,
|
||||
"includeJS": true,
|
||||
"includeCSS": true,
|
||||
"inlineMedia": false,
|
||||
@@ -214,18 +214,12 @@
|
||||
"siteName": "JiboDocs",
|
||||
"iconEmojiStyle": "Native",
|
||||
"exportRoot": "",
|
||||
"includePluginCss": [
|
||||
"code-styler",
|
||||
"code-styler-styles"
|
||||
],
|
||||
"includeStyleCssIds": [
|
||||
"code-styler",
|
||||
"code-styler-styles"
|
||||
],
|
||||
"includePluginCss": [],
|
||||
"includeStyleCssIds": [],
|
||||
"autoDisposeWebpages": true
|
||||
},
|
||||
"logLevel": "warning",
|
||||
"titleProperty": "JRD",
|
||||
"titleProperty": "title",
|
||||
"rssDateProperty": "date",
|
||||
"onlyExportModified": true,
|
||||
"deleteOldFiles": true,
|
||||
|
||||
132
.obsidian/workspace.json
vendored
132
.obsidian/workspace.json
vendored
@@ -4,79 +4,24 @@
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "05bab3d2778ffeca",
|
||||
"id": "7b3950c54aff9719",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "6d78e1847f72f5de",
|
||||
"id": "cf241359d22c6783",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "Getting Started/Welcome to the Jibo Revival Project.md",
|
||||
"file": "Documentation/Voice/Local Voice Round-Trip on Jibo (AI Commmunication).md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "Welcome to the Jibo Revival Project"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "c3f7d6e3edde93cc",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "Jibo Reval Project/Attack Vectors/Hardware and Tegra Exploitation.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "Hardware and Tegra Exploitation"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "0806f039bf8a940e",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "Jibo Reval Project/Getting Started/Modifying the Firmware/1. Get your environment ready!.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "1. Get your environment ready!"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "8f09013cb382a9eb",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "release-notes",
|
||||
"state": {
|
||||
"currentVersion": "1.12.4"
|
||||
},
|
||||
"icon": "lucide-book-up",
|
||||
"title": "Release Notes 1.12.4"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "bca83b8556c51cdb",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "index.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "index"
|
||||
"title": "Local Voice Round-Trip on Jibo (AI Commmunication)"
|
||||
}
|
||||
}
|
||||
],
|
||||
"currentTab": 4
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
@@ -235,7 +180,8 @@
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300
|
||||
"width": 200,
|
||||
"collapsed": true
|
||||
},
|
||||
"left-ribbon": {
|
||||
"hiddenItems": {
|
||||
@@ -251,35 +197,49 @@
|
||||
"quartz-syncer:Quartz Syncer publication center": false
|
||||
}
|
||||
},
|
||||
"active": "1895b61c1551dd83",
|
||||
"active": "cf241359d22c6783",
|
||||
"lastOpenFiles": [
|
||||
"Getting Started/Developing for Jibo/Introduction to the New Jibo SDK.md",
|
||||
"Getting Started/Welcome to the Jibo Revival Project.md",
|
||||
"index.md",
|
||||
"home/kevin/Documents/Jibo-Official-Endpoints/README.md",
|
||||
"home/kevin/Documents/Jibo-Official-Endpoints",
|
||||
"home/kevin/Documents",
|
||||
"home/kevin",
|
||||
"home",
|
||||
"Documentation/Useful Items List.md",
|
||||
"README.md",
|
||||
"Getting Started/Developing for Jibo/About - Jibo SDK V2!.md",
|
||||
"External Devices/MFSx",
|
||||
"External Devices",
|
||||
"Documentation/Voice/Local Voice Round-Trip on Jibo (AI Commmunication).md",
|
||||
"Jibo Tools & Mod Installer/08 - Troubleshooting.md",
|
||||
"Documentation/Voice",
|
||||
"Jibo Tools & Mod Installer/07 - Working Directory + State Files.md",
|
||||
"Jibo Tools & Mod Installer/01 - Installer (How It Works).md",
|
||||
"Getting Started/Modifying the Firmware/Using the install script.md",
|
||||
"Getting Started/Developing for Jibo",
|
||||
"index.md",
|
||||
"obsidian/08 - Troubleshooting.md",
|
||||
"obsidian/07 - Working Directory + State Files.md",
|
||||
"obsidian/06 - Updater (How It Works).md",
|
||||
"obsidian/05 - Windows Support.md",
|
||||
"obsidian/04 - GUI (How It Works).md",
|
||||
"obsidian/03 - CLI Arguments.md",
|
||||
"obsidian/02 - Mapping to guide.md",
|
||||
"obsidian/01 - Installer (How It Works).md",
|
||||
"obsidian/00 - Index.md",
|
||||
"obsidian",
|
||||
"Documentation/Menu Buttons/ButtonSetup.png",
|
||||
"Documentation/Menu Buttons/ButtonSetup.kra",
|
||||
"Documentation/Menu Buttons",
|
||||
"Jibo Tools & Mod Installer/06 - Updater (How It Works).md",
|
||||
"Jibo Tools & Mod Installer/05 - Windows Support.md",
|
||||
"Jibo Tools & Mod Installer/04 - GUI (How It Works).md",
|
||||
"Assets/JiboToolsScreen.png",
|
||||
"Assets/Screenshot_20260317_235807.png",
|
||||
"Jibo Tools & Mod Installer/03 - CLI Arguments.md",
|
||||
"Getting Started/Modifying the Firmware/1. Get your environment ready!.md",
|
||||
"Dictionary/Robot Os.md",
|
||||
"Dictionary/ESML.md",
|
||||
"Jibo Workshop HRI 2024.md",
|
||||
"Dictionary/NVIDIA Tegra K1 (T124) Soc.md",
|
||||
"Dictionary/ShofEL2 - Fusée Gelée Exploit.md",
|
||||
"Attack Vectors/Hardware and Tegra Exploitation.md",
|
||||
"Discoveries/Network Profiling & Traffic Analysis.md",
|
||||
"Documentation/Validated memory adresses.md",
|
||||
"Jibo Tools & Mod Installer/00 - Index.md",
|
||||
"Jibo Tools & Mod Installer/02 - Mapping to guide.md",
|
||||
"Getting Started/Welcome to the Jibo Revival Project.md",
|
||||
"Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.png",
|
||||
"Assets/Jibo RCM.jpg",
|
||||
"Getting Started/Modifying the Firmware",
|
||||
"Getting Started",
|
||||
"Jibo Reval Project/Uncategorized/The \"MIT Application\" Mystery saga.md",
|
||||
"Attack Vectors",
|
||||
"ESML/Jibo-Animations.pdf",
|
||||
"ESML/ESML-SDK.pdf",
|
||||
"Jibo Reval Project",
|
||||
"Untitled.base",
|
||||
"Assets/JiboChatGPT.png",
|
||||
"Assets",
|
||||
"ESML"
|
||||
"Assets/JiboChatGPT.png"
|
||||
]
|
||||
}
|
||||
BIN
Assets/JiboToolsScreen.png
Normal file
BIN
Assets/JiboToolsScreen.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
BIN
Assets/Screenshot_20260317_235807.png
Normal file
BIN
Assets/Screenshot_20260317_235807.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
254
Documentation/AtDev - New Firewall script.md
Normal file
254
Documentation/AtDev - New Firewall script.md
Normal file
@@ -0,0 +1,254 @@
|
||||
- - -
|
||||
# #AtDev , work in progress
|
||||
- - -
|
||||
Under /etc/init.d/ we have
|
||||
|
||||
```shell
|
||||
|
||||
# cd /etc/init.d/
|
||||
# ls
|
||||
S00fix-os S15crond S33dbus S48avahi-daemon S63body-board-power S78jibo-system-manager
|
||||
S01logging S18udev S36sshd S51upload-logs S66ntp S81named
|
||||
S06coredumps S21firewall S39audio-enable S54modules S69start-X11 S84identity-syslog
|
||||
S09wifi-enable S24cpufreq S42avahi-setup.sh S57alsa-volume S72jibo-apply-update rcK
|
||||
S12dns-prime S30urandom S45network S60alsaloopback S75jibo-service-registry rcS
|
||||
|
||||
```
|
||||
|
||||
currently interested in `/etc/init.d/S21firewall`
|
||||
|
||||
```log
|
||||
# cat /etc/init.d/S21firewall
|
||||
#!/bin/sh
|
||||
#
|
||||
# Jibo Firewall init script
|
||||
#
|
||||
|
||||
set -e
|
||||
|
||||
IPTABLES_CMDS="/usr/sbin/iptables /usr/sbin/ip6tables"
|
||||
|
||||
flush_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
$iptables -t filter -F
|
||||
$iptables -t filter -P INPUT ACCEPT
|
||||
$iptables -t filter -P FORWARD ACCEPT
|
||||
$iptables -t filter -P OUTPUT ACCEPT
|
||||
# add the DYNAMIC_ACCESS chain unconditionally
|
||||
$iptables -t filter -X
|
||||
$iptables -t filter -N DYNAMIC_ACCESS
|
||||
done
|
||||
}
|
||||
|
||||
normal_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
$iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
$iptables -t filter -A INPUT -p icmp -j ACCEPT
|
||||
$iptables -t filter -A INPUT -i lo -j ACCEPT
|
||||
# allow dynamic access rules from system-manager
|
||||
$iptables -t filter -A INPUT -j DYNAMIC_ACCESS
|
||||
$iptables -t filter -A INPUT -j REJECT
|
||||
$iptables -t filter -A FORWARD -j REJECT
|
||||
done
|
||||
}
|
||||
|
||||
developer_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
# jibo-dev-shell
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 8686 -j ACCEPT
|
||||
# jibo-skills-service
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 8779 -j ACCEPT
|
||||
# jibo-sync
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 8989 -j ACCEPT
|
||||
# jibo-debug-proxy
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 9191 -j ACCEPT
|
||||
# avahi
|
||||
$iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
|
||||
done
|
||||
normal_rules
|
||||
}
|
||||
|
||||
certification_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
# jibo-certification-service
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
|
||||
done
|
||||
normal_rules
|
||||
}
|
||||
|
||||
service_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
# jibo-certification-service
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 9292 -j ACCEPT
|
||||
# jibo-service-center-service
|
||||
$iptables -t filter -A INPUT -p tcp --syn --dport 9797 -j ACCEPT
|
||||
# avahi
|
||||
$iptables -t filter -A INPUT -p udp --dport 5353 -j ACCEPT
|
||||
done
|
||||
normal_rules
|
||||
}
|
||||
|
||||
start() {
|
||||
echo -n "Configuring firewall: "
|
||||
flush_rules
|
||||
my_mode=$(/usr/bin/jibo-getmode)
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "Unspecified mode. SKIP"
|
||||
elif [ "$my_mode" == "identified" ]; then
|
||||
echo "IDENTIFIED"
|
||||
elif [ "$my_mode" == "int-developer" ]; then
|
||||
echo "INT-DEVELOPER"
|
||||
elif [ "$my_mode" == "developer" ]; then
|
||||
developer_rules
|
||||
test $? -eq 0 && echo "DEVELOPER" || echo "ERROR"
|
||||
elif [ "$my_mode" == "certification" ]; then
|
||||
certification_rules
|
||||
test $? -eq 0 && echo "CERTIFICATION" || echo "ERROR"
|
||||
elif [ "$my_mode" == "service" ]; then
|
||||
service_rules
|
||||
test $? -eq 0 && echo "SERVICE" || echo "ERROR"
|
||||
else
|
||||
normal_rules
|
||||
test $? -eq 0 && echo "OK" || echo "ERROR"
|
||||
fi
|
||||
}
|
||||
|
||||
stop() {
|
||||
echo -n "Unconfiguring firewall: "
|
||||
flush_rules
|
||||
test $? -eq 0 && echo "OK" || echo "ERROR"
|
||||
}
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
start
|
||||
;;
|
||||
stop)
|
||||
stop
|
||||
;;
|
||||
restart)
|
||||
stop
|
||||
start
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start|stop|restart}" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
```
|
||||
|
||||
and in `S78jibo-system-manager`
|
||||
|
||||
```log
|
||||
# cat S78jibo-system-manager
|
||||
#!/bin/sh
|
||||
#
|
||||
# Jibo System Manager init script
|
||||
#
|
||||
|
||||
set -e
|
||||
|
||||
PROCESS=jibo-system-manager
|
||||
BIN_DIR=/usr/local/bin
|
||||
CFG_DIR=/usr/local/etc
|
||||
|
||||
check_mode() {
|
||||
my_mode=$(/usr/bin/jibo-getmode)
|
||||
if [ $? -ne 0 ]; then
|
||||
echo "Unspecified mode. SKIP"
|
||||
exit 0;
|
||||
fi
|
||||
if [ "$my_mode" != "oobe" \
|
||||
-a "$my_mode" != "int-developer" \
|
||||
-a "$my_mode" != "developer" \
|
||||
-a "$my_mode" != "normal" \
|
||||
-a "$my_mode" != "certification" \
|
||||
-a "$my_mode" != "service" ]; then
|
||||
echo "Mode is $my_mode. SKIP"
|
||||
exit 0;
|
||||
fi
|
||||
# only configure coredump generation for internal development modes
|
||||
# for all other modes, don't configure as they cannot be used
|
||||
if [ "$my_mode" == "int-developer" ]; then
|
||||
echo "Configuring coredumps"
|
||||
# all subprocesses should generate core dumps
|
||||
ulimit -c unlimited
|
||||
fi
|
||||
}
|
||||
|
||||
check_running() {
|
||||
pgrep -x jibo-system-man >& /dev/null
|
||||
return $?
|
||||
}
|
||||
|
||||
wait_for_stopped() {
|
||||
while check_running; do
|
||||
echo -n "waiting... "
|
||||
sleep 2
|
||||
done
|
||||
}
|
||||
|
||||
start() {
|
||||
echo -n "Starting $PROCESS: "
|
||||
check_mode
|
||||
$BIN_DIR/$PROCESS -c $CFG_DIR/$PROCESS.json --daemon
|
||||
test $? -eq 0 && echo "OK" || echo "ERROR"
|
||||
}
|
||||
|
||||
stop() {
|
||||
echo -n "Stopping $PROCESS: "
|
||||
killall $PROCESS
|
||||
wait_for_stopped
|
||||
test $? -eq 0 && echo "OK" || echo "ERROR"
|
||||
}
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
start
|
||||
;;
|
||||
stop)
|
||||
stop
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start|stop}" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
```
|
||||
|
||||
to bypass the lockout in normal mode we can add like a filter under the normal rules function
|
||||
|
||||
first ima remount with write permissions :
|
||||
|
||||
```shell
|
||||
|
||||
mount -o remount,rw /
|
||||
|
||||
# vi and append :
|
||||
|
||||
normal_rules() {
|
||||
for iptables in $IPTABLES_CMDS; do
|
||||
$iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||||
$iptables -t filter -A INPUT -p icmp -j ACCEPT
|
||||
$iptables -t filter -A INPUT -i lo -j ACCEPT
|
||||
# allow dynamic access rules from system-manager
|
||||
|
||||
|
||||
|
||||
>>> $iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT <<<
|
||||
$iptables -t filter -A INPUT -j DYNAMIC_ACCESS
|
||||
$iptables -t filter -A INPUT -j REJECT
|
||||
$iptables -t filter -A FORWARD -j REJECT
|
||||
done
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
i was gonna use telnetd but its not installed
|
||||
|
||||
anyway using`jibo-getmode` i will revert back to the `normal` mode
|
||||
|
||||
and it works! saving diff for the installer
|
||||
|
||||
now that we have normal mode with ssh we have more capabilities, i will re screw the head back!... i broke my face ring
|
||||
@@ -61,14 +61,11 @@ When Jibo reaches the "Checking for Updates" screen, it isn't "dead." Even while
|
||||
### **Domain Discrepancy**
|
||||
|
||||
- **jibo.com:** Officially shut down; no longer resolves to an active site.
|
||||
- **jibo.net:** Currently active with a "Coming Soon" page. I am monitoring this to see if any hardcoded traffic redirects here.
|
||||
- **jibo.net:** Tribute site made by Community member Jibo-detective or RoboticaLabs on youtube
|
||||
|
||||
---
|
||||
|
||||
## Next Steps for Contributors
|
||||
|
||||
1. **SSL Decryption:** We need to perform a Man-in-the-Middle (MITM) attack using a tool like `mitmproxy` to see the actual content of the HTTPS requests.
|
||||
2. **DNS Poisoning:** Set up a local DNS server (like Pi-hole or a custom BIND server) to redirect `8.8.8.8` calls to a local gateway.
|
||||
3. **Endpoint Mocking:** Create a Python or Flask server to return dummy `200 OK` responses to the AWS IPs to see if Jibo bypasses the update screen.
|
||||
Check out [[Networking & ports & Error codes]] by ZaneDev from discord
|
||||
|
||||
---
|
||||
|
||||
21
Documentation/Networking/Networking & ports & Error codes.md
Normal file
21
Documentation/Networking/Networking & ports & Error codes.md
Normal file
@@ -0,0 +1,21 @@
|
||||
- - -
|
||||
# Useful Ports
|
||||
> [!INFORMATION]
|
||||
> You might not be able to access some ports if you haven't unblocked them on Jibo's firewall.
|
||||
### 8779
|
||||
This port has the skills manager. From here you can do a semi-reboot by stopping and starting the "@be/Be" skill.
|
||||
### 15150
|
||||
This port has logs. This port is only available on v3+ of the revival project (can be checked on the information section in settings).
|
||||
### 10004
|
||||
Error service, allows you to simulate errors in realtime. Shows names of third parties by accident.
|
||||
It seems in recent versions of Jibo errors relating to him not being able to connect to Jibo Inc Servers don't create a pop up L2, L7, Q1 (oddly WIFI4 and WIFI4a still give pop up), Q4. N1-N12 don't have pop ups either. OTA11 and R1 also makes an error inside an error saying "NOT HANDLED BY ERROR SKILL".
|
||||
|
||||
**TL;DR:**
|
||||
|
||||
| Error Code(s) | Shows Popup? | Notes |
|
||||
|---|---|---|
|
||||
| L2, L7, Q1 | No | Server connection errors |
|
||||
| WIFI4, WIFI4a | Yes | |
|
||||
| Q4 | No | |
|
||||
| N1–N12 | No | |
|
||||
| OTA11, R1 | No | Triggers error-within-error: "NOT HANDLED BY ERROR SKILL" |
|
||||
5
Documentation/The be skill/About the be skill.md
Normal file
5
Documentation/The be skill/About the be skill.md
Normal file
@@ -0,0 +1,5 @@
|
||||
- - -
|
||||
The Be skill really is just jibos main menu including his eye and well... menu...
|
||||
anyway i will write about this later but for now here are some references to check out :)
|
||||
|
||||
|
||||
BIN
Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.kra
Normal file
BIN
Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.kra
Normal file
Binary file not shown.
BIN
Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.png
Normal file
BIN
Documentation/The be skill/Assets/Menu Buttons/ButtonSetup.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 133 KiB |
@@ -0,0 +1,5 @@
|
||||
- - -
|
||||
|
||||
Located in `/usr/local/bin/`
|
||||
|
||||
Has a lot of random assets, potentially has assets useful for restoration.
|
||||
5
Documentation/The be skill/Assets/The audio directory.md
Normal file
5
Documentation/The be skill/Assets/The audio directory.md
Normal file
@@ -0,0 +1,5 @@
|
||||
- - -
|
||||
|
||||
Located in `/opt/jibo/Jibo/Skills/@be/be/node_modules/jibo-anim-db-animations/audio/`
|
||||
|
||||
Lots of audio assets, the surrounding folders also contain other assets.
|
||||
7
Documentation/The be skill/The Splash screen image!.md
Normal file
7
Documentation/The be skill/The Splash screen image!.md
Normal file
@@ -0,0 +1,7 @@
|
||||
- - -
|
||||
|
||||
it is located in:
|
||||
|
||||
`/opt/jibo/Jibo/Skills/@be/be/resources/JiboSplash.png`
|
||||
|
||||
This file allows you to edit the splash screen. This is the image that shows at the start of the Be skill (normally the Jibo logo, Jibo Revival logo, OpenJiboOS logo, or some variation). Note: This is only the splash screen for the Be skill. It will only edit the splash seen when you restart "@be/Be", or in the **'second boot stage'** when Jibo spins and shows the splash a second time.
|
||||
16
Documentation/Useful Items List.md
Normal file
16
Documentation/Useful Items List.md
Normal file
@@ -0,0 +1,16 @@
|
||||
Jibo was built a little weird, so it's easy to forget things. This document contains things that are nice to know for tinkering or developing for Jibo Revival.
|
||||
- - -
|
||||
## About [[The Splash screen image!]]
|
||||
|
||||
## About [[The assets directory]]
|
||||
|
||||
## About [[The audio directory]]
|
||||
|
||||
## About [[Networking & ports & Error codes]]
|
||||
|
||||
## About [[Network Profiling & Traffic Analysis]]
|
||||
|
||||
## About [[Local Voice Round-Trip on Jibo (AI Commmunication)]]
|
||||
|
||||
- - -
|
||||
Documented by ZaneDev @ Our Discord
|
||||
@@ -0,0 +1,264 @@
|
||||
# Local ASR, TTS, and Voice Round-Trip on Jibo (Post-Cloud)
|
||||
|
||||
> This document describes the first confirmed working voice interaction on a Jibo robot after official cloud services were discontinued.
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Short version: Jibo can still have a full conversation loop locally.
|
||||
|
||||
We now have:
|
||||
|
||||
* Speech → text (STT) working locally
|
||||
* Text → speech (TTS) working locally
|
||||
* A working loop where Jibo hears something and responds
|
||||
|
||||
This is all happening without the original cloud services.
|
||||
|
||||
---
|
||||
|
||||
## Key Findings
|
||||
|
||||
Here’s what we now know for sure:
|
||||
|
||||
* Wake word detection (`hey jibo`) still works locally
|
||||
* Speaker ID is still running locally (even if it rejects us 😄)
|
||||
* `jibo-asr-service` can be started and controlled manually
|
||||
* ASR (speech recognition) is exposed over HTTP on port `8088`
|
||||
* TTS (speech output) is exposed over HTTP on port `8089`
|
||||
|
||||
### ASR Endpoints
|
||||
|
||||
Confirmed working endpoints:
|
||||
|
||||
* `/asr_simple_interface`
|
||||
* `/audio_source`
|
||||
* `/asr_control`
|
||||
* `/status`
|
||||
|
||||
### WebSocket Outputs
|
||||
|
||||
ASR results are streamed over WebSockets:
|
||||
|
||||
* `ws://<jibo-ip>:8088/port`
|
||||
* `ws://<jibo-ip>:8088/simple_port`
|
||||
|
||||
### Example STT Start Payload
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "start",
|
||||
"task_id": "DEBUG:task3",
|
||||
"audio_source_id": "alsa1",
|
||||
"hotphrase": "none",
|
||||
"speech_to_text": true,
|
||||
"request_id": "stt_start3"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What’s Actually Happening (Architecture)
|
||||
|
||||
Here’s the real flow in plain English:
|
||||
|
||||
1. We send a request to Jibo to start listening
|
||||
2. Jibo captures audio from its mic (ALSA)
|
||||
3. The ASR engine processes it
|
||||
4. Results come back over WebSocket
|
||||
5. Our app reads the transcript
|
||||
6. Our app decides what to say
|
||||
7. We send that to Jibo’s TTS
|
||||
8. Jibo speaks
|
||||
|
||||
Visual version:
|
||||
|
||||
```
|
||||
HTTP POST (/asr_simple_interface)
|
||||
↓
|
||||
ASR service captures audio
|
||||
↓
|
||||
Speech recognition runs locally
|
||||
↓
|
||||
WebSocket emits events
|
||||
↓
|
||||
External app receives transcript
|
||||
↓
|
||||
External logic decides response
|
||||
↓
|
||||
HTTP POST (/tts_speak)
|
||||
↓
|
||||
Jibo talks
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example WebSocket Output
|
||||
|
||||
Here’s a trimmed real example of a final result:
|
||||
|
||||
```json
|
||||
{
|
||||
"event_type": "speech_to_text_final",
|
||||
"task_id": "DEBUG:task3",
|
||||
"utterances": [
|
||||
{
|
||||
"utterance": "what time is it",
|
||||
"score": 975.9
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
You’ll also see:
|
||||
|
||||
* `speech_to_text_incremental` (partial results)
|
||||
* `end_of_speech`
|
||||
* `hotphrase` (for "hey jibo")
|
||||
|
||||
---
|
||||
|
||||
## Demo Flow (How to Reproduce)
|
||||
|
||||
This is the important part.
|
||||
|
||||
### 1. Make sure you are in `int-developer` mode and ASR service is running
|
||||
|
||||
From ssh:
|
||||
|
||||
```
|
||||
/usr/local/bin/jibo-asr-service -c /usr/local/etc/jibo-asr-service.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Connect to WebSocket
|
||||
|
||||
```
|
||||
ws://<jibo-ip>:8088/simple_port
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Start an STT task
|
||||
|
||||
POST to:
|
||||
|
||||
```
|
||||
http://<jibo-ip>:8088/asr_simple_interface
|
||||
```
|
||||
|
||||
With:
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "start",
|
||||
"task_id": "DEBUG:task3",
|
||||
"audio_source_id": "alsa1",
|
||||
"hotphrase": "none",
|
||||
"speech_to_text": true
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. Speak to Jibo
|
||||
|
||||
Say something like:
|
||||
|
||||
> “what time is it”
|
||||
|
||||
---
|
||||
|
||||
### 5. Wait for final transcript
|
||||
|
||||
Watch for:
|
||||
|
||||
```
|
||||
event_type: speech_to_text_final
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. Send response to TTS
|
||||
|
||||
POST to:
|
||||
|
||||
```
|
||||
http://<jibo-ip>:8089/tts_speak
|
||||
```
|
||||
|
||||
With something like:
|
||||
|
||||
```json
|
||||
{
|
||||
"text": "It is demo time."
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. Jibo speaks 🎉
|
||||
|
||||
---
|
||||
|
||||
## Known Behaviors / Quirks
|
||||
|
||||
Some things we’ve seen so far:
|
||||
|
||||
* WebSocket connections can drop → reconnect logic helps
|
||||
* Incremental results can be messy or duplicated
|
||||
* Multiple transcript guesses can show up
|
||||
* Wake word (`task0`) runs alongside your custom task
|
||||
* Saying “hey jibo” during a manual STT session can interfere
|
||||
* Speaker ID often rejects (but doesn’t block STT)
|
||||
|
||||
---
|
||||
|
||||
## Corrections to Previous Assumptions
|
||||
|
||||
Some things we (and others) thought before that are now clearly wrong or incomplete:
|
||||
|
||||
* “ASR is dead without cloud” → **Not true in developer mode**
|
||||
* “Only wake word works locally” → **Incomplete**
|
||||
* “No way to get transcripts” → **False (WebSocket output exists)**
|
||||
* “Jibo can’t answer questions anymore” → **Also false now 🙂**
|
||||
|
||||
---
|
||||
|
||||
## What This Means
|
||||
|
||||
This is a big deal:
|
||||
|
||||
* Jibo’s core voice pipeline is still there
|
||||
* The cloud was orchestration, not the whole system
|
||||
* We can now rebuild the “brain” externally
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
Where this naturally goes next:
|
||||
|
||||
* Hook wake word → automatically trigger STT
|
||||
* Figure out how this behaves in “normal mode”
|
||||
* See if Jibo tries to initiate outbound connections (old cloud flow)
|
||||
* Intercept or replace those endpoints locally
|
||||
* Build a simple always-on bridge service:
|
||||
|
||||
* Wake word → STT → AI → TTS
|
||||
|
||||
---
|
||||
|
||||
## Final Thought
|
||||
|
||||
We didn’t just poke at endpoints here.
|
||||
|
||||
We proved Jibo can:
|
||||
|
||||
* hear
|
||||
* understand
|
||||
* and respond again
|
||||
|
||||
That’s a pretty great place to be.
|
||||
@@ -21,6 +21,12 @@ Before starting ANY work , lets get you up to speed with the enviroment and what
|
||||
5. An the mindset of (everything will be fine!)
|
||||
|
||||
- - -
|
||||
|
||||
>[!DANGER]
|
||||
> # Part 0 | Note your jibos IP Down
|
||||
> Make sure you have your jibos IP adress , so you wont have to redo 4 hours of flashing just because you forgot your ip
|
||||
|
||||
- - -
|
||||
# Part 1 | Connecting your jibo
|
||||
|
||||
So first , go ahead and plug jibo in to your host device that you are going to dump the firmware into using your usb cable
|
||||
|
||||
14
Jibo Tools & Mod Installer/00 - Index.md
Normal file
14
Jibo Tools & Mod Installer/00 - Index.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# JiboAutoModv2
|
||||
This folder contains internal documentation for how this repo works.
|
||||
|
||||
## Start here
|
||||
|
||||
- [[01 - Installer (How It Works)]]
|
||||
- [[02 - Mapping to guide]]
|
||||
- [[03 - CLI Arguments]]
|
||||
- [[04 - GUI (How It Works)]]
|
||||
- [[05 - Windows Support]]
|
||||
- [[06 - Updater (How It Works)]]
|
||||
- [[07 - Working Directory + State Files]]
|
||||
- [[08 - Troubleshooting]]
|
||||
|
||||
88
Jibo Tools & Mod Installer/01 - Installer (How It Works).md
Normal file
88
Jibo Tools & Mod Installer/01 - Installer (How It Works).md
Normal file
@@ -0,0 +1,88 @@
|
||||
# Installer (How It Works)
|
||||
|
||||
The repo has a “CLI installer” and an optional GUI wrapper that launches the same Python tools.
|
||||
|
||||
The basic mod logic lives in `../jibo_automod.py`
|
||||
|
||||
## What the installer actually does
|
||||
|
||||
The tool is automating the exact same high-level steps you do manually in [[1. Get your environment ready!]]
|
||||
|
||||
1. Build ShofEL (`shofel2_t124`) if it isn’t built yet.
|
||||
2. Put the Jibo into NVIDIA Tegra RCM mode (USB device `0955:7740`).
|
||||
3. Read eMMC contents using `EMMC_READ`.
|
||||
4. Find the `/var` partition (usually GPT partition #5, ~500MB).
|
||||
5. Modify `/var/jibo/mode.json` from `normal` to `int-developer`.
|
||||
6. Write the modified `/var` partition back using `EMMC_WRITE`.
|
||||
7. Optionally verify by reading back and comparing hashes.
|
||||
|
||||
After that, Jibo boots to a checkmark and SSH should work:
|
||||
|
||||
- `ssh root@<jibo-ip>`
|
||||
- password: `jibo`
|
||||
|
||||
## Launchers (what runs what)
|
||||
|
||||
### Linux launcher
|
||||
|
||||
- `../jibo_automod.sh` is a Bash launcher
|
||||
- It does a light dependency check, then prompts:
|
||||
- CLI installer (recommended)
|
||||
- GUI installer (experimental)
|
||||
|
||||
In CLI mode it runs:
|
||||
|
||||
- `python3 ../jibo_automod.py <args>`
|
||||
|
||||
In GUI mode it:
|
||||
|
||||
- creates `../.venv/` if missing
|
||||
- installs GUI deps from `../JiboTools/JiboTools/requirements.txt`
|
||||
- launches `../JiboTools/JiboTools/main_panel.py`
|
||||
|
||||
### Windows launcher
|
||||
|
||||
- `../jibo_automod.bat` just runs `python ../jibo_automod.py <args>`
|
||||
- It warns if you’re not running as Administrator.
|
||||
|
||||
## How it edits mode.json (important detail)
|
||||
|
||||
`../jibo_automod.py` tries multiple strategies to edit `mode.json` inside the `/var` filesystem image:
|
||||
|
||||
1. **Linux mount (preferred on Linux)**
|
||||
- Mounts `var_partition.bin` as a loop device.
|
||||
- Edits `jibo/mode.json` (or a couple fallback paths).
|
||||
- Unmounts.
|
||||
|
||||
2. **debugfs (preferred for Windows if available)**
|
||||
- Uses `debugfs` from `e2fsprogs` to read and rewrite the file inside the ext filesystem image without mounting.
|
||||
- This is the safest option on Windows if you can install it (see [[05 - Windows Support]]).
|
||||
|
||||
3. **Raw in-place patch (last resort)**
|
||||
- Searches the binary image for known JSON string patterns like `{"mode": "normal"}`.
|
||||
- Overwrites bytes in-place without changing file size.
|
||||
- **If the replacement would require growing the data and there is no safe padding, it refuses.**
|
||||
|
||||
>[!note]
|
||||
Because this is a real filesystem image, the mount/debugfs approaches are more reliable than raw patching.
|
||||
|
||||
## Installer modes
|
||||
|
||||
The CLI tool supports three main workflows:
|
||||
|
||||
- **Full mod** (default): full eMMC dump, then extract/modify/write `/var`.
|
||||
- **Dump-only**: only dumps eMMC (no modifications).
|
||||
- **Mode-json-only** (“fast mode”): reads only GPT + `/var` and patch-writes only changed sectors.
|
||||
|
||||
Details and flags: [[03 - CLI Arguments]]
|
||||
|
||||
## Where output goes
|
||||
|
||||
By default, the tool uses `../jibo_work/` for working files:
|
||||
|
||||
- `jibo_full_dump.bin` (full mode)
|
||||
- `gpt_dump.bin` (fast mode)
|
||||
- `var_partition_original.bin` / `var_partition.bin`
|
||||
- backups, verification reads, and patch chunks
|
||||
|
||||
More: [[07 - Working Directory + State Files]]
|
||||
104
Jibo Tools & Mod Installer/02 - Mapping to guide.md
Normal file
104
Jibo Tools & Mod Installer/02 - Mapping to guide.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Mapping to guide.md
|
||||
|
||||
This page explains how the automated installer in `../jibo_automod.py` relates to the manual steps in `../guide.md`.
|
||||
|
||||
## Big picture
|
||||
|
||||
`../guide.md` is the “do it by hand” method.
|
||||
|
||||
`../jibo_automod.py` is the “do the same steps, but scripted” method.
|
||||
|
||||
If something goes wrong in automation, the guide is still valuable because it explains:
|
||||
|
||||
- how to confirm RCM mode
|
||||
- how to interpret partition layouts
|
||||
- what `/var/jibo/mode.json` does conceptually
|
||||
|
||||
## Step-by-step mapping
|
||||
|
||||
### Part 1 (Connecting / RCM)
|
||||
|
||||
Guide:
|
||||
- Enter RCM mode and confirm with `lsusb` showing NVIDIA APX (`0955:7740`).
|
||||
|
||||
Tool:
|
||||
- `detect_jibo_rcm()` tries `lsusb` on Linux.
|
||||
- Falls back to scanning `/sys/bus/usb/devices` if `lsusb` is missing.
|
||||
- On Windows it can’t reliably detect in the same way, so it prints guidance and proceeds.
|
||||
|
||||
Related: [[05 - Windows Support]]
|
||||
|
||||
### Part 2 (Build ShofEL)
|
||||
|
||||
Guide:
|
||||
- Clone/build ShofEL manually with `make`.
|
||||
|
||||
Tool:
|
||||
- `build_shofel()` runs `make` inside `../Shofel/`.
|
||||
- If payload `.bin` files are missing, it requires the ARM toolchain (`arm-none-eabi-gcc`).
|
||||
|
||||
### Part 3 (Dump eMMC)
|
||||
|
||||
Guide:
|
||||
- Run: `shofel2_t124 EMMC_READ 0x0 0x1D60000 full_jibo_dump.bin`
|
||||
|
||||
Tool:
|
||||
- Default full workflow calls `dump_emmc()` which runs the same command.
|
||||
- Fast workflow (`--mode-json-only`) does *not* dump full eMMC; it only reads GPT + `/var`.
|
||||
|
||||
### Part 4 (Identify and extract /var)
|
||||
|
||||
Guide:
|
||||
- Run `fdisk -l dump.bin`
|
||||
- Find partition 5, compute start/count, then `dd` out `var_partition.bin`.
|
||||
|
||||
Tool:
|
||||
- Parses GPT directly (`parse_gpt_partitions()`), with an `fdisk` fallback on Linux.
|
||||
- Then extracts bytes by seeking directly inside the dump (no `dd` needed).
|
||||
- Uses heuristics to identify `/var` (partition #5 and roughly 400–600MB).
|
||||
|
||||
### Part 4.2 (Edit mode.json)
|
||||
|
||||
Guide:
|
||||
- Mount loop device and edit `jibo/mode.json`.
|
||||
|
||||
Tool:
|
||||
- On Linux: prefers a loop mount and edits `mode.json`.
|
||||
- On Windows: prefers `debugfs` if installed.
|
||||
- Raw in-place patch is last resort.
|
||||
|
||||
Related: [[01 - Installer (How It Works)]]
|
||||
|
||||
### Part 5 (Write /var back)
|
||||
|
||||
Guide:
|
||||
- Convert start sector to hex and run `EMMC_WRITE <start> var_partition.bin`.
|
||||
|
||||
Tool:
|
||||
- Always uses the GPT-derived start sector (so you don’t manually convert it).
|
||||
- In fast mode, it can patch-write only changed sectors instead of writing the full 500MB.
|
||||
|
||||
### Part 6 (Verify)
|
||||
|
||||
Guide:
|
||||
- Read back and compare hashes.
|
||||
|
||||
Tool:
|
||||
- Optional verify step reads back the written range and compares MD5.
|
||||
|
||||
## Why the automated tool differs from the guide
|
||||
|
||||
The guide is intentionally explicit and teaches the mental model.
|
||||
|
||||
The tool tries to reduce “math + manual disk ops” by:
|
||||
|
||||
- parsing GPT automatically
|
||||
- extracting partitions programmatically
|
||||
- handling mount/debugfs edits
|
||||
- optionally patch-writing only changed sectors
|
||||
|
||||
## When to fall back to the guide
|
||||
|
||||
- If your partition layout differs enough that `/var` isn’t partition 5.
|
||||
- If the filesystem inside `/var` is corrupted and mount/debugfs can’t read it.
|
||||
- If you want a full backup regardless of speed (the guide defaults to full dump).
|
||||
147
Jibo Tools & Mod Installer/03 - CLI Arguments.md
Normal file
147
Jibo Tools & Mod Installer/03 - CLI Arguments.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# CLI Arguments
|
||||
|
||||
This page documents the CLI flags for the two main tools:
|
||||
|
||||
- `../jibo_automod.py` (installer/mod tool)
|
||||
- `../jibo_updater.py` (OS updater)
|
||||
|
||||
If you’re using launchers (`.sh`/`.bat`), they forward all arguments through.
|
||||
|
||||
## jibo_automod.py
|
||||
|
||||
### Modes (mutually exclusive)
|
||||
|
||||
- (no mode flag)
|
||||
- Full mod workflow (full eMMC dump, extract/modify/write `/var`).
|
||||
|
||||
- `--dump-only`
|
||||
- Only dump eMMC; don’t modify anything.
|
||||
|
||||
- `--write-partition FILE`
|
||||
- Write an already-prepared partition image to eMMC.
|
||||
- You must tell it where to write using `--start-sector`.
|
||||
|
||||
- `--mode-json-only`
|
||||
- Fast path:
|
||||
1) read GPT (small)
|
||||
2) read `/var` only (~500MB)
|
||||
3) modify `/var/jibo/mode.json`
|
||||
4) write back either a patch (default) or full `/var`
|
||||
|
||||
### Common options
|
||||
|
||||
- `--dump-path FILE`
|
||||
- Use an existing dump file instead of reading from the device.
|
||||
|
||||
- `--output FILE` / `-o FILE`
|
||||
- Output file for dumps.
|
||||
|
||||
- `--start-sector HEX`
|
||||
- Start sector for `--write-partition`.
|
||||
- Parsed with base autodetect (`0x...` works).
|
||||
- Default is `0x7E9022` (but the full/fast workflows usually compute the start sector from GPT).
|
||||
|
||||
- `--force-dump`
|
||||
- Re-dump even if a dump exists.
|
||||
|
||||
- `--rebuild-shofel`
|
||||
- Force rebuilding ShofEL (`make clean` then `make`).
|
||||
|
||||
- `--skip-detection`
|
||||
- Skip USB “is Jibo connected” checks.
|
||||
|
||||
- `--no-verify`
|
||||
- Skip verification read-back.
|
||||
|
||||
### Fast mode options
|
||||
|
||||
- `--full-var-write`
|
||||
- Only meaningful with `--mode-json-only`.
|
||||
- If set: write the full `/var` partition back (slower).
|
||||
- If not set: compute sector diffs and only write changed ranges (faster).
|
||||
|
||||
### Examples
|
||||
|
||||
- Full mod:
|
||||
- `python3 jibo_automod.py`
|
||||
|
||||
- Dump only:
|
||||
- `python3 jibo_automod.py --dump-only -o my_dump.bin`
|
||||
|
||||
- Use existing dump:
|
||||
- `python3 jibo_automod.py --dump-path jibo_work/jibo_full_dump.bin`
|
||||
|
||||
- Fast mode:
|
||||
- `python3 jibo_automod.py --mode-json-only`
|
||||
|
||||
- Write a prepared partition:
|
||||
- `python3 jibo_automod.py --write-partition var_partition.bin --start-sector 0x7E9022`
|
||||
|
||||
## jibo_updater.py
|
||||
|
||||
The updater assumes you already have SSH access to the robot.
|
||||
|
||||
### Required
|
||||
|
||||
- `--ip <host>` (alias: `--host`)
|
||||
- IP or hostname of your Jibo.
|
||||
|
||||
### Connection
|
||||
|
||||
- `--user <name>` (default `root`)
|
||||
- `--password <pass>` (default `jibo`)
|
||||
- `--ssh-timeout <seconds>` (default `15`)
|
||||
|
||||
### Release selection
|
||||
|
||||
- `--releases-api <url>`
|
||||
- API endpoint for Gitea releases.
|
||||
|
||||
- `--stable`
|
||||
- Ignore prereleases.
|
||||
|
||||
- `--tag <tag>`
|
||||
- Install a specific tag instead of “latest”.
|
||||
|
||||
### Archive layout
|
||||
|
||||
- `--build-path <relative/path>`
|
||||
- If the updater can’t find the `build/` folder automatically, specify where it is inside the extracted archive.
|
||||
|
||||
### Safety / UX
|
||||
|
||||
- `--state-file <path>`
|
||||
- Where it remembers the last applied version per host.
|
||||
|
||||
- `--force`
|
||||
- Re-download and re-install even if the local state says you’re already on that version.
|
||||
|
||||
- `--yes`
|
||||
- Don’t prompt for confirmation.
|
||||
|
||||
- `--dry-run`
|
||||
- Download/extract + connect, but don’t upload files and don’t touch mode.json.
|
||||
|
||||
### Returning to normal mode
|
||||
|
||||
- `--return-normal`
|
||||
- After update, set `/var/jibo/mode.json` back to `normal` (no prompt).
|
||||
|
||||
- `--no-return-normal`
|
||||
- Never prompt and never change mode back.
|
||||
|
||||
### Examples
|
||||
|
||||
- Update to latest:
|
||||
- `python3 jibo_updater.py --ip 192.168.1.50`
|
||||
|
||||
- Stable only:
|
||||
- `python3 jibo_updater.py --ip 192.168.1.50 --stable`
|
||||
|
||||
- Specific tag:
|
||||
- `python3 jibo_updater.py --ip 192.168.1.50 --tag v3.3.0`
|
||||
|
||||
- Dry run:
|
||||
- `python3 jibo_updater.py --ip 192.168.1.50 --dry-run`
|
||||
|
||||
More detail: [[06 - Updater (How It Works)]]
|
||||
100
Jibo Tools & Mod Installer/04 - GUI (How It Works).md
Normal file
100
Jibo Tools & Mod Installer/04 - GUI (How It Works).md
Normal file
@@ -0,0 +1,100 @@
|
||||
# GUI (How It Works)
|
||||
|
||||
The GUI is an optional Qt (PySide6) front-end.
|
||||
|
||||
>[!Important]
|
||||
the GUI does **not** re-implement the mod/updater logic; it mostly launches the same Python scripts and shows their logs.
|
||||
|
||||
- - -
|
||||
|
||||
|
||||
![[JiboToolsScreen.png]]
|
||||
|
||||
- - -
|
||||
## Entry points
|
||||
|
||||
- Linux launcher: `../jibo_gui.sh`
|
||||
- Windows launcher: `../jibo_gui.bat`
|
||||
|
||||
The GUI module it runs is:
|
||||
|
||||
- `python -m gui.main_panel`
|
||||
|
||||
The implementation is in:
|
||||
|
||||
- `../JiboTools/JiboTools/gui/main_panel.py`
|
||||
|
||||
## Main Panel overview
|
||||
|
||||
The main panel UI (`form.ui`) is loaded at runtime (Qt Widgets, not QML):
|
||||
|
||||
- `../JiboTools/JiboTools/form.ui`
|
||||
|
||||
`MainWindowController` wires up widgets and behavior:
|
||||
|
||||
- “Connect” button opens an SSH session to the robot using Paramiko.
|
||||
- It reads `/var/jibo/identity.json` to display the robot name.
|
||||
- The panel includes toggles/fields for Home Assistant and AI settings (currently UI-only wiring; the panel mainly focuses on connection + launching tools).
|
||||
|
||||
### Connection behavior
|
||||
|
||||
- Host/IP comes from the UI field.
|
||||
- Credentials are currently fixed to `root` / `jibo` in the panel code.
|
||||
- UI shows a status dot and swaps images based on connection state.
|
||||
|
||||
## Tool runner windows (Installer / Updater)
|
||||
|
||||
When you click installer/updater from the panel, it spawns a separate “Tool Runner” window:
|
||||
|
||||
- Installer: runs `jibo_automod.py`
|
||||
- Updater: runs `jibo_updater.py`
|
||||
|
||||
The common implementation is:
|
||||
|
||||
- `../JiboTools/JiboTools/gui/tool_runner_window.py`
|
||||
|
||||
### How the tool runner executes scripts
|
||||
|
||||
- Uses `QProcess` (see `ProcessRunner`) to run a Python process.
|
||||
- Captures merged stdout/stderr and appends it into a log view.
|
||||
- Has a Start/Stop button (Stop terminates then kills if needed).
|
||||
|
||||
It resolves which Python to use with:
|
||||
|
||||
- `resolve_python_invocation()` in `../JiboTools/JiboTools/gui/process_runner.py`
|
||||
|
||||
Resolution order (simplified):
|
||||
|
||||
1. Use repo-local `../.venv/` Python if present.
|
||||
2. Otherwise use the current interpreter (useful if launched from Qt Creator).
|
||||
3. Windows fallback: `py -3`.
|
||||
4. Linux fallback: `python3`, then `python`.
|
||||
|
||||
### Passing arguments
|
||||
|
||||
- The tool runner has an “Extra args” textbox.
|
||||
- For the updater runner specifically, it also has a host field that becomes `--ip <host>`.
|
||||
|
||||
This means the GUI is effectively a thin wrapper over the CLI flags described in [[03 - CLI Arguments]].
|
||||
|
||||
### “Open in terminal”
|
||||
|
||||
The tool runner can try to spawn an external terminal window with the exact command line it would run.
|
||||
|
||||
- Linux: tries `x-terminal-emulator`, `gnome-terminal`, `konsole`, etc.
|
||||
- Windows: uses `cmd.exe`.
|
||||
|
||||
## Dependencies
|
||||
|
||||
GUI deps live in:
|
||||
|
||||
- `../requirements-gui.txt` (PySide6)
|
||||
- `../JiboTools/JiboTools/requirements.txt` (PySide6 + Paramiko)
|
||||
|
||||
The CLI installer launcher `../jibo_automod.sh` also auto-creates `../.venv/` and installs `../JiboTools/JiboTools/requirements.txt` if you pick GUI mode.
|
||||
|
||||
## Practical notes / limitations
|
||||
|
||||
- The GUI is great for convenience, but debugging is often easier from CLI because you can see exactly what flags are being passed.
|
||||
- The installer still requires RCM mode + USB access; the GUI does not remove that requirement.
|
||||
- The updater requires SSH access (meaning: you must already be in developer mode / checkmark boot).
|
||||
83
Jibo Tools & Mod Installer/05 - Windows Support.md
Normal file
83
Jibo Tools & Mod Installer/05 - Windows Support.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Windows Support
|
||||
|
||||
This repo supports Windows, but there are two separate “Windows” stories:
|
||||
|
||||
1. **Running the Python scripts on Windows** (launchers: `.bat`)
|
||||
2. **Actually talking to the Jibo over USB in RCM mode** (drivers + build tools)
|
||||
|
||||
The USB/RCM part is the trickiest.
|
||||
|
||||
## Launchers
|
||||
|
||||
- Installer: `../jibo_automod.bat`
|
||||
- Runs `python ../jibo_automod.py %*`
|
||||
- Warns if not Administrator.
|
||||
|
||||
- Updater: `../jibo_updater.bat`
|
||||
- Prefers `../.venv/` Python if present.
|
||||
- Else prefers `py -3`.
|
||||
|
||||
- GUI: `../jibo_gui.bat`
|
||||
- Same Python resolution approach.
|
||||
|
||||
## Environment setup helper
|
||||
|
||||
- `../windows_setup.bat` helps install dependencies via MSYS2 and explains Zadig.
|
||||
|
||||
It installs (via MSYS2):
|
||||
|
||||
- MinGW gcc/make
|
||||
- libusb
|
||||
- ARM toolchain (`arm-none-eabi-gcc`) for payload builds
|
||||
|
||||
## USB driver requirement (RCM mode)
|
||||
|
||||
When Jibo is in RCM mode it enumerates as NVIDIA APX (`0955:7740`).
|
||||
|
||||
On Windows you typically need to replace its driver with WinUSB:
|
||||
|
||||
- Use Zadig and install WinUSB for the “APX” device.
|
||||
|
||||
Without this, ShofEL won’t be able to talk to the device.
|
||||
|
||||
## Editing mode.json on Windows
|
||||
|
||||
Linux can mount the ext filesystem image and edit `/var/jibo/mode.json` normally.
|
||||
|
||||
Windows usually can’t mount the ext image easily, so `../jibo_automod.py` tries alternative methods:
|
||||
|
||||
1. **debugfs (recommended)**
|
||||
- If `debugfs.exe` is available on PATH, the tool can edit the file inside the ext filesystem image safely.
|
||||
- Install via MSYS2:
|
||||
- `pacman -S --needed e2fsprogs`
|
||||
|
||||
2. **Raw in-place patch (last resort)**
|
||||
- The tool searches the partition image bytes for JSON patterns and overwrites them without changing length.
|
||||
- This can fail if the on-disk JSON format differs or if there’s no safe padding space.
|
||||
|
||||
If you’re on Windows and you’re seeing warnings about raw edits or the tool can’t find patterns, installing `debugfs` is the best fix.
|
||||
|
||||
## WSL option
|
||||
|
||||
Another workable approach is to use WSL2 and follow the Linux path.
|
||||
|
||||
Caveat: you still need USB passthrough into WSL (which can be non-trivial depending on your setup).
|
||||
|
||||
## Common Windows failure modes
|
||||
|
||||
- Device not detected / can’t open USB:
|
||||
- Wrong driver (use Zadig -> WinUSB)
|
||||
- Not Administrator
|
||||
- Cable is charge-only
|
||||
|
||||
- Build failures:
|
||||
- Missing MSYS2 packages
|
||||
- ARM toolchain missing (payload `.bin` files won’t build)
|
||||
|
||||
- mode.json edit failures:
|
||||
- Install `e2fsprogs` and ensure `debugfs` is on PATH
|
||||
|
||||
## Related docs
|
||||
|
||||
- Installer workflow: [[01 - Installer (How It Works)]]
|
||||
- CLI flags: [[03 - CLI Arguments]]
|
||||
79
Jibo Tools & Mod Installer/06 - Updater (How It Works).md
Normal file
79
Jibo Tools & Mod Installer/06 - Updater (How It Works).md
Normal file
@@ -0,0 +1,79 @@
|
||||
# Updater (How It Works)
|
||||
|
||||
The updater is a separate tool from the installer.
|
||||
|
||||
- Installer: puts Jibo into developer mode by editing `/var/jibo/mode.json` via RCM + eMMC writes.
|
||||
- Updater: once you have SSH access, it downloads a JiboOs release and uploads a rootfs overlay to the robot over SFTP.
|
||||
|
||||
Implementation: `../jibo_updater.py`
|
||||
|
||||
## High-level flow
|
||||
|
||||
1. Query the releases API (Gitea JSON) and pick a release:
|
||||
- latest (default)
|
||||
- stable-only (`--stable`)
|
||||
- specific tag (`--tag`)
|
||||
|
||||
2. Download the chosen release archive.
|
||||
|
||||
3. Extract it safely (checks for path traversal in archives).
|
||||
|
||||
4. Find the `build/` folder inside the extracted tree.
|
||||
- You can override with `--build-path`.
|
||||
|
||||
5. SSH into the Jibo using Paramiko.
|
||||
|
||||
6. Ensure `/` is writable:
|
||||
- tests with a `touch` on `/.jibo_rw_test`
|
||||
- if needed, runs `mount -o remount,rw /`
|
||||
|
||||
7. Upload the contents of `build/` into `/` using SFTP.
|
||||
- Directories are created as needed.
|
||||
- Files are uploaded and chmod is best-effort preserved.
|
||||
- Symlinks are uploaded as symlinks if possible; otherwise it uploads dereferenced content.
|
||||
|
||||
8. Optionally return Jibo to normal mode by changing `/var/jibo/mode.json` back to `normal`.
|
||||
|
||||
9. Record the applied tag in a local state file so repeated runs can short-circuit.
|
||||
|
||||
## What “build/” means
|
||||
|
||||
Releases are expected to contain a “rootfs overlay” folder named `build/`.
|
||||
|
||||
That directory typically includes paths like:
|
||||
|
||||
- `etc/`
|
||||
- `opt/`
|
||||
- `usr/`
|
||||
- `var/`
|
||||
|
||||
The updater essentially copies those files to the same locations on the robot.
|
||||
|
||||
## State file
|
||||
|
||||
By default, the updater stores last-applied tag per host in:
|
||||
|
||||
- `../jibo_work/update_state.json`
|
||||
|
||||
If the state file says the host already has the latest tag, it exits unless you pass `--force`.
|
||||
|
||||
More: [[07 - Working Directory + State Files]]
|
||||
|
||||
## Safety knobs
|
||||
|
||||
- It prompts before upload unless `--yes` is passed.
|
||||
- `--dry-run` downloads/extracts and connects, but does not upload or edit mode.json.
|
||||
|
||||
## Returning to normal mode
|
||||
|
||||
At the end, the updater can switch the robot back to normal mode:
|
||||
|
||||
- `--return-normal` (force it)
|
||||
- `--no-return-normal` (never prompt / never change)
|
||||
- otherwise it prompts (unless `--yes` is passed)
|
||||
|
||||
Note: returning to normal mode can disable the “checkmark/dev” behavior depending on how JiboOs uses `mode.json`.
|
||||
|
||||
## CLI reference
|
||||
|
||||
See [[03 - CLI Arguments]] for the complete list and examples.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Working Directory + State Files
|
||||
|
||||
Both the installer and updater use `../jibo_work/` as their “scratch + cache” directory.
|
||||
|
||||
This is helpful for:
|
||||
|
||||
- keeping your large dumps out of the repo root
|
||||
- making it obvious what can be deleted vs what is precious
|
||||
|
||||
## jibo_automod.py outputs
|
||||
|
||||
Depending on mode, you may see:
|
||||
|
||||
- `jibo_full_dump.bin`
|
||||
- The full eMMC dump (~15GB). Created by full workflow.
|
||||
|
||||
- `gpt_dump.bin`
|
||||
- Small dump (default 4096 sectors / ~2MB) used by `--mode-json-only`.
|
||||
|
||||
- `var_partition_original.bin`
|
||||
- Original `/var` read from the robot (fast mode).
|
||||
|
||||
- `var_partition.bin`
|
||||
- Working copy that gets modified.
|
||||
|
||||
- `var_partition_backup.bin`
|
||||
- Backup copy made before modifications.
|
||||
|
||||
- `verify_partition.bin`
|
||||
- Read-back buffer used during verification.
|
||||
|
||||
- `var_patch_###.bin`
|
||||
- Patch chunks produced by sector-diff patch-writing in fast mode.
|
||||
|
||||
- `mode.json.original` / `mode.json.modified`
|
||||
- Best-effort debug copies of the JSON before/after editing.
|
||||
|
||||
### What you should keep
|
||||
|
||||
- Keep `var_partition_backup.bin` somewhere safe.
|
||||
- If you made a full dump, consider archiving `jibo_full_dump.bin` (space permitting).
|
||||
|
||||
## jibo_updater.py outputs
|
||||
|
||||
The updater uses:
|
||||
|
||||
- `../jibo_work/updates/`
|
||||
- `downloads/` cached archives
|
||||
- `extracted/` extracted trees
|
||||
|
||||
And it tracks state in:
|
||||
|
||||
- `../jibo_work/update_state.json`
|
||||
|
||||
That file maps host -> last applied tag.
|
||||
|
||||
## Cleaning up
|
||||
|
||||
- Safe-ish to delete: extracted archives and patch chunks (you can always re-download / re-create).
|
||||
- Be careful deleting: backups and any full dump you still care about.
|
||||
|
||||
## Related docs
|
||||
|
||||
- Installer overview: [[01 - Installer (How It Works)]]
|
||||
- Updater overview: [[06 - Updater (How It Works)]]
|
||||
184
Jibo Tools & Mod Installer/08 - Troubleshooting.md
Normal file
184
Jibo Tools & Mod Installer/08 - Troubleshooting.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# Troubleshooting
|
||||
|
||||
This page is a practical checklist for common failure points.
|
||||
|
||||
If something fails, also see:
|
||||
|
||||
- Installer internals: [[01 - Installer (How It Works)]]
|
||||
- Windows specifics: [[05 - Windows Support]]
|
||||
- CLI flags: [[03 - CLI Arguments]]
|
||||
- Updater internals: [[06 - Updater (How It Works)]]
|
||||
|
||||
---
|
||||
|
||||
## 1) Jibo not found / can’t talk to APX (RCM)
|
||||
|
||||
### Symptoms
|
||||
|
||||
- Tool prints “Jibo not found in RCM mode”
|
||||
- `EMMC_READ` / `EMMC_WRITE` fails immediately
|
||||
- On Linux, `lsusb` does not show `0955:7740`
|
||||
|
||||
### Checklist
|
||||
|
||||
- Use a known-good **data** micro-USB cable (charge-only cables are common).
|
||||
- Ensure the robot is actually in RCM:
|
||||
- hold RCM button
|
||||
- press reset/power
|
||||
- release when you get red LED and no normal boot
|
||||
- Try a different USB port (avoid hubs).
|
||||
|
||||
### Linux permissions
|
||||
|
||||
- If it works only with `sudo`, consider installing the udev rule:
|
||||
- see `../99-jibo-rcm.rules`
|
||||
|
||||
### Windows driver
|
||||
|
||||
- Install WinUSB for the “APX” device using Zadig.
|
||||
- Run the tool as Administrator.
|
||||
|
||||
---
|
||||
|
||||
## 2) ShofEL build issues
|
||||
|
||||
### Symptoms
|
||||
|
||||
- `make` fails in `../Shofel/`
|
||||
- Tool complains about missing payload binaries (like `emmc_server.bin`)
|
||||
|
||||
### Checklist
|
||||
|
||||
- You need normal build tools: `gcc`, `make`, libusb dev headers.
|
||||
- If payload `.bin` files are missing you also need the ARM toolchain:
|
||||
- `arm-none-eabi-gcc`
|
||||
|
||||
Notes:
|
||||
|
||||
- The tool’s `--rebuild-shofel` forces a rebuild.
|
||||
|
||||
---
|
||||
|
||||
## 3) Dump is slow / crashes near the end
|
||||
|
||||
### Full dump mode
|
||||
|
||||
- Full dump reads ~15GB; multi-hour runtime is normal.
|
||||
- If it fails at ~99%, you often still have most of the content.
|
||||
|
||||
### Use fast mode instead
|
||||
|
||||
If your only goal is enabling SSH/dev mode, you can usually skip the full dump:
|
||||
|
||||
- `--mode-json-only`
|
||||
|
||||
This reads only GPT + `/var` (~500MB) and writes back only what changed.
|
||||
|
||||
---
|
||||
|
||||
## 4) mode.json edit fails
|
||||
|
||||
### Why this happens
|
||||
|
||||
`/var` is an ext filesystem image. Editing a file *inside* it is easiest on Linux (mount) and harder on Windows.
|
||||
|
||||
### What the installer tries (in order)
|
||||
|
||||
- Linux: mount loop device and edit `/var/jibo/mode.json`
|
||||
- Any OS: try `debugfs` if installed
|
||||
- Fallback: raw byte-pattern overwrite
|
||||
|
||||
### Fixes
|
||||
|
||||
- On Windows, install `debugfs` via MSYS2:
|
||||
- package: `e2fsprogs`
|
||||
- If raw patching fails:
|
||||
- it likely can’t find the exact JSON string pattern, or it would need to grow the data region.
|
||||
- installing `debugfs` is usually the right fix.
|
||||
|
||||
---
|
||||
|
||||
## 5) Fast mode patch-write writes too much (or falls back)
|
||||
|
||||
### What patch-write is
|
||||
|
||||
In `--mode-json-only` the tool tries to compute which 512-byte sectors changed between:
|
||||
|
||||
- `var_partition_original.bin`
|
||||
- `var_partition.bin`
|
||||
|
||||
Then it writes only those sector ranges.
|
||||
|
||||
### When it falls back to full `/var` write
|
||||
|
||||
It will write the entire partition if:
|
||||
|
||||
- the images differ in size (shouldn’t happen in normal flows)
|
||||
- too many sectors changed
|
||||
- too many disjoint ranges were detected
|
||||
|
||||
If your edit method rewrites a lot of blocks (filesystem reallocation), you may see a full write anyway.
|
||||
|
||||
To force full write explicitly:
|
||||
|
||||
- `--full-var-write`
|
||||
|
||||
---
|
||||
|
||||
## 6) Verify step fails (hash mismatch)
|
||||
|
||||
### Meaning
|
||||
|
||||
- The read-back does not match the local file.
|
||||
|
||||
### Common causes
|
||||
|
||||
- Unstable USB connection/cable
|
||||
- Jibo dropped out of RCM mid-process
|
||||
- Write succeeded but read-back got corrupted
|
||||
|
||||
### What to do
|
||||
|
||||
- Re-enter RCM and re-run with `--mode-json-only --full-var-write` (simplest “make it match” path).
|
||||
- Consider disabling verify to proceed if you’re confident the write worked:
|
||||
- `--no-verify`
|
||||
|
||||
---
|
||||
|
||||
## 7) SSH works but updater fails
|
||||
|
||||
### Connection failures
|
||||
|
||||
- Check Jibo is booted to the checkmark and reachable:
|
||||
- port 22 open
|
||||
- `root` / `jibo`
|
||||
|
||||
### “Rootfs is read-only” issues
|
||||
|
||||
Updater tries to remount `/` read-write:
|
||||
|
||||
- `mount -o remount,rw /`
|
||||
|
||||
If that fails, the updater will refuse to upload.
|
||||
|
||||
### Archive layout issues
|
||||
|
||||
If the updater cannot find `build/` automatically:
|
||||
|
||||
- pass `--build-path` to point at it inside the extracted tree
|
||||
|
||||
### Dry-run
|
||||
|
||||
To debug without uploading files:
|
||||
|
||||
- `--dry-run`
|
||||
|
||||
---
|
||||
|
||||
## 8) Where to look for logs / outputs
|
||||
|
||||
- Installer work files: `../jibo_work/`
|
||||
- Updater cached downloads/extraction: `../jibo_work/updates/`
|
||||
- Updater state tracking: `../jibo_work/update_state.json`
|
||||
|
||||
See: [[07 - Working Directory + State Files]]
|
||||
@@ -1,9 +0,0 @@
|
||||
Jibo has many different interesting things that sometimes you can get confused! This document contains things that are nice to know for tinkering or developing for Jibo Revival.
|
||||
# Useful Ports
|
||||
> [!INFORMATION]
|
||||
> You might not be able to access some ports if you haven't unblocked them on Jibo's firewall.
|
||||
### 8779
|
||||
This port has the skills manager. From here you can do a semi-reboot by stopping and starting the "@be/Be" skill.
|
||||
# Useful Files
|
||||
### /opt/jibo/Jibo/Skills/@be/be/resources/JiboSplash.png
|
||||
This file allows you to edit the splash screen. One thing to clarify is that it is only the splash screen for the Be skill meaning it will only edit the splash seen when you restart "@be/Be" or in the 'second boot stage' when Jibo spins and shows the splash
|
||||
24
index.md
24
index.md
@@ -5,28 +5,18 @@ This is a vault base around the jibo revival project, everything we have discove
|
||||
|
||||
### Table Of Contents
|
||||
|
||||
[[Hardware and Tegra Exploitation]]
|
||||
To check a mod guide , go to [[1. Get your environment ready!]]
|
||||
|
||||
[[Network Profiling & Traffic Analysis]]
|
||||
To read about the project go to : [[Welcome to the Jibo Revival Project]]
|
||||
|
||||
To learn about the os , check out [[Useful Items List]]
|
||||
|
||||
|
||||
|
||||
>[!info]
|
||||
Files under uncategorized or Documentation with the #AtDev tag are files i use to keep track of the steps to make or recreate something , eventually they will get compiled to a guide or proper documentation
|
||||
|
||||
|
||||
- - -
|
||||
|
||||
Uncategorized:
|
||||
[[Jibo Workshop HRI 2024]]
|
||||
[[Useful Items]]
|
||||
|
||||
|
||||
Documentation:
|
||||
ESML:
|
||||
[[ESML-SDK.pdf]]
|
||||
[[Jibo-Animations.pdf]]
|
||||
Dictionary:
|
||||
[[ESML]]
|
||||
[[Robot Os]]
|
||||
|
||||
|
||||
|
||||
More stuff will be coming soon :)
|
||||
Reference in New Issue
Block a user