raspOVOS roadmap: Where is this headed

[builderjer]

There has been some work done on an install script, mainly by Bulwagga, which works pretty well on a Raspbian system, but I think more could be done.

• manual_install_script.sh
  • detect underlying OS and install correct packages
  • add option for stable and dev
  • add GUI option
  • add options for specific sound devices
  • TTS and STT options
• raspbian-ovos image
  • Dedicated Mark 1 image
  • Automatic hardware detection
    • respeaker
    • aiy-voicebonnet
  • spotify
  • kde connect

There has been lots of talk from users about a start and stop script. I think with ovos using systemd and docker, could really just be a section in the docs and not really its own separate script.

Any other ideas or comments?

[Bulwagga]

Other thoughts... How useful would it be to have an uninstall script? STT and TTS server configuration? How often would you be doing new installs? Why would you be doing new installs? Why are you doing an install rather than using a docker container or an image?

Thanks

[builderjer]

With an install script, why not an uninstall script

Options for STT and TTS might not be bad, or an option to set them up or use default

[zap-gearloose]

how about a summary print out on connected and recognized devices - like a system check that shows if devices like usb mic or the likes are working correctly or at least are recognized by the system?

hi there, new here, my linux is still a little rusty, can only present user perspective. looking forward to see this project develop. have the ovos on my pi4b with pseye and some 3,5 jack speaker, just started out. hyped

[builderjer]

This is pretty much covered in the docs

https://openvoiceos.github.io/community-docs/troubleshooting_audio/

[builderjer]

from chats
https://matrix.to/#/!EOygeDJPfJQOfNacqH:matrix.org/$7vXdEQ6g1c4cSBxY8IbTfpMMCbpxDSFtVk9UCvRZV8c?via=matrix.org&via=mozilla.org&via=outskirtslabs.com

[mikejgray]

Related to these chats, I'd like to see some decisions made around who the target audience of the RaspOVOS image is. I don't think it qualifies as an appliance because the expectation there would be either a) the software provider (OVOS) manages all updates including security updates, or b) the expectation is to re-image for any/all updates. I see this as more of a spiritual successor to the Picroft, personally, and the intended target audience are people who have development/sysadmin experience.

The reason this is important is the conversation around whether or not to use a Python virtual environment.

If the expectation is that the end user be able to go into the image and hack around (install OS/pip packages, make changes to the underlying OS, use it as a development machine), then a Python virtual environment makes sense to isolate the OVOS software from the rest of the Python packages on the system.

If the expectation is that the end user is to accept the software as-is with minimal hacks/updates, then a system Python environment is probably acceptable, although I personally try to avoid that at all costs. Rebuilding your OS because your random dependency broke things you didn't even know existed is not a fun time.

Given the broad documentation around this image, I'd argue this is not meant to be a true appliance. The user is encouraged to log in, run commands, make updates, add software, etc. While the Assistant is meant to represent the bulk of the system, it is not everything on the system, and there is a non-zero risk that updating from apt could break the Assistant in unpredictable ways - or vice versa.

[builderjer]

I think these are valid points for sure, and I also think that you have convinced me of a venv. More and more are looking for a picroft replacement that they can hack on for sure. and being debian based, makes it perfect for that.

[Bulwagga]

At one point we had discussed keeping dev and prod versions of the rasbian image and install script. Is there any broader interest in this? For myself I know that when I want an up-to-date working version, it means an evening of tinkering. Not that I mind (I really enjoy it) but are we missing out on users that simply want to experiment with kasa or monitor their dryer without a steep learning curve?

[builderjer]

I plan a sable image when ovos-core==0.0.8 is released. Usually all of the skills are at a "stable" release then also. Almost there

[Bulwagga]

OK, let me work at the script. There is a version conflict now and it gives me a chance to see how we will lock versions in the new configuration.

[builderjer]

Should be able to pull everything from pypi instead of git. That is kinda the plan

[Bulwagga]

Got it. Thanks!

[Bulwagga]

At one time we had some Neon skills but we took them out. How about adding back Neon skill-alerts as a replacement for OVOS skill-alerts until OVOS skill-alerts is more mature?

[builderjer]

I don't want to pull in neon-utils and a new branch of ovos-skill-alerts that I have been testing with locally. I would like to switch to that instead.

[Bulwagga]

Works for me. :)