Навигация

Как устроена навигация в автомобилях Tesla. В чем трудности поиска пути по земли русской?

C 2018 года все счастливые обладатели Tesla в России получили обновление Европейской навигации в которой России уже не было, официально это объясняется поддержанием баланса веса карт и удалением регионов, не входящих в зону официального обслуживания.

Как же использовать большой экран Tesla на полную силу? Видеть маршрут, какой процент батареи останется? С какой скоростью ехать? Можно ли сделать даунгрейд на старые карты?

Тесла использует для построения маршрутов Valhalla -это механизм маршрутизации с открытым исходным кодом и сопутствующие библиотеки для использования с данными OpenStreetMap.

Вальхалла - это не только пантеон германских Богов и "чертог мёртвых ", но и отличный движок для построения маршрутов с дополнительными инструментами и модульной структурой, API на основе C++, с возможностью перекрестной компиляции различных фрагментов. И да, все это open source https://github.com/valhalla/valhalla.

Работает на Linux и Mac OS и частично на Windows.

Valhalla состоит из нескольких библиотек, каждая из которых отвечает за свою функцию. Расположение различных функций по библиотекам выглядит следующим образом:

Midgard - базовые географические и геометрические алгоритмы для использования в различных других проектах.

Baldr - базовые структуры данных для доступа и кэширования данных маршрута.

Sif - библиотека, используемая при расчете стоимости узлов графа. Это может быть использовано в качестве входных данных для Loki и Thor.

Skadi - библиотека и сервис для доступа к данным о высоте. Это может быть использовано в качестве входных данных для Mjolnir или в качестве автономной службы.

Mjolnir - Инструменты для превращения открытых данных в части графа Valhalla.

Loki - библиотека, используемая для поиска участка графа и корреляции входных местоположений с объектом внутри участка. Эта коррелированная сущность (ребро или вершина) может использоваться в качестве входных данных для Thor.

Meili - библиотека, используемая для сопоставления карт.

Thor - библиотека, используемая для создания пути через иерархию участков графа. Этот путь и атрибуция вдоль пути могут быть использованы в качестве входных данных для Odin.

Odin - библиотека, используемая для создания маневров в пути. Этот набор информации о направлениях может использоваться в качестве входных данных для Tyr.

Tyr - сервис, используемый для обработки http-запросов для маршрута, связывающегося со всеми другими API valhalla. Tyr форматирует вывод из Odin.

Установка

Если у Вас Ubuntu 20.04 отличный гайд по установке.

Здесь можно скачать карты, выбрав нужные регионы.

Для ЦФО РФ

curl -O http://download.geofabrik.de/russia/central-fed-district-latest.osm.pbf

Рендерим карты

valhalla_build_tiles -c ./conf/valhalla.json central-fed-district-latest.osm.pbf

Запускаем

valhalla_service ~/valhalla/scripts/conf/valhalla.json 2

Давайте найдем маршрут на автомобиле из Москвы в Подольск

curl http://localhost:8002/route \--data '{"locations":[              {"lat":55.7522,"lon":37.6156},              {"lat":55.4242,"lon":37.5547}           ],         "costing":"auto"        }' | jq '.'

В ответ получаем JSON с узловыми токами маневров.

Файл навигации в Тесла

Я обратился https://teesla.ru/ и мне передали файл с европейской навигацией из Тесла. Весит файл около 8гб и на мое удивление содержит вовсе не карты, а уже проложенные пути.

Карты Tesla подгружает из Google, как и данные о зарядках, часть ограничений скорости. Данные в файле навигации представляют собой скомпилированные графы пути.

Для адресов используются данные из карт Tomtom

Файл карт в файловой системе Squashfs (.sfs)

Последние 2кб очень странные, в них и вся соль. Файлы подписаны ключом. Шифрование AES.

При загрузке карт в машину, Тесла проверяет подпись поэтому модифицированные карты не удалось загрузить.

P.S.

Можно ли подписать карты? Найти ключ и порядок S-box? Тесла на Тегра хранят файл навигации на отдельной карте памяти в MCU. Тесла на Intel хранят файл навигации на в основной eMMC. С картой памяти все просто, разбираем половину торпеды, вытаскиваем из MCU, заливаем дамп с картами и вставляем обратно, с eMMC не так все однозначно. Если карты просто залить на чип eMMC, апдейтер в автомобиле с живыми сертификатами загрузит обновление и заменит их.

От cебя готов предоставить приз целый день аренды самой заряженной Tesla model 3 Performance за способ генерации и загрузки карт в Tesla model 3 с РФ. Пишите в личку.

Всем привет. Я android разработчик с небольшим стажем. И сегодня я бы хотел поделиться опытом разработки учебного проекта на C++ и Qt с простой навигацией между экранами. Буду рад услышать критику или дополнения к моему решению и надеюсь, что оно сможет кому-то помочь и упростить жизнь.

Задача

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

У меня была идея проекта, что-то вроде упрощенной версии Trello, но для ее реализации нужно было определиться с тем, как будет осуществляться смена контента в окне. Какие вообще есть варианты? Мы можем создавать разные окна на каждую задачу, но такой вариант плохо сказывается на пользовательском опыте и не нравится мне.

Чтобы отказаться от главного окна, нужно написать навигатор, который будет уметь заменять экраны внутри QStackedWidget и предоставит различные сценарии переходов от одного экрана к другому. Также необходимо знать о предыдущих экранах для возможности вернуться к ним и как-то передавать данные.

На изображении ниже представлена схема приложения и переходы. Когда приложение запускается, мы видим заставку, потом выполняется замена экрана на стартовый или на главный. При этом вернуться с главного экрана на загрузку мы не можем.

В итоге, посмотрев на схему, мы можем составить небольшой список подзадач, которые хотим реализовать:

1. Общий родитель у экранов для реализации взаимодействий.

2. Фабрика экранов.

3. Определение команд для навигации у экранов.

4. Хранение стека экранов.

Общая модель экрана

Очевидный этап проработки навигатора вынесение связанных с ним методов в отдельный класс BaseFragment. Это базовый экран, от которого мы унаследуем все остальные. Пока это просто абстракция, но мы к нему еще вернемся и допишем.

class BaseFragment: public QFrame {    Q_OBJECTsignals:    //тут мы потом определим сигналы для навигатора public:    BaseFragment();    ~BaseFragment();    //тут реализуем что-то из жизненного цикла};

Далее реализуем несколько экранов опираясь на BaseFragment. Каждый из фрагментов является виджетом, который мы можем поместить в QStackedWidget и выбрать отображаемый.

class LoginFragment: public BaseFragmentclass StartFragment: public BaseFragmentclass RegistrationFragment : public BaseFragment

Фабрика фрагментов

После того, как мы сделали несколько фрагментов, нам нужно создать фабрику экранов, чтобы сделать навигацию независимой от конкретно этого проекта. Реализация навигации из проекта в проект не будет меняться, достаточно определить правило, по которому мы будем создавать экраны.

class BaseScreensFactory {public:    BaseScreensFactory();    ~BaseScreensFactory();    virtual BaseFragment* create(QString tag);    virtual QString createStart();};

Фабрика имеет всего два виртуальных метода:

1. create(QString tag) создает экран по его идентификатору (идентификатор мы указываем в конкретной реализации фабрики);

2. createStart() возвращает идентификатор стартового экрана.

Ниже реализация фабрики в моем проекте:

// screensfacrory.h заголовочный файлnamespace screens {    static const QString SPLASH_TAG = "splash";    static const QString START_TAG = "start";    static const QString LOGIN_TAG = "login";    static const QString REGISTRATION_TAG = "registration";  // и так далее.....};class ScreensFactory: public BaseScreensFactory {public:    ScreensFactory();    ~ScreensFactory();    BaseFragment* create(QString tag) override;    QString createStart() override;};// screensfacrory.cpp исходникиBaseFragment* ScreensFactory::create(QString tag) {    qDebug("ScreensFactory create");    if (tag == SPLASH_TAG) {        return new SplashFragment;    } else if (tag == START_TAG) {        return new StartFragment;    } else if (tag == LOGIN_TAG) {        return new LoginFragment;    } else if (tag == REGISTRATION_TAG) {       // и так далее.....    }}QString ScreensFactory::createStart() {    return SPLASH_TAG; // идентификатор стартового экрана.}

Наконец сама навигация

Когда у нас есть модель экрана и фабрика, создающая эти экраны по названию, мы можем написать класс, который будет получать от текущего экрана название следующего и создавать его. Далее новый экран будет добавляться в QStackedWidget контейнер и показываться пользователю.

Нужные нам методы навигации:

• navigateTo(tag) переход к новому экрану с добавлением этого экрана в цепочку открытых живущих.

• back() переход к предыдущему экрану с в цепочке с удалением текущего из нее.

• replace(tag) замена текущего экрана в цепочке на новый.

• newRootScreen(tag) удаление текущей цепочки и создание нового экрана.

• navigateToWhithData(tag, data) то же самое, что и navigateTo(tag), только вместе с именем экрана передается ссылка на какой-то объект.

Например, когда мы открываем экран с регистрацией, находясь на экране приветствия, выполняется метод navigateTo(REGISTRATION_TAG), после регистрации нужно открыть главный экран, но запретить переход назад. Для этого выполняем newRootScreen(MAIN_TAG).

Чтобы навигатор понимал, что нужно текущему фрагменту, в класс BaseFragment нужно дописать сигналы для методов навигации, описанных выше.

class BaseFragment: public QFrame {    Q_OBJECTsignals:  //дописанные сигналы    void back();    void navigateTo(QString tag);    void newRootScreen(QString tag);    void replace(QString tag);        void navigateWhithData(QString tag, BaseModel* model); public:    BaseFragment();    ~BaseFragment();  //дописанные методы для жизненного цикла    virtual void onPause();    virtual void onResume();    virtual void setData(BaseModel* model);};

Поскольку фрагменты не все время находятся на экране, мы можем ставить на паузу процессы, выполняющиеся в нем, вызывая onPause(), и возобновлять, вызывая onResume() из навигатора, который мы скоро напишем. И метод setData() мы вызываем при передаче данных в фрагмент.

После долгих подготовок переходим к написанию навигации. Навигатор будет получать QStackedWidget как контейнер для фрагментов и BaseScreensFactory для создания фрагментов.

navigator.h:

class Navigator: public QObject {    Q_OBJECTprivate:    QStackedWidget *currentContainer;    BaseScreensFactory *screensFactory;    QLinkedList<BaseFragment*> stack;    /**     * @brief createAndConnect     * @param tag тэг создаваемого фрагмента.     *     * Создание фрагмента по тегу и его     * прикрепление к навигатору.     *     * @return фрагмент присоединенный к слотам навигатора.     */    BaseFragment* createAndConnect(QString tag);    /**     * @brief connectFragment     * @param fragment фрагмент который переходит     *        в активное состояние.     *     * Прикрепление текущего фрагмента     * к слотам навигатора для быстрого     * и удобного перехода между экранами.     *     */    void connectFragment(BaseFragment *fragment);    /**     * @brief disconnectFragment     * @param fragment     *     * Отключение сигналов от фрагмента.     */    void disconnectFragment(BaseFragment *fragment);public:    Navigator(            QStackedWidget *container,            BaseScreensFactory *screensFactory    );    ~Navigator();    BaseFragment* getStartScreen();public slots:    /**     * @brief navigateTo     * @param tag имя следующего экрана.     *     * Переход к следующему экрану.     */    void navigateTo(QString tag);    /**     * @brief back     *     * Переход назад по цепочке.     */    void back();    /**     * @brief replace     * @param tag имя экрана на который     *        произойдет замена.     *     * Замена текущего экрана с сохранением     * предыдущей цепочки.     */    void replace(QString tag);    /**     * @brief newRootScreen     * @param tag имя экрана на который     *        произойдет замена.     *     * Замена текущего экрана на новый и сброс     * всей цепочки экранов.     */    void newRootScreen(QString tag);    /**     * @brief navigateWhithData     * @param model     *     * Тот же navigateTo но с данными.     */    void navigateWhithData(QString tag, BaseModel* model);};

Во время смены экранов происходит немного магии с их заменой. При создании фрагмента его сигналы нужно прикрепить к слотам навигатора. При смене фрагмента текущий нужно открепить от слотов и прикрепить новый. connectFragment присоединяет все слоты к сигналам, после этого навигатор управляется этим фрагментом. disconnectFragment открепляет все сигналы. createAndConnect создает фрагмент по его имени через фабрику и сразу прикрепляет его к навигатору. getStartScreen создает стартовый экран по имени, указанному в фабрике, и прикрепляет его к навигатору.

BaseFragment* Navigator::getStartScreen() {    return createAndConnect(this->screensFactory->createStart());}void Navigator::connectFragment(BaseFragment *fragment) {    connect(fragment, &BaseFragment::back, this, &Navigator::back);    connect(fragment, &BaseFragment::replace, this, &Navigator::replace);    connect(fragment, &BaseFragment::navigateTo, this, &Navigator::navigateTo);    connect(fragment, &BaseFragment::newRootScreen, this, &Navigator::newRootScreen);    connect(fragment, &BaseFragment::navigateWhithData, this, &Navigator::navigateWhithData);}void Navigator::disconnectFragment(BaseFragment *fragment) {    disconnect(fragment, &BaseFragment::back, this, &Navigator::back);    disconnect(fragment, &BaseFragment::replace, this, &Navigator::replace);    disconnect(fragment, &BaseFragment::navigateTo, this, &Navigator::navigateTo);    disconnect(fragment, &BaseFragment::newRootScreen, this, &Navigator::newRootScreen);    disconnect(fragment, &BaseFragment::navigateWhithData, this, &Navigator::navigateWhithData);}BaseFragment* Navigator::createAndConnect(QString tag) {    BaseFragment *fragment = this->screensFactory->create(tag);    connectFragment(fragment);    return fragment;}

В конструкторе сохраняем ссылки на контейнер и фабрику, создаем стартовый фрагмент и кладем его в контейнер.

Navigator::Navigator(        QStackedWidget *container,        BaseScreensFactory *screensFactory) {    this->screensFactory = screensFactory;    this->currentContainer = container;    BaseFragment* startFragment = getStartScreen();    this->stack.append(startFragment);    currentContainer->addWidget(stack.last());    currentContainer->setCurrentIndex(0);}

Остается только прописать каждый слот. В слотах нет ничего сложного: чтобы не плодить плашки с кодом я приведу только реализацию navigateTo. В нем мы создаем новый фрагмент по идентификатору, затем тормозим текущий фрагмент и открепляем от навигатора. Далее прикрепляем новый фрагмент и добавляем его в контейнер.

void Navigator::navigateTo(QString tag) {    BaseFragment *newFragment = this->screensFactory->create(tag);    stack.last()->onPause();    disconnectFragment(stack.last());    connectFragment(newFragment);    stack.append(newFragment);    currentContainer->addWidget(newFragment);    currentContainer->setCurrentWidget(newFragment);}

Когда навигатор написан, можно создать его экземпляр и передать в него ссылки на контейнер и фабрику. Это все, что нужно написать в главном окне. Все остальные изменения будут касаться только фабрики фрагментов и самих фрагментов.

MainWindow::MainWindow(QWidget *parent)    : QMainWindow(parent){       try {        container = new QStackedWidget;        this->factory = new ScreensFactory;        this->navigator = new Navigator(                    this->container,                    this->factory        );        this->setCentralWidget(container);    } catch (std::exception& e) {        qDebug("%s", e.what());    }}

Взгляд со стороны

Сейчас мы посмотрели на большое количество кусочков кода, сперва может показаться, что они мало чем связаны. После долгих попыток разобраться это ощущение не пропадает, и это на самом деле хорошо. В итоге мы получили возможность разрабатывать различные экраны приложения абсолютно независимо от остальных частей. Мы пишем реализацию BaseFragment и добавляем ее в фабрику.

Мне мое решение очень помогло в реализации проекта. Я смог ускорить разработку и разделить код.

Всем дочитавшим спасибо, надеюсь кому-то это поможет.

Вот ссылка GitHub проекта

Привет Хабр! Представляю вашему вниманию перевод статьи Mafia: Definitive Editions Clever Navigation System автора Tushar Deb.

Размер игр с открытым миром становится больше с каждым новым релизом: большие карты, больше исследований и еще больше перемещений. Исключение составляют относительно линейные проекты, в которых игроки могут двигаться одними и теми же путями. Например, в серии Need for Speed или Grand Theft Auto: Vice City, где игрок быстро запоминает маленький открытый мир и легко в нем ориентируется. В противном случае искать удобный и короткий путь в опенворлде не самое увлекательное занятие.

И вот тут на помощь приходят мини-карта и метки отмечаете точку и следуете маршруту. Легко!

Но как сделать эту навигационную систему более захватывающей? Как найти способ, который дает игроку новый опыт, а не добавляет рутины?

Игра происходит не на мини-карте, а на гораздо большей области экрана. Мини-карта помогает игроку получить информацию об окружении, которая существует за границами области игрового экрана. Тогда почему игрок смотрит на мини-карту чаще, чем на игровой мир?

В Mafia: Definitive Edition проделана огромная работа по интеграции навигационной системы в окружающую среду игры. Это дало гораздо более захватывающий опыт, который не кажется рутиной, а наоборот добавляет естественного реализма.

Вы не найдете эту навигационную систему в оригинальной Mafia, в которой обычная система посмотрите на мини-карту, как, например, в Red Dead Redemption 2. Мир RDR2 огромен, без меток в нем не обойтись, поэтому постоянно приходится смотреть на мини-карту, отвлекаясь от происходящего на экране.

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

Когда я спешу в игре, то мой навигационный игровой опыт выглядит примерно так:

Так происходит потому, что я не смотрю на игровой экран, который на самом деле занимает большую часть монитора. Когда я перемещаюсь в открытом мире, я по факту смотрю на мини-карту.

Конечно, в других проектах тоже придумали неплохие решения. Например, в Far Cry 5 синие направляющие на дороге помогают сориентироваться, не отвлекаясь на мини-карту.

Но, я считаю, Mafia: Definitive Edition сделала это лучше всех. Вы едете по городу, и что может быть лучше, чем поставить навигационные дорожные знаки, которые реалистично интегрируются в открытый мир.

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

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