Estimativa tool para bids em CNPs

[rafaelcaue]

Considerar o fato de um agente ter todas as tools (ou parte delas) para fazer a tarefa, e estimar isso em um valor para a bid?

Exemplo: Drone tem tool1 Moto tem tool2 e tool3 A tarefa é fazer 2x material1 Material1 precisa da tool2 e da tool3

Porém o drone gasta 8 passos e a moto 16 passos para movimentação (estimativa de passos não considera o assist assemble nem o tempo que um agente vai gastar esperando a ajuda de outros - inviável de implementar isso no momento). Quem seria melhor fazer a tarefa?

Generalizando, que valor atribuímos para a bid do agente quando ele tem todas as ferramentas necessárias para a tarefa? E quando ele tem apenas algumas delas?

Atualmente a bid de um agente é o número de passos até 1 shop + até 1 workshop + até 1 storage. Se o agente não conseguir carregar os itens da tarefa a sua bid é 0 (reject).

[anibalsolon]

Não sei, me parece meio inconsistente a ideia, posso estar viajando... Mas o certo não seria fazer um bid para cada tool do material? Considere o cenário:

Drone tem tool1 Moto tem tool2 e tool3 Carro tem tool2 Material1 precisa da tool1, tool2 e tool3

O mais otimizado seria que o material fosse feito pelo Drone e pela Moto, certo? Desconsiderando distancias/passos.

O que poderia fazer é que o valor dos bids do agente fosse, por exemplo, dividido por 2 quando ele tivesse participando de mais de uma bid por material. Isso para aproveitar o fato de ele já estar indo para lá com a tool2, então vai com a tool3 também. Se ele tivesse mais a tool1, aí dividiria por 2 again e ficaria melhor ainda.

Mas agora, considerando esse novo cenário: Drone tem tool1 Moto tem tool1, tool2 e tool3 Carro tem tool2 Material1 precisa da tool1, tool2 e tool3

Se o drone tiver perto o bastante, ele pode ganhar a bid da tool1. Então o que se poderia fazer internamente no sistema de bids é considerar essa situação de ter mais de uma tool. Internamente, o bid do drone não seria somente o seu bid. O drone daria o seu bid normal para a tool1 do material1, mas no artefato o bid seria o bid do drone + a soma dos menores dos bids para se conseguir alguém com as outras tools. Nesse caso, o bid da moto, já que ela possui as outras tools.

Aí sim, esse sistema de bidding por tool funcionaria de forma justa, já que:

bid do drone + bid da moto > bid da moto

e assim a moto seria selecionada para usar as 3 tools para fazer o material1.

Em um cenário: Drone tem tool1, tool2 e tool3 Moto tem tool1, tool2 Carro tem tool2 Material1 precisa da tool1, tool2 e tool3

o drone só não ganharia o bid sozinho pois há de se considerar a questão do volume no calculo do bid. Nesse caso, o drone e a moto fariam o material1.

Faz sentido? :confounded: :baby: :suspect:

[rafaelcaue]

Faz sentido sim, mas acho que isso entra na separação das tarefas.

Por enquanto o nosso código separa um job nos itens necessários para esse job. Exemplo: priced_job(job1,[item(material1,2),item(material2,2)],storage1)

Vamos ter 2 cnps, uma para 2x material1 e a outra para 2x material2.

E quem ganhar uma dessas cnps fica responsável por comprar as bases, fazer o assemble, e entregar. Caso o agente não tenha a tool ele vai ficar pedindo ajuda e aguardando até alguém vir ajudar. O problema é que se os outros agentes que podem ajudar sempre estiverem ocupados ninguém nunca vai ir ajudar, o que é ineficiente.

Eu acho que uma maneira de implementar o que o Anibal sugeriu seria quebrar a tarefa em compra das bases, assemble (com os assists necessários) e entrega (como discutimos brevemente em uma reunião anterior). Isso garante que o assist vai estar no TODO do agente e eventualmente ele vai ajudar.

Juntando isso com a sugestão do Bordini, podemos deixar a tarefa assim em um primeiro momento, e se o agente perceber que precisa de ajuda (e.g. ele não tem as tools necessárias) ele cria novas cnps. Assim não gastamos tempo criando cnps desnecessárias, por exemplo que podem ser realizadas por apenas 1 agente.

O que acham? Isso não vai ser fácil de implementar, então sugiro fechar uma release com o código que temos agora, que pelo menos completa jobs em algumas situações (temos que encontrar e resolver alguns bugs antes disso mas na reunião discutimos isso).

[rafaelcaue]

Discutido em reuniões, fechando issue.