Создание собственной системы стабилизации
Достаточно просто заменить папку ArduCopter и перекомпилить. Сергей правда туда тоже какие то изменения вносил, но скорей всего без этого можно обойтись, будет время - проаналитим.
Вы походу не понимаете. Смотрите, завтра, например, дидроновцы выпускают APM:Copter 3.2, вы делаете клон этой версии и патчите ее под F4BY, заливаете новые исходники в гитхаб и выпускаете 3.2 RC1. Через день, вы находите ошибку в вашем порте, но дидроновцы то на месте не стоят, они уже новых правок напостили в гитхаб - вам эти правки не нужны для выпуска 3.2 RC2. Вот тут вам, нужна отдельная ветка, где вы будете делать порт именно 3.2, потому что таких итераций может быть несколько, всегда после тестирования вылазит что то новенькое.
Точно, только он должен быть портирован ну например с “ленинградского” и обязательно че-то в нем не совсем должно быть как положено.
применительно к торту - это уже совсем другой торт получится 😃
Одно радует с моего git скорость хорошая 😃
Вы походу не понимаете.
Понимаю.
Через день, вы находите ошибку в вашем порте,
Это вряд ли 😃 Там не так много изменений и надеюсь постоянно их делать не надо будет. Кроме того все косяки можно выловить при тестах не запуская АПМ, прямо из терминала Нутекса. За саму работу АПМ, ессесно, мы отвечать не можем, ибо в нём мы никаких изменений не делаем.
Т.е. если выходит новый релиз АПМ и он безглючно работает (либо иное не замечено) на ПХ4 и Пиксхавке, то он ровно также будет работать и на F4BY.
надо менять ardupilot / libraries / AP_HAL_PX4 / AnalogIn.cpp
ardupilot / libraries / AP_HAL_PX4 / HAL_PX4_Class.cpp
ardupilot / mk / PX4 / ROMFS / init.d / rc.APM
изменения там копеешные, да и сами либы меняются редко, стало быть их особо трогать не нужно. Менять только АПМ.
Вот только меня терзают смутные сомнения, как бы дидронсы не начали бороться с чужим железом проверкой настроек периферии прямо из кода АПМ. Хотя такой вариант убьет все прелести ХАЛа для них самих.
Это вряд ли Там не так много изменений и надеюсь постоянно их делать не надо будет. Кроме того все косяки можно выловить при тестах не запуская АПМ, прямо из терминала Нутекса. За саму работу АПМ, ессесно, мы отвечать не можем, ибо в нём мы никаких изменений не делаем.
Это точно не на вряд ли. Я вчера наткнулся на косяк с компасом и на данный момент не понятно откуда он вылез. Компас оказался повернут на 45градусов. Опять таки, код написан так, что ориентацию компаса нельзя сменить в планере (игнорируется) - а это значит, что скорее всего надо будет менять код (возможно конечно поможет очистка mtd как писал Сергей, но что то я не верю) - вот тебе и вторая версия, а я только начал тестировать.
Кроме этого, как то странно работает USB COM порт. Я к сожалению не знаю как работает он у PX4, но тут что то не так. Если подключится терминалом к COM порту, почти сразу после подачи питания на плату, то терминал быстренько отваливается. Я подозреваю, что COM порт отключается после запуска Nuttex и передачи управления в APM. Если дождатся пока светодиод быстро проморгается и потом подключится - все нормально, пока не сделаешь ребут плате - после этого порт опять не коннектится.
Компас оказался повернут на 45градусов. Опять таки, код написан так, что ориентацию компаса нельзя сменить в планере (игнорируется) - а это значит, что скорее всего надо будет менять код (возможно конечно поможет очистка mtd как писал Сергей, но что то я не верю) - вот тебе и вторая версия, а я только начал тестировать.
45 это странно, кратно 90 может быть. Надо бы проверить данные через терминал, в терминале набрать hmc5883 и он выдаст подсказку по командам.
Кроме этого, как то странно работает USB COM порт.
это не косяк 😃 это режим прошивки, сразу после сброса запускается лодырь, который быстро мигает СВД. А после нескольких секунд запускается нутекс и АПМ.
вот тебе и вторая версия, а я только начал тестировать.
это аномалия 😃 - у меня такая же плата и та же прошивка - и север у меня на севере 😃
Если дождатся пока светодиод быстро проморгается и потом подключится - все нормально, пока не сделаешь ребут плате - после этого порт опять не коннектится.
я ж тебе вроде вчера объяснял - да и мы в первой версии с этим напоролись (вместо специфического порта A9 у меня резюк на D+ 1.5К висел для определения платы и наттикс не детектился ибо комп не понимал что лодырь кончился и это уже другое устройство) - оно чё делает - работает лодырь - если подключен по усб (ели усб не подключен он сразу переходит к исполнению программы - моргать не будет) - потом он отсоединяет устройство и вместо этого устройства на тот же порт! цепляет другое 😃 я не знаю почему так сделано, например те же ОР идут как HID совместимые устройства и качелей таких с отключением - подключением нет… тоже самое ты на своих платах (Атмегах) через ftdi цепляешься - и компу пофиг, что ты ресет жал… в терминале например перезагрузка проходит сама без последствий - пишет порт занят - потом ребутит сам плату и опа мы в терминале…
Компас оказался повернут на 45градусов.
Это наш косяк, ибо порт делали новый на новую плату. Исправимся.
Это наш косяк, ибо порт делали новый на новую плату. Исправимся.
но у меня то его нет?
Ты подключайся быстрее - знаешь как весело 😃
так, приду домой залью прошивку проверю 😃
Я тут вычитал (но не проверял), что если достать SD карточку, то APM не загрузится, но: При этом на USB порту будет работать NSH Shell - а значит можно и команды в нем подавать 😃 Например те что Сергей писал про стирание mtd.
Например те что Сергей писал про стирание mtd.
это по моему в более новой версии, которую я ещё не запустил, но попробуй 😃
не помню - но пока не запущен Арду - тест баро точно возвращался с ошибкой - а вот компаса не помню 😦
MPU то тестится…
Чё хотел спросить - я у себя сделал отдельные ветки дабы мастер не портить пока, они как-нибудь должны отражаться в гит? коммиты делал…
Свежая паршивка не летающая!!! правда моторы не запустил, но компас проверить можно:
И ещё есть странность - почему мне приходится светодиоды переворачивать ? в старой понятно - но и тут всё наизнанку?
Вот загадка:
[boot] Successfully initialized SPI port 1
[boot] Initialized SPI port2
[boot] Successfully bound SPI port 2 to the MMCSD driver
[boot] Initializing SPI port 3
[boot] Successfully initialized SPI port 3
rgbled: init failed
[init] looking for microSD...
[init] card mounted at /fs/microsd
sercon: Registering CDC/ACM serial driver
sercon: Successfully registered the CDC/ACM serial driver
[init] USB interface connected
Running rc.APM
Mounting binfs
binfs mounted OK
removed old boot.log
Detected FMUv1 board
[uorb] ready
uorb started OK
[PX4IO_i2c] on I2C bus 2 at 0x1a
<px4io> io_reg_get(0,0,1): data error -6
[px4io] protocol/firmware mismatch
px4io: driver init failed
Loading /etc/px4io/px4io.bin
[PX4IO] using firmware from /etc/px4io/px4io.bin
[PX4IO] bootloader not responding
px4io: error updating PX4IO - check that bootloader mode is enabled
Failed to upgrade PX4IO firmware
[PX4IO_i2c] on I2C bus 2 at 0x1a
<px4io> io_reg_get(0,0,1): data error -6
[px4io] protocol/firmware mismatch
px4io: driver init failed
No PX4IO board found
Setting FMU mode_pwm
[fmuservo] default PWM output device
<fmuservo> MODE_8PWM
<fmuservo> set_pwm_rate 0 50 50
[fmuservo] starting
<fmuservo> adjusted actuator update interval to 20ms
Starting APM sensors
[MS5611_I2C] on I2C bus 2 at 0x77
ms5611 started OK
<adc> init done
adc started OK
Starting FMUv1 sensors
[HMC5883] on I2C bus 2 at 0x1e
hmc5883 started OK
hmc5883: starting mag scale calibration
hmc5883: axes scaling: 1.124398 1.035146 1.135034
hmc5883: mag scale calibration successfully finished.
hmc5883: PASS
hmc5883 calibrate OK
<MPU6000> ID 0x58
[MPU6000] on SPI bus 1 at 3
mpu6000 started OK
<L3GD20> probe failed
l3gd20: driver start failed
No l3gd20
[Airspeed] i2c::transfer returned -110
<Airspeed> probe failed
ets_airspeed: driver start failed
<Airspeed> probe failed
<Airspeed> probe failed
meas_airspeed: driver start failed
Trying PX4IO board
mtd: Creating partitions
mtd: Partition 0. Block offset=0, size=256
started mtd driver OK
reading /fs/mtd expecting 8192 bytes
readtest OK
mtd readtest OK
Starting ArduPilot /dev/ttyACM0 /dev/ttyS1 /dev/null
Starting ArduCopter uartA=/dev/ttyACM0 uartC=/dev/ttyS1 uartD=/dev/null
initialised /dev/ttyACM0 OK 16384 1024
initialised /dev/ttyS2 OK 1024 512
initialised /dev/ttyS1 OK 1024 512
ArduPilot started OK
rc.APM finished
NuttShell (NSH)
nsh> <fmuservo> MODE_2PWM
<fmuservo> set_pwm_rate 0 50 50
<fmuservo> set_pwm_rate 0 50 490
<fmuservo> set_pwm_rate 0 50 490
<fmuservo> set_pwm_rate 0 50 490
<fmuservo> set_pwm_rate f 50 490
<fmuservo> set_pwm_rate f 50 490
<fmuservo> set_pwm_rate f 50 490
<fmuservo> adjusted actuator update interval to 2ms
стартует как MODE_2PWM, хотя задано MODE_8PWM - и нигде не могу найти, на прошлой прошивке запускались все 8, а раньше я и 12 запускал…
По моему уже спрашивал, - неужели портирование чужого софта проще, чем написать свой, или хотябы использовать частично,…???.
Или там так все понятно, что только “хедеры” читай и исправляй ? (для меня - темный лес, даже связываться не хочу…)
это по моему в более новой версии, которую я ещё не запустил, но попробуй
Проверил, работает и на твоей версии! Только как обычно, COM порт надо открывать после того как проморгается светодиод, а после подключения нажать <enter> - тогда появится приглашение nsh>
Это наш косяк, ибо порт делали новый на новую плату. Исправимся.
но у меня то его нет?
Я подумал что это новый порт, полез в гит, а там чехарда со знаками.
Ты подключайся быстрее - знаешь как весело
Не… АПМ мне не интересен, я слишком много протопал своими ногами. Вот если б я только сейчас в это ввязывался, то АПМ меня вполне бы устроил. А 3 года назад, кода я купил АПМ1, один день в руках его покрутил и бросил на полку, так он и валяется.
Но помогать не отказываюсь, новый порт добъём.
стартует как MODE_2PWM, хотя задано MODE_8PWM - и нигде не могу найти, на прошлой прошивке запускались все 8, а раньше я и 12 запускал…
это поправимо, ты в гит всё делаешь?
По моему уже спрашивал, - неужели портирование чужого софта проще, чем написать свой, или хотябы использовать частично,…???.
Портирование проще, ибо можно не вникать в математику совсем, а сосредоточится на привязках к железу. Для АПМ с Нутексом сложность составляла в понимании структуры Нутекса и его “склейки” с АПМ. После того как понимание появилось всё стало крайне просто, и в сам код АПМ ни заглядывать не править совершенно не нужно.
Сергей, ты можешь выложить именно патч своих исправлений в PX4? Да и вообще, ты на каких ревизиях базируешь свои правки, надеюсь не на самых свежих правках из GIT?
Тот патч, что выкладывал - там файлы только те которые правил (правки все подписаны) - они практически неизменны (ну если драйверов MPU и HMC не считать) сейчас да воюю со свежими - пытаюсь понять что намудрили с портами это уже где-то с начала февраля такое (выходы ШИМ)…
в остальном впринципе можно брать любую версию…
с патча - с помощью сравнения файлов (я пользую meld - есть в репозитории убунты) в течении пары минут патчится…
та версия, что залита в платы облётана мной лично на старой плате…
вечером могу пропатчить то что у меня в гит но получится прошивка отсюда rcopen.com/forum/f134/topic224458/4166
она не работает (моторы)
Тот патч, что выкладывал - там файлы только те которые правил - они практически неизменны (ну если драйверов MPU и HMC не считать) сейчас да воюю со свежими - пытаюсь понять что намудрили с портами это уже где-то с начала февраля такое (выходы ШИМ)… в остальном впринципе можно брать любую версию…
Нельзя делать порт на базе свежей версии в GIT - пока не выйдет версия, там может быть полнейший хлам и нерабочий код. Сами дидроновцы постоянно в рассылке пишут что мол, добавлена такая то фича, пользуйте на свой страх и риск, т.к. не протестировано.
Конкретно сейчас, они тестируют новое ядро навигации и ИНС - Onion5, вроде уже более менее рабочее оно, но нам зачем быть бета тестерами их кода?
Ладно, тогда давайте так, вы балуетесь с последними исходниками. А я буду портировать последнюю релизную версию.
Ладно, тогда давайте так, вы балуетесь с последними исходниками. А я буду портировать последнюю релизную версию.
3.1.2 релиз не вопрос, но в px4Firmware и PX4NuttX - нет релизов 😦 они такие какие есть… а арду без разницы - мы его и не трогаем…
если я сейчас свой гит обновлю - последствий для дийдроносов надеюсь не будет? а то как-то странновато выглядит - их бранчи у меня есть, а моих я не вижу?
3.1.2 релиз не вопрос, но в px4Firmware и PX4NuttX - нет релизов
Как это нету, есть, тегами помечены.
Смотри Арду github.com/…/8a10427cdee1fdb0acee4204d3505644cdd48…
если успею сейчас и PX4Firmware сделаю…
ну по крайней мере наглядно будет где что меняю…
Вот и всё остальное github.com/…/18bbd65fe7935c2e70fd37b453f3b60c44b66…
но это уже не катит - запустятся только два выхода из восьми 😦
в понимании структуры Нутекса
Мне интересно (на будущее),: а как ведет себя сей Нутекс (и ему подобные) при зависании, скажем одной из активных задач/потоков, ??? (в смысле остальные будут ли жить ?)
Кто юзал на практике РТО-сы ???
зависании, скажем одной из активных задач/потоков, ???
на арде проверил - работает 😃 арду виснет (затык в драйвере был) - датчики спокойно опрашиваю 😃 ось в любом случае имеет высший приоритет…
датчики спокойно опрашиваю
По аналогии, та же “винда” в основном вспотыкалась именно о периферию (любили микрософт засунуть драйвер в ядро для быстродействия), тут конечно уже надо конкретно с STM разбираться… но уже что-то… 😃
Ну тут какбы палка о двух яйц концах получается - с одной стороны многопоточность и все дела, а с другой ось в приоритете и жизненно важное прерывание отправит там по парку погулять - мол не до тебя щяс - я тут контрольную сумму решила посчитать(образно), а ты лезешь… Полётник должен быть тупым мосхом его задача знать и исправлять положение и на комманды реагировать безпрекословно и не задумываться о том правильные они по его мнению или нет (в смысле адекватные комманды)…
Кто юзал на практике РТО-сы ???
Если зависает задача в ртос, хотя не так, задач как таковых нет, есть один код ртос, который по системному прерыванию выполняет куски кода нескольких процедур (задач). Если виснет одна “задача”, то виснет весь ртос. Это не х86 с аппаратной поддержкой многозадачности.
на арде проверил - работает арду виснет (затык в драйвере был) - датчики спокойно опрашиваю ось в любом случае имеет высший приоритет…
Это тебе так кажеццо. Арду виснет программно, но не аппаратно.