obsidian/Main
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

First Commit

Browse Source
This commit is contained in:
Claudio
2024-12-02 15:11:30 +01:00
commit 031f6004de
4688 changed files with 441558 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Control Zero - Setup.md Normal file
View File

@@ -0,0 +1,36 @@
# Hardware
## Pinout
![[Pasted image 20240229144513.png]]
![[Pasted image 20240229144518.png]]
# Software
1. compile the correct firmware and flash it to the flight controller
2. Setup the correct airframe and calibrate the controller
3. import the last px4-fmuv5 config files and check the correct settings
4. check every peripheral independently.
1. Optical flow
2. pwm outputs (virt swash and servos)
3. rc
4. i2c --> angle sensor
5. telem 1 --> mavlink router
6. telem 2 --> micrortps bridge
7. USB --> flashing, debugging, etc.
## Virtual Swashplate Calibration
Requirements to fulfill before starting the calibration routine:
- Make sure that the motors turn in the correct direction, else swap 2 ESC-Motor cables
- Do this calibration routine with a battery and do not use a power supply. The power supply would limit the current and thus interfere with the swashplate modulation, falsifying all results.
- Wear a bike helmet for protection if you do the manual calibration
1. Set the PARAM1 Tuning channel to a nice continuous potentiometer type knob on your RC: ![[Pasted image 20240304172822.png]]
2. Prepare Parameters to do the calibration routine:
1. Set all `MC_*` parameters to have feedforward only control: Meaning force saving PID values to 0 for all axes (roll, pitch and yaw) and setting the FF parameter to 0.15: ![[Pasted image 20240304173415.png]]
2. Set the drone to ACRO mode
3. Calibrate every virtual swashplate individually (upper and lower, explained for the upper swashplate with ID=0). Repeat for ASR012_VS_EN values for: upper:1, lower: 2, both: 3
1. Enable only the upper swashplate under Q->ASR012->ASR012_VS_EN=1
2. Apply the RC_TO_PARAM option for the Upper Swash Offset parameter (ASR012_0_OFFSET)![[Pasted image 20240304172646.png]]
3. Wear the bike helmet
4. Hold drone in your hand and pitch forward. Turn the knob until the pitch/roll directions you feel correspond to what you command with the stick.
5. Reset RC-To-Param: Tools->Clear All RC to Param

43
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Custom uORB Message.md Normal file
View File

@@ -0,0 +1,43 @@
uORB message are the equivalent of [[ROS2]] messages in the PX4 messaging system. uORB does the same job as the ROS2 middleware system by sharing messages in a public and subscribe system across different modules. A good overview on how uORB works and how to customize it look at the dev-series on [this blog](https://px4.io/px4-uorb-explained-part-1/).
In order to add a custom uORB message that can be used to share information between modules and allow to log data we need to do the following steps:
- add the message definition to `PX4-Autopilot/msg/custom_msg.msg`
- add the timestamp field in the first line, since it is mandatory:
`uint64 timestamp`
- add the message file path to `PX4-Autopilot/msg/CMakeLists.txt` in order to compile the message.
If the message should be used in several independent topics we can add the following line to the message definition:
`# TOPICS topic_name_1 topic_name_2 topic_name_3`
# ROS2 Compatibility
Starting from PX4 v1.14 ROS2 compatibility is native (see [this release article](https://px4.io/px4-autopilot-release-v1-14-what-you-need-to-know)).
In order to use the new uORB message with the ROS2 system on the companion computer you need to enable it on the bridge. In order to do this there are 4 steps required as explained in [this thread](https://github.com/PX4/px4_msgs/issues/7):
1. create the uORB `.msg` file under `PX4-Autopilot/msg/`
2. Generate the ROS `.msg` using the `uorb_to_ros_msgs.py` script and copy it to `px4_msgs` under you colcon/ament workspace
3. Do the changes on both `yaml` files in `PX4-Autopilot/msg/tools` and `px4_ros_com/templates` as you did above
4. Build your colcon/ament workspace with both updated `px4_ros_com` and `px4_msgs`
## Bridge Message Yaml File
The `.yaml` file is located in two locations: under `PX4-Autopilot/msg/tools/` and in `px4_ros_com/templates/` and it needs to be the correct version in the two locations in order for the bridge to work seamlessly. Below you can find a part of such a file ([px4_ros_com](https://github.com/PX4/px4_ros_com/blob/release/1.13/templates/urtps_bridge_topics.yaml) version):
```yaml
- msg: TelemetryStatus #9
receive: true
- msg: Timesync #10
receive: true
send: true
- msg: TrajectoryWaypoint #11
send: true
- msg: VehicleCommand #12
receive: true
- msg: VehicleControlMode #13
send: true
- msg: VehicleLocalPositionSetpoint #14
receive: true
- base: VehicleLocalPositionSetpoint #15
msg: TrajectorySetpoint
receive: true
```
The option `receive: true` means that the bridge shares the messages from the companion computer to the PX4-flight controller, whereas the option `send: true` means that the PX4-flight controller sends the messages to the companion computer. If a two-way communication is desired you can add both options, just like in the example above (`Timesync`).
The PX4-Autopilot version uses the uORB message names (lowercase and underscore), whereas the px4_ros_com version uses the default ROS2 standard for the message definition (CamelCase).
It is **extremely** important that the yaml file definition of those messages matches, else the bridge won't work properly. Specifically, the order of the messages as well. Because in the background, the messages are shared over their id (indicated as a comment in the excerpt above).

7
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Direct Actuator Control from ROS2.md Normal file
View File

@@ -0,0 +1,7 @@
We want to do this in order to control a peripheral actuator such as a winch or a payloadbay.
# PX4 v1.13 and below
At the time of writing we use a modified version of the PX4 v1.13.3, which still uses the (now deprecated) mixing system to allocate control to the different actuators. Unfortunately this makes it quite cumbersome to control. I added a hack to the system, by using the [[Mavlink]] messagePWM
# PX4 v1.14 and above
The new tight [[ROS2]] integration will allow to control peripheral actuators as explained in [this video](https://youtu.be/3zRCIsq_MCE?t=1020).

23
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Nuttshell - NSH.md Normal file
View File

@@ -0,0 +1,23 @@
The nuttshell is the main shell used in the px4-environment. It can be used to [interactively work with a px4 flight controller](https://docs.px4.io/main/en/debug/consoles.html) to develop and debug. It can be accessed through [QGroundControl](https://docs.px4.io/main/en/debug/mavlink_shell.html#qgroundcontrol-mavlink-console) or [through USB](https://docs.px4.io/main/en/debug/mavlink_shell.html#mavlink-shell-py).
# Commands
An overview of all commands can be found in the [px4-documentation](https://docs.px4.io/main/en/modules/modules_main.html). Interactively you can also send the command `help` to list all available commands.
## listener
`listener uorb_topic_name`
The listener commands allows to debug the uorb message system. It was important to debug the drivers of the magnetic sensors or to debug a working bridge.
## uORB top
`uorb top`
## micrortps_client
`micrortps_client`
# Custom Commands
## osd_payload_control
## indi control
- [ ] Make sure this title is correct #todo/b
## asr012
## a5047p

1
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/PX4 Build Instructions.md Normal file
View File

@@ -0,0 +1 @@
In order to successfully build PX4 for different boards you need to configure them first by running the `boardconfig` option with the command.

24
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Payload Controller.md Normal file
View File

@@ -0,0 +1,24 @@
The first quick and dirty implementation was done on the companion computer using a ROS2 Node (see [[Direct Actuator Control from ROS2]]). But this will use too much bandwidth on the datalink between the flight controller and the companion computer.
# PX4 Implementation
We want to be able to open and close the payload bay even if the drone is not armed. Therefore, we need to make use of the pre-arm state that exists in order to check the functionality of non-dangerous [[Actuators |actuators]] (e.g. control surfaces. not motors/propellers). The arm, disarm and pre-arm configuration is explained on the [PX4 user guide](https://docs.px4.io/main/en/advanced_config/prearm_arm_disarm.html).
We want the following parameters:
| Parameter | Description | Value |
| ---- | ---- | ---- |
| COM_PREARM_MODE | ALWAYS | 2 |
| CBRK_IO_SAFETY | No Safety Switch | 22027 |
This puts the drone into the pre-arm state upon boot and allows to move the control surfaces immediately, without engaging the propellers.
## PWM Calibration
The payload servos should be calibrated like any other servo motor. We need to configure the following parameters (assuming the servo is MAIN_5):
| Parameter | Description | Value |
| ---- | ---- | ---- |
| PWM\_MAIN\_DIS5 | PWM value in disarm state | e.g. 1500 |
| PWM\_MAIN\_FAIL5 | PWM Value in failsafe state | e.g 1500 |
| PWM\_MAIN\_MAX5 | Maximum PWM value commanded | e.g. 1958 |
| PWM\_MAIN\_MIN5 | Minimum PWM value commanded | e.g. 867 |
The values are usually experimentally measured using a simple PWM controller (aka. servo tester).
## Payload Controller Module

24
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/ROS2 Interface for PX4.md Normal file
View File

@@ -0,0 +1,24 @@
# FastDDS Bridge
This is the newest type of bridge and it allows to integrate ROS2 and PX4 much closer together.
The [newest development](https://www.youtube.com/watch?v=3zRCIsq_MCE&ab_channel=PX4Autopilot-OpenSourceFlightControl.) allows to easily define new flight modes that run on the companion computer instead of PX4. PX4 remains aware of this.
# MicroRTPS Bridge
## Troubleshooting
### Baudrate Mismatch
If the baudrate is not the same on both ends, no error is thrown, but the communication does not work.
In the screenshot below you can see the status when the baudrate had a mismatch (red rectangle), there were no received messages. Once the baudrate was correct the messages could be received (green rectangle)
![[Pasted image 20240311104419.png]]
The baudrates are changed like follows:
- on the PX4 you can change the parameter `SER_TEL_2_BAUD` if TELEM2 is used as the micrortps bridge. Or if you start the bridge with a nuttshell command you can use the argument `b`, e.g.: `micrortps_client start -t UART -d dev/ttyS2 -b 921600`
- on the companion computer side with the argument `-b`, when launching the micrortps agent: `./install/px4_ros_com/bin/micrortps_agent -b 921600 -d /dev/ttyAMA1 -g`
### ROS2 Topic Echo does not receive PX4-Data
If the bridge is setup correctly echoing the attitude message on the companion computer should show the messages. For it to work, the correct ROS2 environment has to be sourced and both ends of the bridge (agent on the companion computer, client on the px4-system) have to be running.
Run the following command: `ros2 topic echo /fmu/vehicle_attitude/out`.
Messages should start to appear.
If not check the following things:
- Is the cable connected?
- Have RX and TX cables been confused?
- Does the baudrate match on both ends? (see [[ROS2 Interface for PX4#Baudrate Mismatch]])
-

10
99 Work/0 OneSec/OneSecNotes/10 Projects/PX4/Virtual Swashplate.md Normal file
View File

@@ -0,0 +1,10 @@
The virtual swashplate algorithm is implemented in 2 modules within PX4.
# Parameters
It's important to have oneshot (or possibly dshot) as a protocol, because normal pwm signals are is too slow to do the actuation at our rpm.
In the flight controllers the PWM pins are grouped into timer groups, which use the same timer in the background and thus need to share the same protocol. For the [[Control Zero - Setup|Control Zero]] those groups are 1234, 56 and 78. We have chosen 7&8 as our virtual swashplate outputs.
| Parameter | Description | Value |
| ---- | ---- | ---- |
| PWM_MAIN_OUT | The pwm channels used as ESC outputs | 78 |
| PWM_MAIN_RATE | The pwm rate at which the signal is being generated. 0 Hz means that the [[PWM#Oneshot\|OneShot125]] protocol is used. | 0 Hz |