语境
我的任务是设计和构建一个微型四轴飞行器的速度 PID 控制器，而不是室内的苍蝇。四轴飞行器飞行的房间配备了基于摄像头的高精度室内跟踪系统，可为四轴飞行器提供速度和位置数据。由此产生的系统应该能够接受每个轴（x、y、z）的目标速度并以该速度驱动四轴飞行器。
四轴飞行器的控制输入是滚转/俯仰/偏航角和高度的推力百分比。
我的想法是为每个轴实现一个 PID 控制器，其中 SP 是该方向上的所需速度，测量值是跟踪系统提供的速度，输出值是滚转/俯仰/偏航角和推力百分比。
不幸的是，因为这是我第一次接触控制理论，我不确定我是否朝着正确的方向前进。
问题
我了解基本的 PID 控制器原理，但我仍然不清楚它如何仅通过对误差求和并乘以常数将速度（m/s）转换为滚转/俯仰/偏航（弧度）？是的，速度和滚转/俯仰成正比，所以这是否意味着乘以正确的常数会产生正确的结果？
对于垂直速度控制器的情况，如果速度设置为 0，四轴飞行器实际上应该只是保持其高度而不上升或下降。如何将其与 PID 控制器集成，以便在误差实际为 0 时推力值不为 0（应保持悬停，而不是下降）？我应该在输出中添加一个常数项吗？
系统实施后，调整 PID 增益参数的好方法是什么？手动试错？
系统开发的下一步是位置 PID 控制器的附加层，它将所需位置 (x,y,z) 作为设定点，测量位置由室内跟踪系统提供，输出为 x/y /z 速度。这是一个好方法吗？分离这些 PID 控制层的原因是该项目是促进可重用性的更大框架的一部分。仅使用单层 PID 控制器直接将位置坐标作为设定值并输出滚转/俯仰/偏航/推力值会更好吗？
我们已经有一个适用于x86，x64和ARM的UWP应用程序。关于商店认证，一切都很好，所有测试都通过了，包括.NET本机编译。
我们想使用Desktop Bridge（类似于此处指定的内容：https：//blogs.msdn.microsoft.com/appconsult/2016/12/19/desktop-bridge-the-migrate-phase-invoking-a- win32-process-from-a-uwp-app /），将一个小型.NET 4.6.1 WPF侧踢应用添加到主要的UWP（x86，x64）版本中。WPF应用程序对某些本机dll具有三个依赖项（x86和x64），这些依赖项与该应用程序的其余部分打包在一起。
我们将WPF.exe应用程序和dll添加到了现有的UWP软件包（如上述博客文章中所指定-使用xcopy），并为HockeyApp构建了软件包。在本地和功能上，一切都适用于x86和x64。上载到ms开发人员中心后，不幸的是，商店认证失败并显示以下错误：
“程序包接受验证错误：必须由.NET Native工具链预先编译用Desktop Bridge转换并需要.NET Native框架的应用程序”
-但已经为UWP版本x86，x64启用了本机编译。
然后，我们尝试创建Windows应用程序打包项目（如此处所述：https : //docs.microsoft.com/zh-cn/windows/uwp/porting/desktop-to-uwp-packaging-dot-net#generate-packages -for-your-desktop-bridge-app），并将UWP应用程序和WPF都添加为依赖项。然后，我们创建了一个新的应用程序清单和商店关联（不幸的是，似乎无法重用UWP应用程序中的现有清单）。我们针对（x86 x64版本）构建了应用商店软件包，并在本地成功测试了所有内容。然后，我们上传了软件包以赢得开发人员中心，并再次遇到与以前相同的错误
“程序包接受验证错误：必须由.NET Native工具链预编译使用Desktop Bridge转换并需要.NET Native框架的应用程序”。
作为后续，我们从Windows应用程序打包项目中删除了UWP项目，并将WPF应用程序设置为入口点。然后，我们构建了一个存储包，将其上载，.NET本机编译错误消失了。太奇怪了...
UWP和WPF的组合（即使启用了UWP的本机编译）以某种方式导致此认证错误。我们感觉包装有问题。
我们确实希望使这种组合正常工作，否则我们将不得不退回到拥有两个单独的应用程序：一个纯UWP和一个打包的WPF配套应用程序，需要分别安装。我们真的希望我们不必这样做。我不确定我们在做什么错，目前我已经没有想法了。
PS：我们也知道我们需要填写并提交有关受限功能的表格：完全信任。但是在我们这样做之前，我们需要确保其他一切都很好。