Arguments for voice commands

[aclindsa]

Is your feature request related to a problem? Please describe.
It is often helpful to be able to add 'arguments' or 'parameters' to voice commands. For example "
set timer for 10 minutes". Have you given any thought towards how this would be implemented?

Describe the solution you'd like
A way for commands to indicate that they accept/expect arguments, and a mechanism for the core system to relay any spoken arguments back to the command's python function.

Describe alternatives you've considered
Initial thought is that this could be somehow added to the command_registry call at https://github.com/openassistant/oa-core/blob/master/oa/core/util.py#L32. However, there may be a bit more intelligence needed here. For instance, "set timer for 10 minutes from now" is different than "set timer for 10 o'clock", so simply finding the first spoken number may not be sufficient.

[joshuashort]

Thanks for raising the issue! I'm definitely with you on "often helpful" -- I'd say it's necessary.

It'd probably be something like 'slotted' commands and interactive prompts:

"set timer for [n:time_unit]"
"set timer" -> "how long?" -> "[n:time_unit]"

The command_registry helper is a great place to start! But, yeah, it's not quite that simple. Especially with variants.. so it's kind of a matter of coming up with syntax/parsers.

Open to input..

[minghia]

Second that, this is a very necessary feature.

[Yaser-Feyli]

Could you please make this open assistant compatible with Linux Fedora also please?
The project would also be cooler if it hade a international language package!

[joshuashort]

@Yaser-Feyli It should work with Fedora.. open an issue if you're having a specific problem?

[minghia]

@Yaser-Feyli I have it running on Fedora 30 on a laptop. What you need to install a version of Python > 3.6. Luckily Fedora 30 comes with 3.7.3 and it works quite well.

[minghia]

Could you use something like https://github.com/snipsco/snips-nlu to do the command parsing? It would allow a more expressive set of commands.

[joshuashort]

Yes @minghia, basically something like that.

But getting there is a little tricky. The recognizer needs either a full lexicon or at least one with enough words to support some command variations.. ideally there’d be some interplay between the context/intent model and recognition — to help resolve ambiguous words and stuff.

If you’re able to get an accurate text string, it’d be a simple call like parsing = nlu_engine.parse(text). The trick is getting text :/