FWKS
(Gad)
January 27, 2023, 4:16pm
1
I get the following messages on the Ardupilot log right around the moments where the drone starts exhibiting very strange behaviors:
Where are these messages generated? Is this text coming from the Ardupilot code or the Myxas themselves?
What’s the meaning of this “Passive Phase modulation disabled”?
We’re using Myxas with Telega 0.5
Thanks
The message comes from the motor controller, not from the flight controller. It refers to the transition between two phase voltage modulation strategies shown in the following diagram. The left part shows the regular sinewave modulation, the right part shows the “passive phase” modulation strategy:
Also here’s a very instructive comparison of the two:
The original illustration is made by Max La and published under CC BY-SA 3.0.
FWKS
(Gad)
January 27, 2023, 6:18pm
3
Thanks @pavel-kirienko
In pracrice - what does this transition mean for the motor control and why or when does the Myxa descides to transition?
Furthermore - I’m getting some other messages of the same type, where can i find some documentation regarding the meaning of these messages?
This is explained here, in section “vector control system”:
Starting next week, we will advise our customers to adopt Telega v1.0 — the first stable release of the Telega motor control solution that is compatible with the existing hardware. An official announcement will follow. The stable release is equipped with comprehensive documentation available at telega.zubax.com .
While v1 is obviously built on the same core IP as Telega v0, it comes with certain differences. One such difference is the fact that it does not support DroneCAN, focusing exclusively on Cyphal instead. I am familiar with the details of your application and I can predict that you will benefit from the adoption of the new firmware. As an ArduPilot user, however, you will be facing the obvious problem that the following pull request, which brings support for Cyphal-interfaced motor controllers into ArduPilot, is failing to gain attention of the maintainers:
ArduPilot:master
← PonomarevDA:pr-uavcan-v1
opened 07:52AM - 31 Mar 22 UTC
This PR adds a minimal implementation of Cyphal (uavcan v1.0) for ESC controllin… g.
It has the following required for any application functions:
- Node heartbeat (the node publishes uavcan.node.Heartbeat)
- Generic node information (the node response on uavcan.node.GetInfo.1.0 request)
- Register interface (response on uavcan.register.Access.1.0 and uavcan.register.List.1.0)
I also implemented templates for the following data types, but they do nothing yet. They might be completed if someone needs them or even removed for a while:
- uavcan.node.port.List (sends all supported port id)
- uavcan.node.ExecuteCommand (handles requests on restart or save parameters commands)
It also interacts with all necessary for ESC controlling data types, such as:
- reg.udral.service.actuator.common.sp.Vector4.0.1
- reg.udral.service.common.Readiness.0.1
- reg.udral.physics.electricity.PowerTs_0_1
- reg.udral.service.actuator.common.Feedback_0_1
- reg.udral.service.actuator.common.Status_0_1
- reg.udral.physics.dynamics.rotation.PlanarTs_0_1
All ESC related data types have non-fixed subject identifier. It is handled by the register interface that is based on AP_Param library. Since the implementation doesn't support automatically port id enumeration, you need to either manually or using a script from external server set their id (for ardupilot and for esc's).
Typical set of parameters and corresponded registers might be as on the picture below:
![ardupilot_params](https://user-images.githubusercontent.com/36133264/160892348-bdcf6122-24b3-4ac9-b768-44970b7c4562.png)
I also forwarded esc telemetry to the corresponded MAVLink message:
![esc_telem](https://user-images.githubusercontent.com/36133264/160892583-821a31f1-431a-4174-bb10-59983c528031.png)
The implementation is based on `libcanard`, `o1heap`, `public_regulated_data_types` repositories which are added as submodules. It also uses `nunavut` for generating the code from DSDL. I tried to implement it in the similar way as AP_UAVCAN is implemented. You may use both versions of UAVCAN simultaneously, but on different CAN buses only.
According to the build summary comparison, on CUAV v5 the current branch used 14244 bytes of flash memory more than master branch. Although free flash on this branch on this hardware is 317088 bytes.
The firmware was tested on real copter based on cuav v5. I attached here a few flight examples [first](https://youtu.be/wBNh1XV1EMQ) and [second](https://youtu.be/FE_kxwhicWM) and corresponded [log files](https://drive.google.com/drive/folders/11hBPpcgdHG1a3gUMJ8z9DtMmeTAbuwBR?usp=sharing). I used Holybro kotleta20 ESCs based on sapog v3 firmware. Here should be noticed that I tested it before merging master branch into this branch. I may provide more tests in future. I also tried `Tools/scripts/build_all.sh` and it's ok.
I also want to notice that even if it was tested it is a still just a first version of implementation. It has a few assumptions, for example:
- it is expected to use it only for quadcopter since it uses exactly 4 ESCs,
- it works only on first CAN bus now.
I didn't test it on other hardware.
Any feedback is welcome.