vault backup: 2025-02-03 07:04:13
This commit is contained in:
Binary file not shown.
@@ -1,13 +0,0 @@
|
||||
A loom video instruction can be found [here](https://www.loom.com/share/f6460a1200fe499eb3aae941c8bd8ca8?sid=49451325-5d3a-4953-8e24-7007af44a99e).
|
||||
# Preparation
|
||||
1. Decide which image you want to flash to the cm4. All images can be found on the [google drive](https://drive.google.com/drive/folders/1SCE0VCfHIKdJlZBVMUI5AOd8uqdrAA_7) and usually you can find an overview on the [CM4 Images Overview sheet](https://docs.google.com/spreadsheets/d/1hWfCUwhnYKjQz526QUwpVui-eFWYgPfyoRJ40pwvJD8/edit#gid=0). For this example I chose the image `cm16_240104.img.xz`.
|
||||
2. Decide which physical cm4 board you want to flash the image to. A list of all cm4's that we own can be found in the [CM4 overview sheet](https://docs.google.com/spreadsheets/d/18PtsqKYUrfK0cAAFBfwtgTSo0JnJ0n5Dc3oIjpWry6I/edit#gid=0). For this example we chose the cm4 with ID 14.
|
||||
1. Be aware that there are two versions of cm4s. The lite version requires a SD-card whereas the EMMC version does not. The flashing instructions are different for the two.
|
||||
2. The cm4s also come with different RAM and EMMC storage. You can visually inspect the part numbers if you are unsure. E.g. [RAM](https://semiconductor.samsung.com/dram/lpddr/lpddr4/k4f6e304hb-mgcj/), or [EMMC](https://semiconductor.samsung.com/estorage/emmc/emmc-5-1/klmbg2jetd-b041/).
|
||||
|
||||
# Flashing
|
||||
If you have the EMMC version follow the instructions here: https://onesecinc.atlassian.net/wiki/spaces/MC1/pages/35029029/Flash+CM4+EMMC+with+a+new+Image
|
||||
|
||||
If you flash a Lite version, plug the SD-card into your development computer and then follow the instructions starting from point 5.
|
||||
# UID
|
||||
# Testing
|
||||
Binary file not shown.
@@ -1,6 +0,0 @@
|
||||
|
||||
# Unchanged from V2
|
||||
- temp and humidity sensor
|
||||
- 3V3 LDO:
|
||||
- only consumers changed, but is remaining below limit.
|
||||
- led drivers changed only very little
|
||||
Binary file not shown.
@@ -1,8 +0,0 @@
|
||||
[This article](https://opensource.com/article/18/6/embedded-linux-build-tools) summarizes different build tools to get the embedded application working. Currently, we use the last of the four options described: a stripped down desktop distribution.
|
||||
Also [this video](https://www.youtube.com/watch?v=9vsu67uMcko&ab_channel=DigiKey) by DigiKey series goes into those tools in more detail, mostly yocto.
|
||||
|
||||
# Yocto
|
||||
# Buildroot
|
||||
# OpenWRT / LEDE
|
||||
|
||||
|
||||
@@ -1,3 +0,0 @@
|
||||
- [ ] Is SIM-card inserted and correctly oriented?
|
||||
- [ ] Are Antennas connected securely (GNSS, LTE, LTE Diversity)
|
||||
- [ ]
|
||||
Binary file not shown.
Binary file not shown.
@@ -1,5 +0,0 @@
|
||||
The Webapp is hosted on our [[OneSec Server#PX4 - Flight Review|VPS server]]. The credentials are:
|
||||
- user: claudio
|
||||
- pw: CesOne8143_
|
||||
# Add a New Log
|
||||
![[Pasted image 20240320120530.png]]
|
||||
@@ -1,64 +0,0 @@
|
||||
We host the server at [netcup - Germany](https://www.netcup.eu/), a company that offers VPS. The IP address of our server is 37.120.177.0.
|
||||
|
||||
# Organisation
|
||||
## Access
|
||||
The following is the access data to access the server through ssh (part of my `~/.ssh/config` file):
|
||||
```bash
|
||||
Host netcup
|
||||
HostName v2202204173997187481.hotsrv.de
|
||||
User root
|
||||
IdentityFile ~/.ssh/netcup_osd_claudio
|
||||
```
|
||||
## Setup
|
||||
Vinnie, Dannick's Friend, helped me with the setup. I leave the bash history and the zsh history files here as a reference.
|
||||
![[bash_history_netcup]]
|
||||
|
||||
![[zsh_history_netcup]]
|
||||
|
||||
I have installed `zsh` and `oh-my-zsh` to make the interaction easier
|
||||
|
||||
in the cli-history files above you can see how the project got updated, but basically update the project files on a local machine, test everything, push it to gitlab. Then access the server, pull the changes, checkout to the correct version and restart the docker container:
|
||||
```zsh
|
||||
docker compose -f docker-compose.dev.yml down docker compose -f docker-compose.dev.yml up -d --build --force-recreate
|
||||
```
|
||||
## Structure
|
||||
The main folder is called osd_apps, which hosts the web-apps that we're running.
|
||||
We use [[nginx]] as a reverse proxy to serve the different web-apps and [[Docker]] to run the apps in an appropriate container.
|
||||
|
||||
We also use certbot (installed through snap) to keep the certifiates up to date.
|
||||
|
||||
The [[OneSec - FlightReview|flight review app]] is hosted at the website [testlogs.onesec.com](testlogs.onesec.com). The authentication is done through a nginx configuration. The credentials can be found on the specified article.
|
||||
|
||||
### 6tunnel
|
||||
[6Tunnel](https://github.com/wojtekka/6tunnel) is used to create a translation service for Dannicks NAS. Basically the server (which has a static IPV4 address) forwards requests to a IPV6-address (Dannicks NAS). See history files above for the commands. And make sure that the firewall (`ufw`) allows the correct ports (32400 in Dannicks case).
|
||||
|
||||
### Nginx
|
||||
Nginx is used as a reverse proxy server, that checks incoming traffic and routes it to the correct interface on the server. We can configure it, such that any traffic coming from a certain URI (e.g. testlogs.onesec.com) is rerouted to the localhost:5006. And on this interface we are running a docker container, which hosts the web-app. This means that any traffic coming from testlogs.onesec.com is directed towards the web-app and any other traffic (from the IP for instance) is routed to `/var/www/http` and a static content is served (default nginx stuff). If another app is added we can have an additional port for that as explained in [this article](https://www.digitalocean.com/community/questions/how-to-host-multiple-docker-containers-on-a-single-droplet-with-nginx-reverse-proxy).
|
||||
|
||||
### Certbot
|
||||
Certbot is a tool that manages certificates for our webserver. It has a really good integration with nginx. Some more info can be found [here](https://sirfitz.medium.com/setting-up-an-nginx-instance-with-certbot-and-configuring-it-for-wildcard-subdomains-on-ubuntu-96e413281a99). Especially the cron-job for the autorenewal is handy. But cerbot also has a automated way of handling this, as can be seen in the [instruction set by digital ocean](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04). Compared to the instructions on the blog article, on our server we've used the following command:
|
||||
```bash
|
||||
sudo certbot --nginx -d testlogs.onesec.com
|
||||
```
|
||||
|
||||
|
||||
### Docker
|
||||
[[Docker]] is used to isolate multiple web-apps that are running. A few important things are listed here:
|
||||
- use the `-d` or `--detach` option to let it run in the background even if the terminal is disconnected. This ensures that the webapp is running when the setup process is finished.
|
||||
# WebApps
|
||||
## PX4 - Flight Review
|
||||
A [customized version](https://gitlab.com/onesecdelivery/flight_review_osd) of the official PX4 [flight review](https://github.com/PX4/flight_review) app is hosted there.
|
||||
|
||||
|
||||
# How to add a new WebApp?
|
||||
1. Go to namecheap.com, login and [add a new A-record.](https://www.namecheap.com/support/knowledgebase/article.aspx/319/2237/how-can-i-set-up-an-a-address-record-for-my-domain/)![[Pasted image 20240123183014.png]]Here you can see that for the subdomain foxglove and testlogs we have an A-Record [^1] to forward to our VPS server (37.120.177.0). Once this is done all traffic gets forwarded to our VPS server where we need to handle it.
|
||||
2. Access the servers command line through SSH (see instructions above).
|
||||
3.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Footnotes
|
||||
[^1]: An A record **maps a domain name to the IP address (Version 4) of the computer hosting the domain**. An A record uses a domain name to find the IP address of a computer connected to the internet. The A in A record stands for Address.
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
@@ -1,19 +0,0 @@
|
||||
Nav3 is our custom implementation of a navigation library. It is heavily inspired by [[ROS2 - NAV2 Library|NAV2]] which is a standard [[ROS2]] library.
|
||||
|
||||
By heavily inspired I mean it is basically copied, and modified.
|
||||
|
||||
# Differences
|
||||
## Costmap_3d
|
||||
The `nav3_costmap_3d` package is completely rewritten. The only similarity to the original `nav2_costmap_2d` package is that we're using the same API to remain compatible with the rest of the `nav2` library.
|
||||
|
||||
Our own costmap_3d implementation uses a fruxel grid instead of voxels.
|
||||
|
||||
## Planners
|
||||
Several planner plugins are missing for now.
|
||||
|
||||
## Controllers
|
||||
Several controller plugins are missing for now.
|
||||
|
||||
|
||||
## Nav3_util
|
||||
- Added `calculate_linear_speed(Twist)` which is a central util function to calculate speed
|
||||
@@ -1,12 +0,0 @@
|
||||
The purpose of using [[Docker]] this is to have a containerized build of the autopilot. This means that any employee can easily get started with development by cloning the vscode-docker-dev repo and open the repo in a containerized mode. This drastically reduces onboarding time and also ensures that everyone is working on the exact same system.
|
||||
|
||||
There are a few inspirations to how I want to set this up:
|
||||
1. Keep in mind that the final code needs to run on the raspberry pi cm4 module, without a docker container because we need hardware access.
|
||||
2. The containerization can be built in several layers:
|
||||
1. ros2 production (no simulation tools, this is the closest we get to the rasperry pi --> exports a shell script to install on the rasperry pi.)
|
||||
2. simulation stack: includes px4-osd that runs the current px4-code and the px4 simulation running in gazebo as well as ros2 to do development
|
||||
3. testing stack: same as previous stack but includes integration tests: missions to accomplish and writes automated reports if the flights were successful or not (could also upload to a log website)
|
||||
|
||||
This is going to be really helpful in the future, because with every commit merge to the main branch, unit-tests, functional tests and integration tests need to pass before a merge can happen.
|
||||
|
||||
PX4 already does [extensive testing](https://github.com/PX4/PX4-Autopilot/tree/main/test) within a gazebo simulation. It also includes more elaborated [integration tests](https://github.com/PX4/PX4-Autopilot/tree/main/integrationtests/python_src/px4_it).
|
||||
@@ -1,5 +0,0 @@
|
||||
## How to run
|
||||
1. We need a transform between map and odom: `os2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 1 map odom`
|
||||
2. We need the px4 simulation running: `source ~/ros2_ws/install/setup.zsh && cd ~/px4-osd && make px4_sitl_default gazebo_osd_mono_copter`
|
||||
3. We need the RTPS bridge running: `/home/claudio/ros2_ws/install/px4_ros_com/bin/micrortps_agent -t UDP`
|
||||
4.
|
||||
@@ -1,23 +0,0 @@
|
||||
|
||||
# PX4_MSGS
|
||||
The [PX4_msgs](https://github.com/PX4/px4_msgs) package is required, because it translates [[Custom uORB Message|uORB]] messages into the ROS2 ecosystem and vice versa. The project contains a `msg` folder, which contains the msg definitions. Usually, those message definitions are autogenerated by [a script](https://github.com/PX4/PX4-Autopilot/blob/v1.13.3/msg/tools/uorb_to_ros_msgs.py) provided by the PX4-Autopilot project.
|
||||
A build error that has popped up several times is that the messsage definition comments contain `*/` which is misinterpreted by the compiler
|
||||
Error message:
|
||||
``` bash
|
||||
/home/pi/ros2_ws/build/px4_msgs/rosidl_generator_c/px4_msgs/msg/detail/gimbal_v1_command__struct.h:356:3: error: expected identifier or ‘(’ before ‘/’ token
|
||||
356 | */
|
||||
| ^
|
||||
/home/pi/ros2_ws/build/px4_msgs/rosidl_generator_c/px4_msgs/msg/detail/gimbal_v1_command__struct.h:365:3: error: expected identifier or ‘(’ before ‘/’ token
|
||||
365 | */
|
||||
```
|
||||
In order to solve this error, just delete the relevant parts of the comment.
|
||||
|
||||
|
||||
# px4_ros_com
|
||||
In order to successfully build the `px4_ros_com` package you need to define the following env-variable: `export FASTRTPSGEN_DIR="/usr/local/bin/"`.
|
||||
Without it it will not work and throw the following error:
|
||||
```bash
|
||||
c++: error: /home/pi/ros2_ws/build/px4_ros_com/src/micrortps_agent/microRTPS_agent.cpp: No such file or directory
|
||||
c++: fatal error: no input files
|
||||
```
|
||||
|
||||
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