Make reward speed-independent

[kazeevn]

Про reward. Вижу с ним проблему. Он делается по тикам - если пролететь по той же траектории в 2 раза быстрее, то штраф будет примерно в 2 раза меньше, хотя вероятность столкновения, очевидно, не поменяется.

1. Если делать, как в https://github.com/yandexdataschool/satellite-collision-avoidance/issues/2 - то reward надо будет интегрировать по времени.
2. Если по тикам, то надо интегрировать по тикам

[bamasa]

Понятно. Я так понимаю, что тогда надо в get_reward учитывать previous_state и time_between_states.

[bamasa]

Хотя не понятно. Я думал, что повышенная скорость - отклонение от траектории, которое учитывается в reward. А коль скоро мы движемся с одной скоростью, зачем интегрировать?

[bamasa]

плюс еще я думаю, что несмотря на #2 (что, кстати, мы и планируем делать - даже в action внесли), надо считать reward и проверять collision по тикам. Иначе, например, мы можем задать так time_to_next_action так, что просто не заметим collision.

[kazeevn]

Хотя не понятно. Я думал, что повышенная скорость - отклонение от траектории, которое учитывается в reward. А коль скоро мы движемся с одной скоростью, зачем интегрировать?

Ты прав в том, что у нас траектория (параметры эллипса) и скорость однозначно связаны. Я не совсем корретно выразился, лететь быстрее по той же траектории не получиться. Имелось ввиду другое - если сейчас спутник летит быстрее, он в набирает меньше штрафа за счёт того, что у него меньше плотность тиков в опасной зоне, если он достаточно ускорится, он вообще может её "проскочить".

надо считать reward и проверять collision по тикам.

Да, конечно.

[bamasa]

А почему просто не регулировать плотность тиков? Просто поставить ее достаточную. Тем более, что все объекты примерно с одной скоростью летают?

[kazeevn]

Я не про corner cases, я про reward hacking. Два КА летят на встречу друг другу - один решает "помирать, так с музыкой!", ускоряется на встречу - и получает бонус в reward.

А почему просто не регулировать плотность тиков?

Это само по себе хорошая идея - чем больше скорости, тем меньше мы хотим шаг. Как это сделать хорошо, надо думать.

IMHO, интегральный reward должен быть функцией от вероятности того, что КА дожил до текущего момента, полученной в какой-то простой модели. Если это будут интуитивные "попугаи", от reward hacking'а мы не уйдём. Я попросил Ирину посмотреть: https://github.com/yandexdataschool/satellite-collision-avoidance/issues/6

[kazeevn]

Кажется, это отдельная сложная часть. На правах идеи, можно попробовать вариант без формализма вероятности вообще. Сказать, что КА - шары, координаты знаем точно. Если шары пересекаются, штраф и game over. А вероятности потом оценивать методом Монте-Карло.

Что ты про такое думаешь с точки зрения RL?

[bamasa]

Думаю что надо начать именно с этого. Кормить весь state в нейронку (в начале просто NN, потом RNN) и с помощью RL обучать ее веса (на выходе получать action). И учет отклонения от траектории я хочу сделать, т.к. кажется, что иначе КА будет будет маневрировать как ему вздумается.

[kazeevn]

Обсудили 7.12: скользящий максимум

[kazeevn]

@bamasa я посмотрел на код и не очень понимаю логику, по которой считается текущий self.collision_risk_reward. Не мог бы ты словами написать, чему, с точки зрения физики, равен self.collision_risk_reward в момент времени t?

[bamasa]

@kazeevn , идея была такая, что self.collision_risk_reward будет считаться как некоторая функция от вероятности столкновения. сейчас он просто ей равен.

Но теперь ясно, что раз у нас есть вероятность столкновения, тогда collision_risk_reward представляет собой лишнюю величину. Будем просто копить reward. P.S. сейчас залью

[kazeevn]

collision_risk_reward не лишняя - reward складывается из нескольких компонент. Я скорее спрашивал, как ты считаешь вероятность столкновения.