roboforum.ru

Да, круто. Гол с разворота - супер. Только опасно все это - тратить свое время на виртуальный мир...

Добавлено спустя 3 минуты 24 секунды:
Блин, идея, у нас же есть реальные машинки, управляются с компа как бои роботов. Повесить камеру, в машинки заливать сценарии (это я сказал? ) через интернет.
Во, и тараканьи бега/футбол/сумо наши тоже в теме.

Добавлено спустя 6 минут 17 секунд:
Хотя было все это - микрогонки, поломают все через интернет и нужен постоянно оператор. Надо беспроводные зарядки допиливать...

Dmitry__ писал(а): в машинки заливать сценарии

Последнее время пошли дела кое как. А то я уже хотел поставить эпиграфом к теме цитату из фильма "Трое в лодке..."( в книге такого нет):"Джорж, вы вообще хотите поставить палатку?! - Вообще-то говоря не очень." (За точность цитаты не ручаюсь)

Я знал, что тебе понравится
Но у нас специализация - игровые системы, никакого ИИ

Scorpio, спроектируй всё нормально и нить происходящего не будет теряться, будут интервалы перед действиями и т.д. вариантов как реализовывать море. из того старого проекта, что уже упоминал немного покопипастил и подправил для наглядности

Код: Выделить всё • Развернуть

public class JumpSensor : ISensor
{
    private readonly IEventDispatcher eventDispatcher;

    private FieldObjectMode modeChangedFrom;
    private FieldObjectMode modeChangedTo;

    public JumpSensor(IEventDispatcher eventDispatcher)
    {
        this.eventDispatcher = eventDispatcher;
    }

    public void Update()
    {
        var currentMode = Unit.Mode;

        if (this.modeChangedTo != currentMode)
        {
            this.modeChangedFrom = this.modeChangedTo;
            this.modeChangedTo = currentMode;

            if (this.modeChangedTo == FieldObjectMode.Jump)
            {
                this.eventDispatcher.Dispatch(new JumpStartedEvent());
            }
            else if (this.modeChangedFrom == FieldObjectMode.Jump)
            {
                this.eventDispatcher.Dispatch(new JumpEndedEvent());
            }
        }
    }
}

public class JumpToFieldObjectAction : IAction<JumpToFieldObjectContext>
{
    private readonly ICommandDispatcher commandDispatcher;

    public JumpToFieldObjectAction(ICommandDispatcher commandDispatcher)
    {
        this.commandDispatcher = commandDispatcher;
    }

    public RunStatus Execute(JumpToFieldObjectContext context)
    {
        this.commandDispatcher.Dispatch(new JumpToFieldObjectCommand(context.FieldObject, context.Distance));
        return RunStatus.Success;
    }
}

public class JumpToFieldObjectCommandHandler : ICommandHandler<JumpToFieldObjectCommand>
{
    private readonly IEventDispatcher eventDispatcher;

    public JumpToFieldObjectCommandHandler(IEventDispatcher eventDispatcher)
    {
        this.eventDispatcher = eventDispatcher;
    }

    public void Execute(JumpToFieldObjectCommand command)
    {
        command.FieldObject.JumpTo(command.Distance);

        this.eventDispatcher.Dispatch(new StartJumpingToFieldObjectEvent(command.FieldObject, command.Distance));
    }
}

public class CanJumpToFieldObjectCondition : ICondition<JumpToFieldObjectContext>
{
    private readonly IJumpManager JumpManager;

    public CanJumpToFieldObjectCondition(IJumpManager JumpManager)
    {
        this.JumpManager = JumpManager;
    }

    public bool IsSatisfies(JumpToFieldObjectContext context)
    {
        return this.JumpManager.CanJumpTo(context.FieldObject);
    }
}

public class StartJumpingToFieldObjectEvent : IEvent
{
    public StartJumpingToFieldObjectEvent(FieldObject FieldObject, double distance)
    {
        this.FieldObject = FieldObject;
        this.Distance = distance;
    }

    public FieldObject FieldObject { get; }

    public double Distance { get; }
}

public class JumpEndedEvent : IEvent { }

public class JumpStartedEvent : IEvent { }

public class JumpManager : IJumpManager, IEventHandler<StartJumpingToFieldObjectEvent>, IEventHandler<JumpEndedEvent>
{
    private readonly ITimeoutProvider timeoutProvider;

    private DateTime nextJumpAfter;

    public JumpManager(ITimeoutProvider timeoutProvider)
    {
        this.timeoutProvider = timeoutProvider;
    }

    public bool CanJump()
    {
        if (this.nextJumpAfter > DateTime.UtcNow) return false;

        if (Unit.Mode == FieldObjectMode.Jump) return false;

        if (Unit.Item.Attributes.TryGetValue("JumpEnergyNeed", out attributeValue) && Unit.Energy - attributeValue.ToDouble() < 0) return false;

        return true;
    }

    public bool CanJumpTo(IJumpable obj)
    {
        return this.CanJump() && obj.IsInJumpRange;
    }

    public void Handle(StartJumpingToFieldObjectEvent @event)
    {
        this.nextJumpAfter = DateTime.UtcNow + this.timeoutProvider.GetRandomTimeout(2000, 4000);
    }

    public void Handle(JumpEndedEvent @event)
    {
        this.nextJumpAfter = DateTime.UtcNow + this.timeoutProvider.GetRandomTimeout(2000, 3500);
    }
}

там свои особенности и ограничения были, а работая в своём коде можно сделать намного лучше и удобней. или тот тестовый пример с зарядкой акума смутил? так он тестовый, на пощупать - как компилировать, как заливать, сколько бинарик будет занимать, как быстро что-то выполняться будет (чужие тесты с чудными данными это хорошо, но недостаточно), как стыкуется mf с конкретным мк (работа с переферией, таймерами и т.д.) и прочее. а так будет более адекватный (как там дерево это ни разу не для реального применения - старые корявые костыли, только в профиль) небольшой фреймворк с событими, планировщиками действий и использовании разных подходов (машина состояний, деревья,...) на различных уровнях, подсистемами, сервисами, псевдомногопоточностью,... доступ к различным примерам реализации у тебя же есть, возьми и посмотри повнимательней хотя бы как на дотнете из коробки реализованы различные типы приложений, покопай роботикс студию, рос, юнити3д, поковырять игры, ботов для соревнований, как реализовано управление во всяких машинках, обучающих конструкторах и т.д.

Спасибо, ребята, что не даете скучать.Я всю эту инфу складываю в копилку кладези мудрости, в надежде, что на пенсии у меня хватит времени со всем этим разобраться. Хотя не исключено, что у квантовых компов в то время будут совершенно другие парадигмы (это слово Дмитрий произносил - надеюсь не ругательное)

или сразу в мусорник всё складывай. толку от мотания на ус никакого - ни достаточного понимания как что работает, ни представления в какой задаче как можно реализовать и реализуемо ли вообще. бери и пробуй реализовывать - даже криво-косо реализованное лучше чем никак. набрался ещё опыта и знаний, пробуешь сделать лучше.

А давайте каждый напишет кратенько, как он бы реализовывал сценарий приведённого робота - Лунохода, а потом вводим в сценарий дополнительное условие, например - если на пути конфета, то съешь её. Далее смотрим, как работают полученные решения с изменённым сценарием. Если я правильно понял, у Виктора это просто добавляются правила (интересно было бы посмотреть реализацию, очень заманчиво выглядит написание логики, как набора правил . Я бы в этом случае добавил автомат по съедению конфеты, причём, для наглядности и простоты, нарисую в графах и прогоню конвертером в код. Это не просто конвертер, а с автоматической генерацией кода логирования процесса исполнительного механизма, для отладки логики. Ещё входное воздействие появиться дополнительное - сенсор КОНФЕТА. Примерно так получается: препятствие -> конфета -> автомат КОНФЕТА (вызываемый, с перехватом управления) -> состояние автомата КОНФЕТА: СЪЕСТЬ КОНФЕТУ -> состояние КОНФЕТА СЪЕДЕНА -> выход из автомата КОНФЕТА.

smur писал(а):а потом вводим в сценарий дополнительное условие, например - если на пути конфета, то съешь её

Это опять абстрактный мир. Эти сценарии могут не действовать в реальном мире или приводить к абсолютно другому результату. Луноход слишком примитивен, чтоб на нем показывать преимущества алгоритмов. Пример Виктора Казаринова вырождается в самый примитивный конечный автомат. Да и вообще, все вводные данные в примере предопределены, странный ИИ.
Куда интереснее "Russian AI cup" dccharacter-а, вот там можно сравнивать преимущества парадигм. Но есть маленькое но - опасность заиграться в виртуальный мир и выкинуть на свалку весь полученный опыт.

Добавлено спустя 2 минуты 7 секунд:
Вообще, заметил тенденцию, в этой теме обозначились 2 человека, которые пропагандируют практику, угадайте кто?

Кто?

Добавлено спустя 42 секунды:
У меня на спортивных роботах конечные автоматы работают на ура.

smur писал(а):А давайте каждый напишет кратенько...

Вот это я и предлагал, чтобы сравнить преимущества разных подходов. Если луноход себя исчерпал, то можно придумать новую задачу или усложнить луноход

Квантовые компы никак не повлияют на сценарии. Квантовые компы работают с состояниями и вероятностями. Оценка ситуации, принятие решения - да. Выполнение заданной последовательности по сценарию - ничего, кроме усложнения программирования не даст.

Добавлено спустя 9 минут 11 секунд:
И вообще, начинайте сначала. Нет у робота задачи есть конфету. У робота есть залача максимизировать полезную функцию или функции. Все. Если ты определишь поедание конфет, как полезную функцию, робот будет их есть. Но поедая конфеты, он будет заниматься не поеданием конфет, а максимизацией полезной функции. Съеденные конфеты - просто побочный эффект максимизации полезной функции поедания конфет.
Перечитайте это десять раз, и поймете, что "сценарии" - это вообще неинтересная предетерминированная область и неважно как и на чем их писать. Язык написания сценариев преследует всего одну задачу - снизить затраты на написание сценариев. Все. Дальше хоббиисту должно перестать это быть интересным вообще, потому что, как нас учит Дима, когда честь идет о семье речи...

Может и так. А, что тогда д.б.интересно хоббисту, если он не АТ-ишник? Я прекрасно понимаю, что чуть ли не каждый день возникают новые АТ-технологии, языки фреймворки, парадигмы и т.п. Но, мне за ними никогда не угнаться. Потому как хобби - оно всегда на поледне месте и просто времени на него практически нет. А, желание делать что-то двигающееся, хрюкающее и говорящее еще не пропало. Можно, конечно день потерять, а потом за полчаса долететь. Но за этот день (в реальности год) еще что-нибудь придумают. А лететь хочется уже сейчас.
Т.е. никакие сценарии тут вообще никто не пишет? В той-же ROS наверняка тоже предполагается место, где роботу надо явно описать последовательность каких-то действий.
- Для чего нужна ROS? - чтобы не писать самому SLAM,
- Для чего нужен SLAM? - чтобы проехать в определенную точку на карте,
- Для чего нам туда ехать? - чтобы сказать "Привет, Вася!".
Это уже сценарий. Что в ROS все равно где и как его записать?

Вот она мощь ИИ! Сразу ощущаешь свою естественную глупость!
Так как же нам облегчить программирование робототехнических систем?
А сценарий типа 'Сбегай за пивом' тоже можно считать неинтересной предетерминированной областью? (Еле выговорил
Что сказать роботу? Или он сам догадается сгонять, раз пятница?
Кстати, с пятницей всех! Надеюсь у кого нибудь робот уже за пивом сбегал, мне вот самому пришлось идти.

Ыыыы, мало раз перечитал мое сообщение

Я всех своих роботов срочно учу поздравлять меня с пятницей. Как мне раньше такая идея в голову не пришла!?
У меня тут, кстати, море Карибское под балконом плещется, и на балконе пивко с креветками Так что ну их, роботов.