vault backup: 2025-02-03 07:04:13
This commit is contained in:
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -1,23 +0,0 @@
|
||||
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 +0,0 @@
|
||||
In order to successfully build PX4 for different boards you need to configure them first by running the `boardconfig` option with the command.
|
||||
@@ -1,24 +0,0 @@
|
||||
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
|
||||
@@ -1,24 +0,0 @@
|
||||
|
||||
# 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]])
|
||||
-
|
||||
@@ -1,10 +0,0 @@
|
||||
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 |
|
||||
Reference in New Issue
Block a user