firened

DECTalk TTS (moonbase alpha voice) runs on raspberry pi

for web
https://webspeak.terminal.ink/

Install, Compile fails on 3A, works on 4B:
https://github.com/dectalk/dectalk

invoke locally:

echo "[dah<300,30>][dah<60,30>][dah<200,25>][dah<1000,30>][dah<200,23>][dah<400,25>][dah<700,18>]" | tee ~/tts.txt

~/dectalk/dist/say -pre '[:phoneme on]' -fi ~/tts.txt -fo ~/dtmemory.wav; aplay -q -D plughw:1 ~/dtmemory.wav

create songs:
https://scruss.com/b...g-with-dectalk/

fun phrases, songs:
http://theflameofhope.co/DECTALK.html
http://theflameofhope.co/dectalk%20speak%20window/ROCK/
https://www.reddit.c..._songscommands/
https://steamcommuni.../?id=1226345628
add your own fun phrases in the comments.

see all these TTS related posts:
Amazon Alexa TTS
picoTTS
Google TTS
Enable espeak markup language
dectalk (moonbase Alpha) TTS

writing this down in case it's useful for someone in the future.

i got an "orange pi pc", it doesn't have WiFi, but there are other orange pis with wlan.

Raspbian is only supported on raspberry pi. i installed armbian on the orange pi pc.
UPS 40-pin hats fit and are electronically compatible, but the mounting holes do not align!

 IMG_20221214_103125.jpg   92,08 Ko   26 téléchargement(s)
 IMG_20221214_103219.jpg   75,36 Ko   27 téléchargement(s)

orange pi uses "parallel dvp data" and does not support raspberry pi's "MIPI CSI-2" camera modules. some people complain about bugs, but image quality would probably be ok for the supported "gc2035" and "ov5640" camera modules. orange pi has a different CSI connector too.

camera hardware support:
ov5640 70°FOV 30/60fps@?
gc2035 110°FOV 15fps@uxga
ov5647 will not work, despite what AliExpress says. ov5647 has a 15pin flex cable but orange pi pc has 24pin connector.

testing the Vigibot client:
install steps taken:
```
sudo nano /boot/armbianEnv.txt
console=display

sudo armbian-config
```

package pigpio cannot be installed.
pigpio is only supported on Raspbian:
https://github.com/N...s/issues/122993
lgpio or rgpio may be alternatives
http://abyz.me.uk/lg/rgpio.html

pigpio calls in vigiclient:
```
const GPIO = require("pigpio").Gpio;
GPIO.INPUT
gpioOutputs[i][j] = new GPIO(hard.OUTPUTS[i].GPIOS[j], {mode: GPIO.OUTPUT});
gpioOutputs[n][i].pwmFrequency(hard.PWMFREQUENCY);
gpioOutputs[n][i].servoWrite(pwm);
gpioOutputs[n][gpio].pwmWrite(Math.abs(map(pwm, -100, 100, -255, 255)));
gpio.mode(GPIO.INPUT);
gpio.digitalWrite(etat);
```

from what i see lgpio has functions for pwmWrite, digitalWrite, servoWrite too, only pwmFrequency doesn't exist, but that's not absolutely necessary.

Links collection:
http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_PC
Armbian:
https://www.armbian.com/orange-pi-pc/
https://linuxhint.co...bian-gnu-linux/



conclusion:
the orange pi, as a SBC for simple uses works well and is cheap. Armbian has similarities and differences to Raspbian, and seems to be a nice OS.
however, it appears that support for each peripheral is manufacturer dependant, in this case orange pi.
whether peripherals like camera, gpio, i2c, uart and the like will work with specific software is not clear.

regarding Vigibot, i think it's possible, but would probably take a considerable amount of effort. wifi, camera, uart, i2c is mostly handled by the OS and can perhaps work with little changes.
but it would require multiple modifications to the vigiclient code to support lgpio.

UPDATE 2022.11.22: Find the updates about this Guide on GitHub: https://github.com/e...spberry-vigibot

## how to create timelapse videos with your robot
Vigibot has the possibility to take photos regularly. the following script will regularly create timelapse videos using the photos, the video can then be played directly from the Vigibot website.

Note: if your camera has a motorized IR cut filter, only do step 5 and check if it clicks every minute when it's dark. this would wear out the motorized IR cut filter rather quickly. an option is to unplug the motorized IR cut filter connector on the camera module. if you have other ideas, let me know.

1. login into your robot over ssh

2. add a tmpfs entry, run:
`sudo nano /etc/fstab`
add:
```
tmpfs /tmp tmpfs defaults,noatime, nosuid,size=20m 0 0
```

3. run `sudo reboot`

4. run `df` and make sure there's a `/tmp` entry.

5. In hardware config set `SNAPSHOTSINTERVAL` to `1` to take a photo every 1 minute.
Note: Snapshots are publicly accessible on https://vigibot.com/captures/

6. create folder
```
sudo mkdir /usr/local/timelapser/
```

7. install script
```
sudo wget -P /usr/local/timelapser/ https://raw.githubus...n/timelapser.sh
```

8. make script executable
```
sudo chmod +x /usr/local/timelapser/timelapser.sh
```

9. run the script manually and leave it running
```
sudo /usr/local/timelapser/timelapser.sh
```

10. open a second ssh connection to your robot

11. run
```
sudo ln -s /usr/bin/ffmpeg /usr/local/vigiclient/processdiffintro
```

12. run
```
sudo ln -s /tmp/timelapse_short.mp4 /usr/local/vigiclient/timelapse_short.mp4
```

13. run
```
sudo ln -s /tmp/timelapse_long.mp4 /usr/local/vigiclient/timelapse_long.mp4
```

14. copy the whole `CMDDIFFUSION` array from `/usr/local/vigiclient/sys.json` into your `/boot/robot.json` file. (if Vigibot pushes an update to `sys.json` you will have to manually update/re-copy the array.)

15. add the 2 following entries to the copied `CMDDIFFUSION` array.
```
] , [
"/usr/local/vigiclient/processdiffintro",
" -loglevel fatal",
" -stream_loop -1",
" -re",
" -i /usr/local/vigiclient/timelapse_short.mp4",
" -c:v h264_omx",
" -profile:v baseline",
" -b:v BITRATE",
" -flags:v +global_header",
" -bsf:v dump_extra",
" -f rawvideo",
" -vf 'scale=640x480:force_original_aspect_ratio=decrease,pad=ih*4/3:ih:(ow-iw)/2:(oh-ih)/2'",
" tcp://127.0.0.1:VIDEOLOCALPORT"
] , [
"/usr/local/vigiclient/processdiffintro",
" -loglevel fatal",
" -stream_loop -1",
" -re",
" -i /usr/local/vigiclient/timelapse_long.mp4",
" -c:v h264_omx",
" -profile:v baseline",
" -b:v BITRATE",
" -flags:v +global_header",
" -bsf:v dump_extra",
" -f rawvideo",
" -vf 'scale=640x480:force_original_aspect_ratio=decrease,pad=ih*4/3:ih:(ow-iw)/2:(oh-ih)/2'",
" tcp://127.0.0.1:VIDEOLOCALPORT"
]
```
`robot.json` should then look something like this:
 Screenshot_20221122_111634.jpg   53,18 Ko   32 téléchargement(s)

 

16. restart the Vigibot client

17. add 2x `CAMERA` entries in hardware config and set `SOURCE` to the `CMDDIFFUSION` array index number of your entry. In the above screenshot that's array index number `8` and `9`.
 IMG_20221122_112140_e.png   174,34 Ko   32 téléchargement(s)

18. add 2x `COMMAND` entries in remote control config and set `CAMERA` to the created camera number. for me it was `5` and `6`.
 Screenshot_20221122_111407_com.opera.browser.jpg   55,57 Ko   32 téléchargement(s)

19. run `ls -l /tmp/`, check if `timelapse_short.mp4` and `timelapse_long.mp4` exist and check if it's working on vigibot.

20. if it works, automatically start it on boot: run `sudo nano /etc/rc.local` and add the following above the line `exit 0`
```
/usr/local/timelapser/timelapser.sh > /dev/tty0 &
```



### additional information / explanations:
thanks to Pascal for some of the above instructions.

it seems `enfuse` hdr images cause ffmpeg to fail. do not set `EXPOSUREBRACKETING`

### for future reference: manual cli commands
- use most recent images for short clip. takes about 10 seconds to create.
```
#target length: 1h in 6s playback
#'-sseof 2': use only most recent 2 seconds of input
#ffmpeg may be assuming a different fps value in its -sseof calculation
#'-r 10': set conversion to 10 fps
#'-filter:v fps=fps=30': force 30 fps output so thr 30 fps vigibot captures work
```
```
sudo ffmpeg -sseof -2 -r 10 -pattern_type glob -i "/home/pi/timelapse/*.jpg" -s 640x480 -vcodec libx264 -filter:v fps=fps=30/tmp/timelapse_short.mp4 -y
```

- long clip. takes about 90 seconds to create.
```
#target length: 24h in 40s playback
#"-sseof 52": use only most recent 52 seconds of input
#ffmpeg may be assuming a different fps value in its -sseof calculation
#'-r 30': set conversion to 30 fps
#'-filter:v "setpts=0.5*PTS"': only pass 50% of the frames, drop the others. this halves timelapse_long playback duration. (e.g. '0.2' would only pass 20% of the frames).
```
```
sudo ffmpeg -sseof -52 -r 30 -pattern_type glob -i "/home/pi/timelapse/*.jpg" -filter:v "setpts=0.5*PTS" -s 640x480 -vcodec libx264 /tmp/timelapse_long.mp4 -y
```
 

UPDATE 2022.08.22: i didn't do a good job checking if the servos fit into the vigibot 3D files. unfortunately no metal gear 180° fit the vigibot 3D files. Doman DM-S0090MD 270° is the only metal gear servo that fits. Bokins plans on modifying the 3D files to make the DIYMore MG90S fit.

 

servo benchmark

goal: find robust servo models for a Minus-Type robot, in the hopes of extending time between servo failures and repairs. A per piece price of up to 20$ may be acceptable (N20 Pololu motors are also in that range). Minus-Type uses Micro Servos, also called 9g or sg90.

tested are the following servo models:

1) DIYMore SG90, plastic gear, 1$: recommended by Vigibot. are very quick which makes for a comically fast head nodding that people find hilarious. used on most of my robots (not WalterJakob's pan-tilt), personal failure rate is pretty high. EDIT: a resonating shaking may happen if the weight is too far from the axis line (used as pan servo on PepitoBots). i assume a drawback of the PID(?) regulator in use, which is probably also responsible for the desired comically fast nodding. same applies to DIYMore MG90S metal gear servo (used as pan servo on Briecam).

2) DIYMore MG90S, metal gear, 3$: had servos in the past that were DOA or didn't work on the lower battery voltage, unfortunately can't remember the exact reason. EDIT: read above servo #1 notes. EDIT: servo doesn't fit the current 3D printer files, requires adjustment.

3) TiankongRC TS90A, plastic gear, 270°, 3$

4) Doooman Hobby DM-S0090MD, metal gear, 270°, 6$

5) DFRobot DS-S006L, plastic gear, 9$: has a clutch to protect internal gears.

6) FiTec FS90MG, metal gear, 6$

7) Spektrum A330, plastic gear, 18$

8) Futaba S3114, plastic gear, 20$: "sub-micro" servo doesn't fit the current 3D printer files, requires adjustment.

9) HiTec HS-55+, plastic gear, 20$

10) HiTec HS-5055MG, metal gear, 30$

11) HiTec HS-65MG, metal gear, 30$
 IMG_20220514_134716.jpg   300,5 Ko   47 téléchargement(s)
↓ See conclusions or table "benchmark table.xlsx" for servo failure times.

test tries to simulate real world usage, common scenarios:

• to work with Vbat voltage 3.3V - 4.2V

• usually low weight/momentum movements (camera is pretty lightweight)

• people may accidentally hit the robot

• robot may drive into walls or objects with a servo absorbing the hit

• servo may want to move into an object and be limited by it

stress test setup:

pre-test #0: power from 3.3V and check if servo is even functional (most servo specifications state a minimum operating voltage of 4V). stop movement with hand, to check if it stops immediately / gets stuck.

main test #1: power from 3.3V, move back and forth (90° - 0°) automatically (eg 1 cycle every 6s to keep temperature low), no weight attached. from time to time force into obstacle (180° position can't be reached) to simulate real world interaction. let run every night and check how many minutes they last before they stop working.
 IMG_20220522_191724.jpg   185,08 Ko   46 téléchargement(s)
notes:

27.5.22: ran test #1 for 2400min (actual movement: 400min), 1 cycle (to 0° and back to 90°) every 6s, no failures.

-> replaced with 10A 3.3V power supply. increased speed from 1 cycle every 6s to 1 cycle every 2s. now movement from 3 servos overlap. can still be doubled. temperature IR meter: room = 27°C, servo avg = 35°C, servo max = 37°C.

28.5.22: ran test #1 for 480min (actual movement: 240min), 1 cycle every 2s no failures.

-> increased speed to 1 cycle every 1s. movement from 6 servos overlap, maximum possible. temperature IR meter: servo avg = 42°C, servo max = 46°C

29.5.22: ran test #1 for 800min (actual movement: 800min), 1 cycle every 1s,

-> divided runtime value by intensity to "actual movement" value.
 VID_20220606_211516.mp4   13,93 Mo   95 téléchargement(s)
Conclusion for Botkins / Minus-Type Robot:

6 servos had good behavior and more than acceptable runtime until failure.

Metal Gears:

• DIYMore MG90S: Okay. EDIT: .stl doesn't fit! 

 

• FiTec FS90MG: Okay. EDIT: .stl doesn't fit! 

• Doooman Hobby DM-S0090MD: Okay (Pan 270°: cable fatigue!)

Plastic Gears:

• DIYMore SG90: Okay

• TiankongRC TS90A: Okay (Pan 270°: cable fatigue!)

not recommend servos:

• DFRobot DS-S006L: Okay EDIT: auto-revert is annoying, drops objects in gripper by itself!

 

• Spektrum A330: No (failed early)

• Futaba S3114: No (.stl doesn't fit)

• HiTec HS-55+: No (Slow)

• HiTec HS-5055MG: No (3.3V unsupported)

• HiTec HS-65MG: No (Slow)

See table "benchmark table.xlsx" for servo failure times.

 benchmark table (1).xlsx   7,24 Ko   74 téléchargement(s)

add a framebuffer view:
- add a CAMERA in hardware config with SOURCE: 1
- add a COMMAND in remote control config and use the created camera number

display chat text on framebuffer:
- install dependencies:
`sudo apt install lolcat cowsay figlet`
-then edit robot.json
`sudo nano /boot/robot.json`

for a cow with a speech bubble, add:

"CMDTTS": "cat /tmp/tts.txt | /usr/games/cowsay | /usr/games/lolcat -F 0.3 > /dev/tty0"

for big colorful text (thank you Pascal) :

"CMDTTS": "cat /tmp/tts.txt | /usr/bin/figlet -f small | /usr/games/lolcat > /dev/tty0"

there are lots of possibilities and adjustments possible with lolcat, figlet, cowsay, toilet or fortune and more. Add your favorite CMDTTS into the comments