Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
The relations of TucoChat and TucoFlyer/Bot-Controller

The relations of TucoChat and TucoFlyer/Bot-Controller

This is my understanding for now.

Voting

The voting system is essential for TucoChat, while the code is actually in Bot-Controller. The voting is made up of cycles with specifyable intervals. After every cycle ends, the flyer will move in the most popular direction in the cycle.

Vote values

Every cycle, the users are voting for directions that the bot will move in, like UP, DOWN, FORWARD, BACKWARD, LEFT and RIGHT.

The vote's syntax depends on the interface, and is not defined in the voting system. For example, in the Gitter and Twitch daemons, I use W to say FORWARD, but in the CLI's case, vote forward is the syntax for voting on FORWARD.

TucoChat interfaces

TucoChat is made up of daemons for every different platform of communication (like Twitch, Gitter, etc.), that's jobs are to send commands to Bot-Controller based on the input it gets. There is also TucoChat-CLI, which is a CLI that directs commands from the command line to Bot-Controller.

TucoChat Daemon Commands

In the daemon, all the commands are coming from outside users, and they should not be treated as administrators (admin commands discussed later on).

Direction commands

Direction commands are votes casted for the gimbal to move in a specified direction in the current cycle.

In daemons for chat platforms (unlike letsrobot.tv), I used a WSAD mapping for the directions currently implemented. (The directions are currently missing UP and DOWN, which is necessary to implement later on.)

When a user types (ex.) W in chat, the bot calls the websocket to place a vote on FORWARD.

Special action commands

Special action commands happen instantly, but cost Tokens, and also have parameters, and cooldowns.

For example, special actions could be CV and gimbal based, instead of winch based. The testing action currently implemented in the daemons is LOOK <value>, which commands Bot-Controller to direct the camera at the specified object based on CV.

TucoChat CLI Commands

The TucoChat-CLI supports all the commands that daemons support (but with other syntax), and it has Admin commands.

Admin commands (Not discussed before)

Admin commands help the admin (you) moderate actions happening through the other daemons. For example, with admin commands, you can modify the cooldown of a specific special action, disable or enable voting, disable or enable the usage of special actions, and set the interval of the vote cycles.

Authentication

Daemon commands (votes & special actions)

Daemon commands do not require authentication, since they have to have safeguards built in to prevent damage from users through the daemon.

So if someone breaks into the LAN and finds Bot-Controller, but can't authenticate, they can't do physical damage to TucoFlyer.

Admin commands

Admin commands require authentication, since they control sensitive settings.

WebSocket commands

Vote commands

For voting, we'd need a websocket command that takes:

  1. a direction (UP/DOWN/LEFT/RIGHT/FORWARD/BACKWARD),
  2. a username, to prevent multiple voting in a cycle
  3. and the name of the daemon's platform, to prevent clashing usernames between platforms

Special action commands

For special actions, we'd need a websocket command that takes:

  1. an action type (LOOK, etc),
  2. action data (object to look at, etc.),
  3. a username, for checking if there are enough points for executing the action, and for checking cooldowns,
  4. and the name of the daemon's platform, to prevent clashing usernames between platforms

Admin commands

In my opinion, it would be logical to have admin commands seperated, instead of munching them into one websocket command and taking a command type and data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.