Category Без рубрики

Как чекаютятся репозитоии в windows в таком случае: используется file схема пути, т.е. например  file://server/svn/MyProject и всё работает отлично.

И вот настал тот час, когда мне стало необходимо зачекаутить этот репозиторий и из под Linux-а. Тут ждёт первая проблема: file схема на линуксе работает только с локальными путями! Все остальные требуют сервера на удалённом компьютере (что у меня сейчас не возможно). Первое решение очевидное – просто монтируем сетевую папку например в /mnt/svn и оттуда чекаутим file:///mnt/svn/MyProject  и это действительно отлично работает! Кроме одного косяка… Работая под Windows-ом в репозиторий MyProject я добавил внешний (external) репозиторий MyProject2! И конечно же до него путь сохранился такой: file://server/svn/MyProject2  и при чекауте MyProject SVN не может слить его зависимость по пути file://server/svn/MyProject2.

То есть по хорошему у меня должен работать чекаут точно по тем же путям, что и в windows, что проблематично, но не возможного же не бывает…

if (strcmp(hostname, "localhost") == 0)
    hostname = NULL;

if (strcmp(hostname, "localhost") == 0 || strcmp(hostname, "server") == 0)
    hostname = NULL;

 
   sudo apt-get install autoconf
   sudo apt-get install libtool-bin
   sudo apt-get install apache2-dev libapr1-dev libaprutil1-dev
   sudo apt-get install zlib1g-dev

   ./get-deps.sh
   cd apr/
   ./buildconf
   cd ../apr-util/
   ./buildconf
   cd ../apr-util/xml/expat/
   ./buildconf.sh
   cd ../../..
   ./autogen.sh
   ./configure
   make //в папке subversion

    sudo make install

А вот и нет. Память “побита” на блоки по 256 байт, выбор ID блока происходит через запись соответствующего ID в биты 1,2,3 байта адреса устройства:

Их можно трактовать как ID 256-байтного блока или просто как старшие дополнительные 3 бита адреса памяти (как в таблице и указано). То есть адресация здесь 11 битная.

Собственно, адрес _устройства_ получаем таким образом:  0xA0 | ((memory_address >> 7) & 0xE).  Нулевой бит по идее контроллируется библиотекой и делать операцию битового чтения & 0xF по идее не нужно. Но опыт подсказывает, что доверять библиотеке Cube от ST не стоит )

Вдруг кому сэкономит время )

Для генерации разрешения 800×600 необходимо во-первых заменить параметры таймингов в файле HDMI_1280.v на эти

always @(posedge pixclk) DrawArea <= (CounterX<800) && (CounterY<600); 
always @(posedge pixclk) CounterX <= (CounterX==1055) ? 0 : CounterX+1; 
always @(posedge pixclk) if(CounterX==1055) CounterY <= (CounterY==627) ? 0 : CounterY+1;
always @(posedge pixclk) hSync <= (CounterX>=840) && (CounterX<968);
always @(posedge pixclk) vSync <= (CounterY>=601) && (CounterY<605);

А так же сгенерить свою PLL с 2 выходами клоков на 40MHz и на 200MHz. 40MHz – частота тактования пикселей, с ней всё ясно, а вот 200 MHz это частота тактования TMDS энкодеров (в HDMI применяется TMDS 10 битное кодирование), они тактоваться должны на частоте в 10 раз быстрее пиксельклоков, однако т.к. используются DDR выходы ПЛИС-а, частота тактования TMDS делится на 2, итого (40*10)/2 = 200MHz

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

Щёточный DC схематически можно представить так:

R – сопротивление обмотки ротора.
L – индуктивность обмотки ротора
e – обратная ЭДС обмоток ротора.
J – момент инерции ротора

Из за вращения ротора в статичном магнитном поле в его обмотках появляется обратная ЭДС, создающая обратное напряжение в обмотках, которое ограничивает максимальные обороты движка (но не только оно ограничивает). Зависит линейно от угловой скорости ротора.

Так же есть ЭДС самоиндукции, появляющаяся при изменении тока, проходящего по обмоткам.
E = – L* (dI/dt)
– как видно тут участвует производная тока и самоиндукция будет влиять на работу мотора только когда ток меняется, КЭП.

e – величина линейная, зависит от угловой скорости ротора, равна k_e * w. k_e – константа обратной ЭДС.

Пользуясь вторым правилом Кирхгофа можно записать уравнение напряжения в моторе:

Vs = R*I + L*(dI/dt) + e;

тут Vs – напряжение питания мотора.

Не сложно переписать уравнение так, что бы выразить производную тока:

dI/dt = (Vs – (R*I) – e) / L;

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

Me = Mm + Mf + Ml

Me = электрический крутящий момент, т.е. момент, сгенеренный обмотками ротора.

Mf – момент трения ротора, линейно зависит от угловой скорости, k_f * w,
Ml – момент внешней нагрузки на ротор.

w – угловая скорость ротора [рад/с]

т.е. Me = J*(dw/dt) + k_f*w + Ml;

Тут есть важная штука: “электрический” момент линейно зависит от тока на обмотках якоря и его коэффициент является одной из важнейших характеристик моторов. То есть “электрический” момент (Me) = k_t * I;

k_t * I = J*(dw/dt) + k_f*w + Ml;

Выразим производную угловой скорости ротора:

dw/dt = (k_t*I – k_f*w – Ml) / J

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

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

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

Что бы график сошёлся идеально, необходимо было крутить несколько коэффициентов. Это достаточно геморно и потому я использовал алгоритм оптимизации Левенберга-Марквардта для автоматической подстройки параметров ))) Критериями ошибок стали максимумы и производные графиков тока и оборотов мотора, а так же разница между идеальными и реальными экстремумами графиков мощности и эффективности, вот что получилось:

Тут gizmo используется для отрисовки графиков, под ними подложка с текстурой реальных графиков. Всё вполне совпадает )

А вот график по времени. Сначала включается питание мотора и потом по достижению максимальных оборотов питание отключается. Видны 2 всплеска на графиках – большой пусковой ток и выброс в отрицательную сторону при выключении.  Синий график – обороты, красный – ток.

   Что успел запилить:
Напаял железки на борд! 2 RFM70 радио модуля пока на 1 общий SPI, акселерометр BMA280 на отдельный SPI, собрал узел контроля оборотов коллекторного мотора, схемка вышла не сложная ) Через полевой транзистор IRLML2803  ШИМ-ом включаю/отключаю питание у мотора, скважностью пульса регулируются обороты, так же добавлен диод Шоттки в качестве шунта мотора, резистор на 100К что бы не происходило произвольного открывания затвора транзистора если WPM пин в подвешенном состоянии.

   Радио пока через RFM70. Для реального применения в квадрокоптере этот радио модуль не подходит из за малого радиуса действия (метров 10), но хоть что-то. Будет использоваться для передачи команд с пульта на коптер.

auto keyboards = Input::instance()->keyboards();

if(keyboards[0]->get_key_state(0x57)){
gameObject->transform->set_local_position(gameObject->transform->get_local_position() + gameObject->transform->forward() * (deltaTime * move_speed));
}

Так же начал прикручивать AMP рендереры, пока что для параметрических поверхностей, чуть позже сделаю биндинги к полигональным моделям. Таким образом можно будет делать гибридный рендер стандартный (растеризацией полигонов) и Path Tracing-ом.

Сложнейший рендер: сферка отрендеренная трассировщиком пути, в цвете выведены нормали.

Пописываю параллельно с остальными проектами “убийцу Unity” 😀

Что уже есть:
Компонентная система сущностей, иерархии трансформов, шейдеры, система материалов удобная, класс для рисования Gizmo, меши с сабмешами, рендеринг из нескольких камер в кадре и так ещё всякие мелочи)   Скоро добавлю загрузку текстур и мешей.

В коде стабилизации квадрика поправил несколько ошибок, сменил PID контроллер Yaw оси на PD т.к. интеграл ошибки считать по этой оси нельзя, знак ошибки постоянно меняется, стало всё стабильно работать без внезапных улетаний в космос )