Osd service что это

Как удалить OSD_Service

OSD_Service.exe — это исполняемый файл (программа) для Windows. Расширение имени файла .exe — это аббревиатура от англ. слова executable — исполнимый. Необходимо запускать исполняемые файлы от проверенных производителей программ, потому что исполняемые файлы могут потенциально изменить настройки компьютера или нанести вред вашему компьютеру. Бесплатный форум с информацией о файлах может помочь вам разобраться является ли OSD_Service.exe вирусом, трояном, программой-шпионом, рекламой, которую вы можете удалить, или файл принадлежит системе Windows или приложению, которому можно доверять.

Вот так, вы сможете исправить ошибки, связанные с OSD_Service.exe

1. Используйте программу Настройщик Windows, чтобы найти причину проблем, в том числе и медленной работы компьютера.
2. Обновите программу HappyOSD. Обновление можно найти на сайте производителя (ссылка приведена ниже).
3. В следующих пунктах предоставлено описание работы OSD_Service.exe.

Информация о файле OSD_Service.exe

Процесс HappyOSD или OSD не содержит информацию об авторе.

Описание: OSD_Service.exe не является необходимым для Windows. Файл OSD_Service.exe находится в подпапках «C:\Program Files». Известны следующие размеры файла для Windows 10/11/7 16,384 байт (92% всех случаев) или 12,800 байт.
Название сервиса — HappyOSD.
У процесса нет видимого окна. Нет описания файла. Это не системный процесс Windows. OSD_Service.exe способен мониторить приложения. Поэтому технический рейтинг надежности 56% опасности.

Важно: Некоторые вредоносные программы маскируют себя как OSD_Service.exe, особенно, если они расположены в каталоге c:\windows или c:\windows\system32. Таким образом, вы должны проверить файл OSD_Service.exe на вашем ПК, чтобы убедиться, что это угроза. Мы рекомендуем Security Task Manager для проверки безопасности вашего компьютера.

Комментарий пользователя

Лучшие практики для исправления проблем с OSD_Service

Аккуратный и опрятный компьютер — это главное требование для избежания проблем с OSD_Service. Для этого требуется регулярная проверка компьютера на вирусы, очистка жесткого диска, используя cleanmgr и sfc /scannow, удаление программ, которые больше не нужны, проверка программ, которые запускаются при старте Windows (используя msconfig) и активация Автоматическое обновление Windows. Всегда помните о создании периодических бэкапов, или в крайнем случае о создании точек восстановления.

Если у вас актуальные проблемы, попробуйте вспомнить, что вы делали в последнее время, или последнюю программу, которую вы устанавливали перед тем, как появилась впервые проблема. Используйте команду resmon, чтобы определить процесс, который вызывает проблемы. Даже если у вас серьезные проблемы с компьютером, прежде чем переустанавливать Windows, лучше попробуйте восстановить целостность установки ОС или для Windows 8 и более поздних версий Windows выполнить команду DISM.exe /Online /Cleanup-image /Restorehealth. Это позволит восстановить операционную систему без потери данных.

Следующие программы могут вам помочь для анализа процесса OSD_Service.exe на вашем компьютере: Security Task Manager отображает все запущенные задания Windows, включая встроенные скрытые процессы, такие как мониторинг клавиатуры и браузера или записей автозагрузки. Уникальная оценка рисков безопасности указывает на вероятность процесса быть потенциально опасным — шпионской программой, вирусом или трояном. Malwarebytes Anti-Malware определяет и удаляет бездействующие программы-шпионы, рекламное ПО, трояны, кейлоггеры, вредоносные программы и трекеры с вашего жесткого диска.

OSD_Service сканер

Security Task Manager показывает все запущенные сервисы Windows, включая внедренные скрытые приложения (например, мониторинг клавиатуры или браузера, авто вход). Уникальный рейтинг надежности указывает на вероятность того, что процесс потенциально может быть вредоносной программой-шпионом, кейлоггером или трояном.

Бесплатный aнтивирус находит и удаляет неактивные программы-шпионы, рекламу, трояны, кейлоггеры, вредоносные и следящие программы с вашего жесткого диска. Идеальное дополнение к Security Task Manager.

Reimage бесплатное сканирование, очистка, восстановление и оптимизация вашей системы.

OSD Service

ceph-volume scans each host in the cluster from time to time in order to determine which devices are present and whether they are eligible to be used as OSDs.

To print a list of devices discovered by cephadm , run this command:

Using the —wide option provides all details relating to the device, including any reasons that the device might not be eligible for use as an OSD.

In the above example you can see fields named “Health”, “Ident”, and “Fault”. This information is provided by integration with libstoragemgmt. By default, this integration is disabled (because libstoragemgmt may not be 100% compatible with your hardware). To make cephadm include these fields, enable cephadm’s “enhanced device scan” option as follows;

Although the libstoragemgmt library performs standard SCSI inquiry calls, there is no guarantee that your firmware fully implements these standards. This can lead to erratic behaviour and even bus resets on some older hardware. It is therefore recommended that, before enabling this feature, you test your hardware’s compatibility with libstoragemgmt first to avoid unplanned interruptions to services.

There are a number of ways to test compatibility, but the simplest may be to use the cephadm shell to call libstoragemgmt directly — cephadm shell lsmcli ldl . If your hardware is supported you should see something like this:

After you have enabled libstoragemgmt support, the output will look something like this:

In this example, libstoragemgmt has confirmed the health of the drives and the ability to interact with the Identification and Fault LEDs on the drive enclosures. For further information about interacting with these LEDs, refer to device management.

The current release of libstoragemgmt (1.8.8) supports SCSI, SAS, and SATA based local disks only. There is no official support for NVMe devices (PCIe)

Deploy OSDs

Listing Storage Devices

In order to deploy an OSD, there must be a storage device that is available on which the OSD will be deployed.

Run this command to display an inventory of storage devices on all cluster hosts:

A storage device is considered available if all of the following conditions are met:

The device must have no partitions.

The device must not have any LVM state.

The device must not be mounted.

The device must not contain a file system.

The device must not contain a Ceph BlueStore OSD.

The device must be larger than 5 GB.

Ceph will not provision an OSD on a device that is not available.

Creating New OSDs

There are a few ways to create new OSDs:

Tell Ceph to consume any available and unused storage device:

Create an OSD from a specific device on a specific host:

Advanced OSD creation from specific devices on a specific host:

Create an OSD on a specific LVM logical volume on a specific host:

You can use Advanced OSD Service Specifications to categorize device(s) based on their properties. This might be useful in forming a clearer picture of which devices are available to consume. Properties include device type (SSD or HDD), device model names, size, and the hosts on which the devices exist:

Dry Run

The —dry-run flag causes the orchestrator to present a preview of what will happen without actually creating the OSDs.

Declarative State

The effect of ceph orch apply is persistent. This means that drives that are added to the system after the ceph orch apply command completes will be automatically found and added to the cluster. It also means that drives that become available (by zapping, for example) after the ceph orch apply command completes will be automatically found and added to the cluster.

We will examine the effects of the following command:

After running the above command:

If you add new disks to the cluster, they will automatically be used to create new OSDs.

If you remove an OSD and clean the LVM physical volume, a new OSD will be created automatically.

If you want to avoid this behavior (disable automatic creation of OSD on available devices), use the unmanaged parameter:

Keep these three facts in mind:

The default behavior of ceph orch apply causes cephadm constantly to reconcile. This means that cephadm creates OSDs as soon as new drives are detected.

Setting unmanaged: True disables the creation of OSDs. If unmanaged: True is set, nothing will happen even if you apply a new OSD service.

ceph orch daemon add creates OSDs, but does not add an OSD service.

Remove an OSD

Removing an OSD from a cluster involves two steps:

evacuating all placement groups (PGs) from the cluster

removing the PG-free OSD from the cluster

The following command performs these two steps:

OSDs that are not safe to destroy will be rejected.

After removing OSDs, if the drives the OSDs were deployed on once again become available, cephadm may automatically try to deploy more OSDs on these drives if they match an existing drivegroup spec. If you deployed the OSDs you are removing with a spec and don’t want any new OSDs deployed on the drives after removal, it’s best to modify the drivegroup spec before removal. Either set unmanaged: true to stop it from picking up new drives at all, or modify it in some way that it no longer matches the drives used for the OSDs you wish to remove. Then re-apply the spec. For more info on drivegroup specs see Advanced OSD Service Specifications . For more info on the declarative nature of cephadm in reference to deploying OSDs, see Declarative State

Monitoring OSD State

You can query the state of OSD operation with the following command:

When no PGs are left on the OSD, it will be decommissioned and removed from the cluster.

After removing an OSD, if you wipe the LVM physical volume in the device used by the removed OSD, a new OSD will be created. For more information on this, read about the unmanaged parameter in Declarative State .

Stopping OSD Removal

It is possible to stop queued OSD removals by using the following command:

This resets the initial state of the OSD and takes it off the removal queue.

Replacing an OSD

This follows the same procedure as the procedure in the “Remove OSD” section, with one exception: the OSD is not permanently removed from the CRUSH hierarchy, but is instead assigned a ‘destroyed’ flag.

The new OSD that will replace the removed OSD must be created on the same host as the OSD that was removed.

Preserving the OSD ID

The ‘destroyed’ flag is used to determine which OSD ids will be reused in the next OSD deployment.

If you use OSDSpecs for OSD deployment, your newly added disks will be assigned the OSD ids of their replaced counterparts. This assumes that the new disks still match the OSDSpecs.

Use the —dry-run flag to make certain that the ceph orch apply osd command does what you want it to. The —dry-run flag shows you what the outcome of the command will be without making the changes you specify. When you are satisfied that the command will do what you want, run the command without the —dry-run flag.

The name of your OSDSpec can be retrieved with the command ceph orch ls

Alternatively, you can use your OSDSpec file:

When this output reflects your intention, omit the —dry-run flag to execute the deployment.

Erasing Devices (Zapping Devices)

Erase (zap) a device so that it can be reused. zap calls ceph-volume zap on the remote host.

If the unmanaged flag is unset, cephadm automatically deploys drives that match the OSDSpec. For example, if you use the all-available-devices option when creating OSDs, when you zap a device the cephadm orchestrator automatically creates a new OSD in the device. To disable this behavior, see Declarative State .

Automatically tuning OSD memory

OSD daemons will adjust their memory consumption based on the osd_memory_target config option (several gigabytes, by default). If Ceph is deployed on dedicated nodes that are not sharing memory with other services, cephadm can automatically adjust the per-OSD memory consumption based on the total amount of RAM and the number of deployed OSDs.

Cephadm sets osd_memory_target_autotune to true by default which is unsuitable for hyperconverged infrastructures.

Cephadm will start with a fraction ( mgr/cephadm/autotune_memory_target_ratio , which defaults to .7 ) of the total RAM in the system, subtract off any memory consumed by non-autotuned daemons (non-OSDs, for OSDs for which osd_memory_target_autotune is false), and then divide by the remaining OSDs.

The final targets are reflected in the config database with options like:

Both the limits and the current memory consumed by each daemon are visible from the ceph orch ps output in the MEM LIMIT column:

To exclude an OSD from memory autotuning, disable the autotune option for that OSD and also set a specific memory target. For example,

Advanced OSD Service Specifications

Service Specification s of type osd are a way to describe a cluster layout, using the properties of disks. Service specifications give the user an abstract way to tell Ceph which disks should turn into OSDs with which configurations, without knowing the specifics of device names and paths.

Service specifications make it possible to define a yaml or json file that can be used to reduce the amount of manual work involved in creating OSDs.

For example, instead of running the following command:

for each device and each host, we can define a yaml or json file that allows us to describe the layout. Here’s the most basic example.

Create a file called (for example) osd_spec.yml :

Turn any available device (ceph-volume decides what ‘available’ is) into an OSD on all hosts that match the glob pattern ‘*’. (The glob pattern matches against the registered hosts from host ls ) A more detailed section on host_pattern is available below.

Then pass it to osd create like this:

This instruction will be issued to all the matching hosts, and will deploy these OSDs.

Setups more complex than the one specified by the all filter are possible. See Filters for details.

A —dry-run flag can be passed to the apply osd command to display a synopsis of the proposed layout.

Filters

Filters are applied using an AND gate by default. This means that a drive must fulfill all filter criteria in order to get selected. This behavior can be adjusted by setting filter_logic: OR in the OSD specification.

Filters are used to assign disks to groups, using their attributes to group them.

The attributes are based off of ceph-volume’s disk query. You can retrieve information about the attributes with this command:

Vendor or Model

Specific disks can be targeted by vendor or model:

Specific disks can be targeted by Size :

Size specs

Size specifications can be of the following forms:

To include disks of an exact size

To include disks within a given range of size:

To include disks that are less than or equal to 10G in size:

To include disks equal to or greater than 40G in size:

Sizes don’t have to be specified exclusively in Gigabytes(G).

Other units of size are supported: Megabyte(M), Gigabyte(G) and Terabyte(T). Appending the (B) for byte is also supported: MB , GB , TB .

Rotational

This operates on the ‘rotational’ attribute of the disk.

1 to match all disks that are rotational

0 to match all disks that are non-rotational (SSD, NVME etc)

This will take all disks that are ‘available’

This is exclusive for the data_devices section.

Limiter

If you have specified some valid filters but want to limit the number of disks that they match, use the limit directive:

For example, if you used vendor to match all disks that are from VendorA but want to use only the first two, you could use limit :

limit is a last resort and shouldn’t be used if it can be avoided.

Additional Options

There are multiple optional settings you can use to change the way OSDs are deployed. You can add these options to the base level of an OSD spec for it to take effect.

This example would deploy all OSDs with encryption enabled.

See a full list in the DriveGroupSpecs

class ceph.deployment.drive_group. DriveGroupSpec ( placement = None , service_id = None , data_devices = None , db_devices = None , wal_devices = None , journal_devices = None , data_directories = None , osds_per_device = None , objectstore = ‘bluestore’ , encrypted = False , db_slots = None , wal_slots = None , osd_id_claims = None , block_db_size = None , block_wal_size = None , journal_size = None , service_type = None , unmanaged = False , filter_logic = ‘AND’ , preview_only = False , extra_container_args = None , extra_entrypoint_args = None , data_allocate_fraction = None , method = None , config = None , custom_configs = None , crush_device_class = None ) 

Describe a drive group in the same form that ceph-volume understands.

block_db_size : Optional [ Union [ int , str ] ] 

Set (or override) the “bluestore_block_db_size” value, in bytes

block_wal_size : Optional [ Union [ int , str ] ] 

Set (or override) the “bluestore_block_wal_size” value, in bytes

Crush device class to assign to OSDs

Allocate a fraction of the data device (0,1.0]

A list of strings, containing paths which should back OSDs

How many OSDs per DB device

The logic gate we use to match disks with filters. defaults to ‘AND’

journal_size : Optional [ Union [ int , str ] ] 

set journal_size in bytes

filestore or bluestore

Optional: mapping of host -> List of osd_ids that should be replaced See OSD Replacement

Number of osd daemons per “DATA” device. To fully utilize nvme devices multiple osds are required. Can be used to split dual-actuator devices across 2 OSDs, by setting the option to 2.

If this should be treated as a ‘preview’ spec

How many OSDs per WAL device

Examples

The simple case

All nodes with the same setup

This is a common setup and can be described quite easily:

However, we can improve it by reducing the filters on core properties of the drives:

Now, we enforce all rotating devices to be declared as ‘data devices’ and all non-rotating devices will be used as shared_devices (wal, db)

If you know that drives with more than 2TB will always be the slower data devices, you can also filter by size:

All of the above OSD specs are equally valid. Which of those you want to use depends on taste and on how much you expect your node layout to change.

Multiple OSD specs for a single host

Here we have two distinct setups

20 HDDs should share 2 SSDs

10 SSDs should share 2 NVMes

This can be described with two layouts.

This would create the desired layout by using all HDDs as data_devices with two SSD assigned as dedicated db/wal devices. The remaining SSDs(10) will be data_devices that have the ‘VendorC’ NVMEs assigned as dedicated db/wal devices.

Multiple hosts with the same disk layout

Assuming the cluster has different kinds of hosts each with similar disk layout, it is recommended to apply different OSD specs matching only one set of hosts. Typically you will have a spec for multiple hosts with the same layout.

The service id as the unique key: In case a new OSD spec with an already applied service id is applied, the existing OSD spec will be superseded. cephadm will now create new OSD daemons based on the new spec definition. Existing OSD daemons will not be affected. See Declarative State .

You can use the ‘placement’ key in the layout to target certain nodes.

This applies different OSD specs to different hosts depending on the placement key. See Daemon Placement

Assuming each host has a unique disk layout, each OSD spec needs to have a different service id

Dedicated wal + db

All previous cases co-located the WALs with the DBs. It’s however possible to deploy the WAL on a dedicated device as well, if it makes sense.

The OSD spec for this case would look like the following (using the model filter):

It is also possible to specify directly device paths in specific hosts like the following:

This can easily be done with other filters, like size or vendor as well.

It’s possible to specify the crush_device_class parameter within the DriveGroup spec, and it’s applied to all the devices defined by the paths keyword:

The crush_device_class parameter, however, can be defined for each OSD passed using the paths keyword with the following syntax:

Activate existing OSDs

In case the OS of a host was reinstalled, existing OSDs need to be activated again. For this use case, cephadm provides a wrapper for activate that activates all existing OSDs on a host.

This will scan all existing disks for OSDs and deploy corresponding daemons.

Further Reading

© Copyright 2016, Ceph authors and contributors. Licensed under Creative Commons Attribution Share Alike 3.0 (CC-BY-SA-3.0). Revision 8a291f4c .

FPV Фристайл. Настройка дрона. Часть 6. OSD. Первый виртуальный полёт ⁠ ⁠

Покупку и сборку смотрите в предыдущих сериях.

На странице OSD настраиваются элементы текстовой информации. В поле Elements перечислены все доступные элементы. Причём каждый можно включить или выключить для трёх профилей. Мы пока настраивать переключение профилей не будем, настроим только один.

Насколько я помню, по умолчанию включен только элемент Warnings — и это не спроста. Все причины, по которым квад не армится будут отображаться на экране, а также другие проблемы: потеря связи, низкий заряд и прочее. В средней области показан пример экрана, но я рекомендую настраивать информацию, глядя в реальные очки, часто границы реального экрана не совпадают с нарисованным в интерфейсе и приходится сдвигать элемент, чтобы его стало видно. В очках изменения видны сразу. В среднем окне можно и нужно перетаскивать элемент в нужную часть экрана. Причём, включаем элемент, утаскиваем в нужный угол, включаем следующий. Иначе они наслаиваются друг на друга и тяжело понять какой элемент мы тащим.

Помимо Warnings вторым обязательным элементом будет напряжение батареи (Battery voltage) или среднее напряжение ячейки (Battery average cell voltage). Если у нас несколько квадов на 4S и 6S, то удобно видеть напряжение ячейки, чтобы сажать любой квад помня лишь одно значение. Всё остальное по большому счёту необязательно, даже уровень сигнала управления (RSSI Value или Link Quality), потому что в нашем случае мы обязаны получить дальность радиоканала управления выше, чем дальность видеоканала. Для диагностики проблем, само собой, полезны будут и эти и другие поля.

Из полезных настроек можно включить отображать режим (Fly Mode), удобно взлетать и садиться в Angle режиме. «Craft name» покажет имя нашего квада, так мы понимаем, что видим картинку со своего квада, а не с чужого. «Flip after crash arrow» покажет в какую сторону отклонять стик, чтобы перевернуться в режиме черепахи, картинка «вверх ногами» иногда дезориентирует, ставить можно по центру экрана, появляется стрелка только в режиме черепахи.

Battery Usage с вариантом Graphical remaining вместе с установленным значением Capacity на странице Power & Battery покажет убывающий прогресс бар батареи. Удобно планировать полёт и судить о состоянии батареи: на уставшей батарее предупреждение «LOW VOLTAGE» покажет гораздо раньше (относительно оставшейся ёмкости).

Поле VTX Channel покажет диапазон, канал и мощность на которой вещает видеопередатчик.

Поначалу забавно поиграться с авиагоризонтом и прицелом (Artifical horizon, Artifical horizon sidebars и Crosshairs), но потом начинаешь ценить каждый пиксель картинки и как минимум убираешь это всё в отдельный профиль для зрителей. Выставлять квад быстро и точно в горизонт будет основной проблемой, но OSD элемент имеет такую задержку, что для этой задачи бесполезен.

В области Warnings настраивается отображение предупреждений — оставим по умолчанию. В области Post Flight Statistics — настройка списка параметров после полёта (читай дизарма). Там можно настроить по желанию — не критично.

Кнопка Font Manager позволяет выбрать шрифт из нескольких вариантов. Только перед сменой шрифта не забудьте нажать Save для сделанных настроек OSD.

Получается, что всё готово для первого полёта, однако главным фактором успешного первого вылета будет готовность пилота.

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

Симулятор буду рассматривать LiftOff, но другие тоже подойдут (Drone Racing League, Velocidrone). В симе, помимо настроек стиков стоит настроить Reset квада на тумблер арма и смену режима Acro\Angle так же как настроили в полётнике. Есть смысл начинать полёты с мыслями о реальном кваде, то есть:

— сразу отмечать где стоит пилот, и летать сначала недалеко от «себя»

— в случае потери контроля\дезориентации стараться делать дизарм (ресет) до столкновения с препятствием или землёй; напомню, что на аппу мы посмотреть не сможем, тумблер дизарма мы по памяти должны переключить в нужное положение

— не стараться исправить ситуацию газом, особенно, когда стало ясно, что квад летит не туда, куда направлена камера; принимаем участь — дизарм

— взлетать в Angle режиме, снова по памяти щёлкаем уже другой тумблер

— поначалу мозгу требуется много усилий для поддержания квада в воздухе, и если пилот устал, то сажать квад в Angle и рядом с «собой»

— ходить по квартире 2 минуты, если упали далеко от себя

— включить симуляцию батареи и следить за напряжением, сажать при разряде

— включить симуляцию помех

Все эти факторы, если о них не думать заранее, станут полной неожиданностью на улице.

На большой высоте комфортнее летать — нет препятствий, но слишком просто потерять своё местоположение и начать улетать с риском потери видео, низко летать опасно, как для квада, так и для препятствий (людей быть рядом не должно вообще).

Для первого виртуального полёта пойдёт первая локация Straw Bale режим Free flight. Летать там можно пробовать вдоль забора по квадрату: пролетели по прямой, повернули, дальше по прямой и так далее. Начать можно высоко, потом высоту снижать. Не забываем после взлёта включать Acro. Регулярно менять направление по часовой\против.

Критерием готового к улице пилота я бы назвал пилота способного надёжно завершать гонку (то есть пролетать 3 круга без проблем каждый раз) на локации Autumn Fields, карта Stick Time. Это простая плоская карта с огромными воротами. И, кстати, летать гонки — очень хорошая тренировка. Нам в первую очередь нужно лететь туда, куда мы хотим (да, с этим будут проблемы поначалу) и гонка нам как раз даёт это. В свободном режиме мы можем сделать вид, что нам туда и нужно было, поэтому точки через которые нужно пролететь должны быть заданы извне.

Другой крайностью будет попытка освоить закрытую локацию, типа подземной парковки (Minus One в Liftoff) до начала реальных полётов. Летать там тяжело, я бы сказал, это как заново учиться, поэтому тратить время там сначала не нужно, а тренироваться в реале и потихоньку пробовать парковку, когда открытые карты наскучат.

Как обычно, призываю не стесняться, и по всем вопросам относительно FPV обращаться ко мне в телегу.

Выбираем OSD для коптера

OSD — это полезное вспомогательное устройство для полетов по камере. В этой статье мы рассмотрим что такое OSD, как оно подключается к нашему FPV оборудованию, и, в заключении, обзор возможностей разных OSD.

Если у вас есть какие-то вопросы — дайте мне знать в комментариях.

Что такое OSD и какие у него преимущества

OSD значит On Screen Display — т.е. дисплей на экране или меню на экране (т.е. поверх основной картинки, как правило с камеры, отображается какая-то дополнительная информация, в основном текстовая). В нашем хобби OSD — это маленькая печатная плата, которая показывает полетные параметры поверх картинки с вашей камеры. Это позволяет следить за состоянием квадрокоптера прямо во время полета по камере.

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

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

OSD не обязательна для полетов по камере, но как вы можете видеть, оно чрезвычайно полезно. Большинство людей покупают как минимум SimpleOSD, чтобы видеть напряжение на аккумуляторе, это нужно для того, чтобы избежать переразряда (если вы летите далеко, то пищалку-сирену сигнализирующую о низком заряде батареи не слышно).

Типы данных которые можно отобразить при помощи OSD

На картинке показан наиболее частоиспользуемый набор данных при полетах по камере.

Таймер

В зависимости от типа вашего OSD, это может быть время полета (считая от момента взлета) или время работы (начиная с момента включения квадрокоптера). Некоторые OSD позволяют отображать несколько видов таймеров.

Напряжение аккумулятора

Практически все OSD позволяют показывать напряжение. Это наиболее важная информация при полете по камере, так что вы знаете когда нужно приземляться (я обычно приземляюсь, когда напряжение падает до 3.5В на ячейку)

Потребляемый ток

Если у вас есть датчик тока, тогда можно отслеживать какой ток потребляют моторы и какая емкость в мАч вашего аккумулятора уже потрачена.

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

RSSI — это выход с вашего приемника управления, обычно в формате PWM, так что возможно потребуется цифро аналоговый преобразователь и фильтр нижних частот.

Предупреждения

Некоторые OSD могут показывать разные сигналы тревоги, предупреждения, для этого вы как пользователь должны задать пороговые значения параметров, например напряжение аккумулятора, значение RSSI, и т.д.

Режим полета

Показывает текущий режим полета вашего коптера. Эта информация будет полезна, если вы часто переключаетесь между разными режимами, типа Loiter (зависание на месте), ручной режим, режим самовыравнивания, так что у вас не возникнет вопрос, в каком режиме сейчас коптер. Для этого придется подключить полетный контроллер к OSD.

Используя GPS вы получаете не только координаты дрона, но еще и его высоту (хотя она будет более точной, чем при использовании барометра или сонара). Благодаря хитрым вычислениям, мы сможете увидеть скорость относительно земли, расстояние до точки старта и ее координаты (графическое отображение направления в сторону точки старта — очень полезная штука, особенно если вы немного потерялись).

Горизонт

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

Подключение OSD в камере, видео передатчику и полетному контроллеру

Я бы разделил все OSD на 3 типа:

• Автономные OSD
• OSD зависимые от полетного контроллера
• Гибридные

Автономные OSD подключаются только к камере и видеопередатчику, и не общаются с полетным контроллером. Иногда их можно подключить напрямую к GPS или другим датчикам, чтобы иметь доступ к их показаниям. Хороший пример этого типа — Skylark OSD (+GPS и датчик тока) и Super Simple OSD.

OSD зависимые от контроллера полагаются на данные только с полетного контроллера, обычно они приходят через последовательный порт (RX/TX). Само по себе OSD не делает ничего кроме отображения этих данных. MinimOSD с Hobbyking — это хороший пример такого типа OSD (если версия без модификаций, типа KV mod). Преимущество этого типа в том, что OSD использует данные полученные от датчиков контроллера, а значит эти данные использует и сам контроллер для упрощения управления и контроля. К то время как в случае автономных OSD, данные с датчиков подключенных к OSD не могут быть использованы полетным контроллером.

Гибридный тип OSD может использоваться как автономное OSD (с ограниченной функциональностью), а также может быть подключен к контроллеру для увеличения набора отображаемых полетных данных. MinimOSD с KV mod — отличный пример такого типа OSD: если используется как автономное, то можно увидеть только RSSI и напряжение, но когда оно подключено к контроллеру с GPS, тогда увидите текущий полетный режим, GPS координаты, высоту и т.д.

Дальше рассмотрим несколько вариантов подключения.

Простейшее подключение — автономное OSD

Как пример — подключение Hobbyking Super Simple OSD к FPV камере, видео передатчику и литиевому аккумулятору 3S.

Теоретически вы можете отслеживать напряжение на втором аккумуляторе используя порт Bat2.

Подключение гибридных OSD

Замечу, что в этом случае OSD самостоятельно измеряет напряжение аккумулятора и уровень RSSI (хотя есть возможность подключить их к контроллеру и передавать данные через его последовательный порт, оба варианта прекрасно работают).

Если необходимо отобразить координаты, направление на точку старта и расстояние до нее, то нужно подключить GPS к Naze32.

OSD которые я уже использовал

MinimOSD с KV Team Mod

В настоящее время MinimOSD — это мое любимое OSD, и именно его я и использую. При загрузке соответствующей прошивки MinimOSD можно использовать с платами Naze32, CC3D, Multiwii, APM и PixHawk. Это очень хорошая плата, которая может отображать абсолютно любую полетную информацию, которая доступна с датчиков.

MinimOSD может отображать любую информацию доступную с датчиков

Hobbyking и Banggood продают MinimOSD, но у них оригинальная версия, у которой нет дополнительных контактов с боку для RSSI, напряжения аккумулятора и т.п. Я бы не стал с ними связываться, если есть возможность купить MinimOSD KV Mod.

В последней версии прошивки вы можете даже настраивать ПИД коэффициенты прямо через меню. Вот тут руководство как настроить MinimOSD и Naze32.

MinimOSD Micro

Точно такое же OSD, как и описано выше, разница — меньший размер. Кроме того, на ней нет преобразователя 12В -> 5В, но это не важно, т.к. все равно никто этот преобразователь не использует из-за перегрева платы.

BrainFPV

Эта плата также показывает все что угодно, при наличии соответствующих датчиков.

BrainFPV (англ.) — это полетный контроллер со встроенным OSD, которое настраивается через программу конфигурации контроллера. Отличный вариант для тех кто не хочет связываться с пайкой, проводами и хочет получить компактную систему.

Skylark OSD

Skylark OSD — может отображать данные GPS (координаты, расстояние до точки старта, высоты, скорость), показания датчика тока, напряжение аккумулятора и таймер.

Это было мое первое автономное OSD. Я использовал KK2 в то время и искал OSD которое бы показывало мне расстояние до точки старта. Skylark OSD работает хорошо и обычно находит спутники довольно быстро. В комплекте идет GPS приемник и датчик тока.

В итоге я продал эту плату, т.к. перешел на меньший размер коптеров, где данные GPS особо и не нужны.

Super Simple OSD (очень простое OSD)

Как в названии и говориться — это очень простое устройство, которое нужно просто подключить.

Да и точность его не так хороша как у E-OSD (в случае если аккумуляторы меньше чем 4S).

Может показывать только напряжение и таймер.

Hobbyking E-OSD

Я рекомендую это OSD тем, кому нужно простое решение, и тем, кто летает только на 3S аккумуляторах. Конечно, его можно хакнуть и прошить другую версию прошивки, тогда оно сможет показывать RSSI через контакт BAT2.