roboforum.ru

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 человека, которые пропагандируют практику, угадайте кто?

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

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

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

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