mirror of https://github.com/OpenIPC/wiki.git
sandbox files translated to English
JohhnGoblin
GitHub
parent
0f5aa3f063
commit
18bed48342
|
|
@ -0,0 +1,26 @@
|
|||
## Adding Smoothness to Video
|
||||
In 1080p@30fps modes, slight video twitching is noticeable, and when shooting in slow motion, the timer shows that the picture freezes for some time and then refreshes. This is due to the unevenness of the stream, which increases sharply at key frames.
|
||||
This can be corrected by reconfiguring two encoder parameters on the camera.
|
||||
Thanks for the work done TipoMan and widgetii!
|
||||
|
||||
We need to put the [gkrcparams](https://github.com/OpenIPC/sandbox-fpv/raw/master/user_TipoMan/gkrcparams) file in /usr/sbin, give it execute permissions `chmod +x /usr/sbin/gkrcparams` and insert its launch after majestic startup in /etc/init.d/S95majestic:
|
||||
|
||||
```
|
||||
start-stop-daemon -b -m -S -q -p "$PIDFILE" -x "/usr/bin/$DAEMON" -- $DAEMON_ARGS
|
||||
sleep 1 <=== INSERT THIS
|
||||
gkrcparams --MaxQp 30 --MaxI 2 <=== INSERT THIS
|
||||
status=$?
|
||||
```
|
||||
After restarting the picture should become smooth. Other settings in majestic.yaml for mcs1 mode:
|
||||
|
||||
```
|
||||
video0:
|
||||
enabled: true
|
||||
bitrate: 7168
|
||||
codec: h265
|
||||
rcMode: cbr
|
||||
gopSize: 1.0
|
||||
size: 1920x1080
|
||||
```
|
||||
|
||||
If the picture still twitches sometimes, you will have to change mcs to 3 in `/etc/wfb.conf`, losing range, or reduce the bitrate.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
## Receiving and displaying video on windows
|
||||
|
||||
In "classic mode" (majestic streams on the camera, and the NVR sends the video stream to the PC, do not forget to specify the IP address of the PC in the wfb.conf of the recorder) video can be received in QGroundControl, Mission Planner and can be simply displayed in a separate window
|
||||
without being tied to programs. To do this, you need to install [GStreamer](https://gstreamer.freedesktop.org/download/) and launch it to receive with some parameters, for example:
|
||||
```
|
||||
C:\gstreamer\1.0\msvc_x86_64\bin\gst-launch-1.0.exe -v udpsrc port=5600 buffer-size=32768 ! application/x-rtp! rtph265depay! queue max-size-buffers=5 ! avdec_h265 ! videoconvert! videoscale! video/x-raw,width=1280,height=720,format=BGRA ! autovideosink sync=false
|
||||
```
|
||||
|
||||
In this example, the video size is changed to 1280x720. To start the video with the resolution of the original stream, remove `videoscale ! ` and `width=1280,height=720,` from the line.
|
||||
|
||||
|
||||
|
||||
|
||||
To play a video in the Mission Planner window, right-click on its window with the horizon and select `Video > Set GStreamer source`, enter the parameter line: `udpsrc port=5600 buffer-size=32768 ! application/x-rtp ! rtph265depay ! queue max-size-buffers=5 ! avdec_h265 ! videoconvert ! video/x-raw,format=BGRA ! appsink name=outsink`, click Ok. The line will be saved for future use.
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
## Connecting the camera to a tablet or PC via LTE (4G) modem
|
||||
|
||||
Flying via 4G is a very interesting topic for aircraft under stabilization or automatic route. Let's break the setup process down into tasks:
|
||||
|
||||
* set up internet via modem on camera
|
||||
* set up your own zerotier server (you can use a public one)
|
||||
* connect the camera and PC to the same zerotier network and set up a stream
|
||||
|
||||
Following [these instructions](usb-modeswitch.md), we will configure usb_modeswitch and the eth1 network interface on the camera with OpenIPC LTE firmware. If you have FPV or LITE firmware, you will need to change it online first:
|
||||
```
|
||||
#here we change fpv to lte in the file /etc/os-release, you can do it manually
|
||||
sed -i 's/BUILD_OPTION=fpv/BUILD_OPTION=lte/' /etc/os-release
|
||||
#and this is if you have the lite version
|
||||
sed -i 's/BUILD_OPTION=lite/BUILD_OPTION=lte/' /etc/os-release
|
||||
|
||||
sysupgrade --force_ver -k -r -n
|
||||
```
|
||||
We get a camera with factory settings and LTE firmware, in which, unlike FPV, WFB is removed and a Zerotier-One client is installed instead.
|
||||
In fact, the correct solution would be not to use usb_modeswitch but to configure the secondary modem composition directly to cdc_ethernet. Then the modem will cease to be universal and will immediately be displayed as a network card, but the probability of a number of problems will disappear.
|
||||
|
||||
#### zerotier
|
||||
This is software for combining multiple devices into one local network. There is a public server for creating your own network, but it is better to raise your own.
|
||||
This will require a vps server running ubuntu.
|
||||
```
|
||||
apt-get install -y apt-transport-https gnupg mc iftop #install dependencies
|
||||
curl -s https://install.zerotier.com | sudo bash #install the client part
|
||||
|
||||
curl -O https://s3-us-west-1.amazonaws.com/key-networks/deb/ztncui/1/x86_64/ztncui_0.7.1_amd64.deb #install the control panel
|
||||
apt-get install ./ztncui_0.7.1_amd64.deb
|
||||
|
||||
echo 'HTTPS_PORT=6443' > /opt/key-networks/ztncui/.env #port for web interface
|
||||
echo 'NODE_ENV=production' >> /opt/key-networks/ztncui/.env #operating mode
|
||||
echo 'HTTPS_HOST=nn.mm.ff.dd' >> /opt/key-networks/ztncui/.env #external IP address of our server
|
||||
|
||||
systemctl restart ztncui
|
||||
```
|
||||
|
||||
Log in using the link https://ip_addr:6443, login admin, password password.
|
||||
Next, create a network and configure the address issuance parameters that you like best, the rest of the settings are default.
|
||||
In private mode, after the client connects, you need to check the Authorized box to allow the client to connect.
|
||||
|
||||
|
||||
|
||||
There is an alternative in the form of a [public server](https://my.zerotier.com/), but the issue of reliability and speed remains suspended. Client programs for Windows, Android can be downloaded [here](https://www.zerotier.com/download/).
|
||||
|
||||
Connection to the network is made by specifying the Network ID, a 16-digit character string, which we take from the control panel. For the camera, we specify it in /etc/datalink.conf
|
||||
```
|
||||
use_zt=true
|
||||
zt_netid=a8867b0bxxxxxxxxx
|
||||
```
|
||||
then reboot the camera. If there is an Internet connection, either LTE or Ethernet, the camera should connect to the zerotier network. This can be checked through the web control panel and on the camera with the ifconfig command.
|
||||
```
|
||||
ztuplek3wb Link encap:Ethernet HWaddr 92:31:B1:54:8B
|
||||
inet addr:10.7.0.1 Bcast:10.7.0.255 Mask:255.255.255.0
|
||||
inet6 addr: fe80::9031:b1ff:fe54/64 Scope:Link
|
||||
UP BROADCAST RUNNING MULTICAST MTU:2800 Metric:1
|
||||
RX packets:93 errors:0 dropped:0 overruns:0 frame:0
|
||||
TX packets:1236835 errors:0 dropped:0 overruns:0 carrier:0
|
||||
collisions:0 txqueue:1000
|
||||
RX bytes:5677 (5.5 KiB) TX bytes:1493618333 (1.3 GiB)
|
||||
```
|
||||
|
||||
For a PC or Android device, [install](https://www.zerotier.com/download/) the program and similarly add the network by its id, authorize the device in the web panel. Try cross ping, it should pass. If there is a firewall/brandmauer, such as under Windows, you need to add a permit rule with our subnet.
|
||||
|
||||
#### Setting up a stream
|
||||
All that remains is to specify the IP address of the ground station from the zerotier network in /etc/majestic.yaml and the video can be received. Don't forget to agree on the codecs.
|
||||
```
|
||||
outgoing:
|
||||
- udp://ip_from_zerotier:5600
|
||||
```
|
||||
|
||||
#### Telemetry
|
||||
I haven't checked the telemetry yet, but everything should work something like this.
|
||||
Mavlink-routerd is used with the config /etc/mavlink.conf. You need to specify endpoints for local serial and ground by the zerotier IP address:
|
||||
```
|
||||
[General]
|
||||
TcpServerPort = 0
|
||||
|
||||
[UartEndpoint drone]
|
||||
Device = /dev/ttyAMA0
|
||||
Baud = 115200
|
||||
|
||||
[UdpEndpoint qgroundcontrol]
|
||||
Mode = Normal
|
||||
Address = gs_ip_from_zerotier
|
||||
Port = 14550
|
||||
```
|
||||
|
||||
Since the connection is bidirectional, we automatically receive telemetry in both directions.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
## Connecting the tablet to the recorder via wifi through the tablet's AP
|
||||
|
||||
The scheme is simple: a [TL-725n](https://www.tp-link.com/ru/home-networking/adapter/tl-wn725n/) or a similar adapter on rtp8188eu, or an adapter for
|
||||
which is the driver in the OpenIPC firmware; the tablet turns on the access point; the recorder connects to this access point; when restarting, the wfb service detects the specified wlan and
|
||||
Sets up broadcasting and telemetry on the tablet.
|
||||
|
||||
### Let's raise the network
|
||||
* Download the driver [8188eu](hi3536dv100/lib/modules/4.9.37/extra/8188eu.ko) to `/lib/modules/4.9.37/extra/`
|
||||
* Let's set up network raising on the adapter in [`/etc/network/interfaces`](hi3536dv100/etc/network/interfaces), specifying your ssid and password:
|
||||
```
|
||||
auto wlan1
|
||||
iface wlan1 inet dhcp
|
||||
pre-up if ! lsmod | grep 8188eu; then insmod /lib/modules/4.9.37/extra/8188eu.ko; fi
|
||||
pre-up sleep 1
|
||||
pre-up wpa_passphrase "ssid" "password" >/tmp/wpa_supplicant.conf
|
||||
pre-up sed -i '2i \\tscan_ssid=1' /tmp/wpa_supplicant.conf
|
||||
pre-up sleep 3
|
||||
pre-up wpa_supplicant -B -D nl80211 -i wlan1 -c/tmp/wpa_supplicant.conf
|
||||
post-down killall wpa_supplicant
|
||||
```
|
||||
### We will correct the service configs
|
||||
* Download updated [`/usr/bin/wifibroadcast`](hi3536dv100/usr/bin/wifibroadcast) and [`/usr/bin/telemetry`](hi3536dv100/usr/bin/telemetry) with connection detection in /usr/bin.
|
||||
* Add a new line to [wfb.conf](hi3536dv100/etc/wfb.conf) with a parameter - the interface name for ap
|
||||
```
|
||||
tab_wlan=wlan1
|
||||
```
|
||||
* If we do not use sending a stream to a PC, we can comment out the `udp_addr` parameter, this will unload the registrar a little.
|
||||
* Turn on the access point on the tablet and reboot the recorder, or press the button on the [front panel](nvr_gpio.md).
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
## Several cameras on one link
|
||||
|
||||
The cameras have a network interface, which in the case of two cameras can be used even without a switch, simply by connecting the four interface wires to each other. This interface will be used for communication between the cameras.
|
||||
If /etc/network/interfaces is modified in approximately the following way:
|
||||
```
|
||||
auto eth0
|
||||
iface eth0 inet dhcp
|
||||
hwaddress ether $(fw_printenv -n ethaddr || echo 00:24:B8:FF:FF:FF)
|
||||
|
||||
auto eth0:1
|
||||
iface eth0:1 inet static
|
||||
address $(fw_printenv -n ipaddr || echo 192.168.1.9)
|
||||
netmask 255.255.255.0
|
||||
```
|
||||
then the cameras will have a sub-interface with the address specified in the env variable `ipaddr` or, if it is empty, specified in address. We need the cameras to have addresses from the same subnet, for example, let it be 192.168.1.9 and 192.168.1.10 for the "first" and "second" cameras.
|
||||
The first one is the one with the wfb link and wifi-whistle. From the second one we only need a stream to an additional port, let's say 5601 to the address of the first camera.
|
||||
If the second camera has openipc, you need to disable wfb on it via `daemon=0` in `datalink.conf` and configure the udp stream in majestic.yaml to 192.168.1.9:5601.
|
||||
Now let's create a demo camera switching script `camswitch.sh` on the first camera:
|
||||
```
|
||||
function wfb_restart {
|
||||
kill -9 $(pidof wfb_tx)
|
||||
. /etc/wfb.conf
|
||||
wfb_tx -p ${stream} -u ${udp_port} -K /etc/drone.key -B ${bandwidth} -M ${mcs_index} -S ${stbc} -L ${ldpc} -G ${guard_interval } -k ${fec_k} -n ${fec_n} -T ${fec_timeout} -i ${link_id} ${wlan} &
|
||||
}
|
||||
|
||||
function cam_1 {
|
||||
# this is main cam, with wfb_tx
|
||||
sed -i 's/udp_port=5601/udp_port=5600/' /etc/wfb.conf
|
||||
wfb_restart
|
||||
}
|
||||
|
||||
function cam_2 {
|
||||
# set '- udp: cam1ip:5601' in /etc/majestic.yaml on cam2
|
||||
sed -i 's/udp_port=5600/udp_port=5601/' /etc/wfb.conf
|
||||
wfb_restart
|
||||
}
|
||||
|
||||
cam_$1
|
||||
```
|
||||
Let's give it execution rights via `chmod +x camswitch.sh` and now we can switch between cameras by calling `camswitch.sh 1` or `camswitch.sh 2`.
|
||||
The script stops wfb_tx, replaces udp_port in its config (the main camera sends to 5600 and the second to 5601) and starts it again, thus switching between streams.
|
||||
You can connect a script call, for example, to [channels.sh](notes_cam_control.md) and control switching from some RC channel.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
## Disabling watchdog on the recorder
|
||||
|
||||
The loader on the recorder starts a dog that reboots it every half hour. To disable, copy [`wdt.ko`](hi3536dv100/lib/wdt.ko) to `/lib` and add to [`/etc/init.d/S95hisilicon`](hi3536dv100/etc/init.d/S95hisilicon) to module loads, unloading immediately:
|
||||
```
|
||||
insmod /lib/wdt.ko
|
||||
rmmod /lib/wdt.ko
|
||||
```
|
||||
|
||||
Reboot, watchdog should no longer trigger.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
## Note on different uart speed for telemetry than 115200
|
||||
|
||||
TipoMan encountered a problem: the camera hung when sending telemetry to uart at a speed different from 115200. Solution: setting the desired speed in `/etc/inittab`.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
### Camera control from the ground
|
||||
|
||||
As an experiment, [`mavfwd`](mavfwd) was supplemented with a parser for the mavlink RC_CHANNELS packet (RC channel values sent from any RC link, such as from a ground station [(joystick)](https://github.com/whoim2/arduremote) via a [Mission Planner joystick](https://ardupilot.org/copter/docs/common-joystick.html)) or from a [connected](rcjoystick.md) joystick to the recorder.
|
||||
|
||||
It monitors changes in channels specified in the `--channels X` or `-c X` argument, counting from the first 4, and if any, calls the [`/root/channels.sh`](gk7205v200/root) script, passing two parameters (channel number and value) to it, and which performs the necessary operations. For example, `-c 1` will monitor only channel 5, and `-c 4` will monitor channels 5,6,7,8. In the current [example](gk7205v200/root/channels.sh) this is changing the camera mode (1080p@30fsp / 720p@5-fps) on channel 5, changing luminance to 7m (three-position switch) and ircut switch (polarizing filter). By default `-c 0`, i.e. disabled.
|
||||
|
||||
To install it on the camera, replace the standard mavfwd in `/usr/sbin/` with the [modified](mavfwd/mavfwd), and add the `-c` parameter to [`/usr/bin/telemetry`](gk7205v200/usr/bin/telemetry#L39). At the same time, you will be able to set the telemetry speed for communication with the flight controller higher than 115200, of course at your own risk!
|
||||
Ideas and suggestions on this matter are welcome and can be expressed [here](https://t.me/+BMyMoolVOpkzNWUy).
|
||||
|
||||
upd 31.03.2023 Added recognition of mavlink 2 protocol.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
## Notes on using gk7205v300 camera with imx335 sensor
|
||||
|
||||
In the main, working with the camera is no different from other gk cameras. Lite or fpv is flashed in the same way, or lite is updated to fpv.
|
||||
The presence and location of pins for USB and UART should be viewed on the seller's page. For example, the camera purchased at [link](https://aliexpress.ru/item/1005005492432144.html) has USB
|
||||
on the connector for the FPC cable and are named in the description WIFI_DP and WIFI_DN (USB DP/DN).
|
||||
|
||||
The nuances concern the resolution settings. The 1080p mode (setting size: 1920x1080 in majestic.yaml) produces 15 frames / second, which is of course unacceptable. It is necessary in the file `/etc/sensors/imx335_i2c_4M.ini`
|
||||
comment out (via `;`) the line `clock=27MHz` and set `Isp_FrameRate=30`, then reboot the camera. The corrected files are in the [imx335_gk7205v300](/imx335_gk7205v300) directory.
|
||||
The `size: 2592x1520` mode also works and produces 20 fps, but the viewing angle of the picture does not change, which suggests interpolation. But it is not known from what resolution - to what. In fact, the delay in 1520p@20 is lower and is about 165 ms, in 1080p@30 - 185 ms.
|
||||
|
||||
Also needed is [gkrcparams](gkrcparams.md) for smoother picture.
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
|
||||
### Notes on building a video link with two-way telemetry mavlink
|
||||
|
||||
The air part of the link is a [gk7205v200](https://sl.aliexpress.ru/p?key=e1sTwWg) camera with a connected USB wifi adapter on the rtl8812au chip, for example ASUS USB AC-56 or an [inexpensive weaker adapter from ali](https://sl.aliexpress.ru/p?key=8CsTwDB).
|
||||
The ground part is a [video recorder](https://sl.aliexpress.ru/p?key=L1sTwWG) based on the hisilicon hi3536dv100 or ev100 chip, to which the rtl8812au or rtl8814au adapter is connected via USB in the same way. For the Russian Federation, it is cheaper and faster to order a camera and recorder from [@ser177](https://t.me/ser177).
|
||||
This article describes the nuances of creating such a link, and is an addition to [this article](https://github.com/OpenIPC/wiki/blob/master/ru/fpv.md).
|
||||
|
||||
|
||||
|
||||
### Possibilities
|
||||
|
||||
This link is capable of transmitting video
|
||||
[(youtube)](https://youtu.be/ldfQ9CLE86I) with the aerial part format (resolution@frame rate) 1920x1080@30 or 1280x720@50 codecs h264 or h265 and mavlink telemetry in both directions. The general scheme of processes for video transmission looks like this:
|
||||
|
||||
|
||||
|
||||
Video transmission is currently possible in two ways. The classic one is the `majestic` streamer via udp port 5600 sending an RTP/h264 or RTP/h265 stream to [wfb-ng](https://github.com/svpcom/wfb-ng) or [OpenHD-wfb](https://github.com/OpenHD/wifibroadcast) for transmission to the ground, where it is received by the wfb response part and sent for playback on a PC or tablet / smartphone via LAN or USB ethernet (tethering). The RTP format is freely played by programs for GS, such as [QGroundControl](https://github.com/mavlink/qgroundcontrol), [Mission Planner](https://ardupilot.org/planner/), [QOpenHD](https://openhdfpv.org/download/) or [FPV-VR](https://github.com/Consti10/FPV_VR_OS). But it is not yet possible to output it to the HDMI port of the recorder, since it is built on a specialized chip with its own SDK and in the usual ways, for example through GStreamer, as video is usually output in the case of Raspberry Pi, this cannot be done.
|
||||
|
||||
<sub>QGroundControl has a bug when playing h265, which manifests itself in the image freezing when entering the menu. This is treated before restarting the program by selecting the h264 video stream and back to h265.</sub>
|
||||
|
||||
Andrey Bezborodov from the OpenIPC team provided compiled examples of *vencoder* and *vdecoder* for testing, pulled from Hisilicon SDK and located in their original form [here](https://github.com/OpenIPC/silicon_research). `venc` runs on the camera and forms an h264 stream with HAL fragmentation instead of `majestic`, `vdec` on the recorder outputs this stream to HDMI. Everything works, but naturally there is no OSD and such a non-standard stream cannot be played by third-party players. This is a very promising way, since it has the ability to reduce video transmission delay. At the moment, it is from 110 to 130 ms. On the "classic scheme" delays are usually from 150 to 230 ms, [here is an example 133 ms](https://github.com/OpenIPC/sandbox-fpv/raw/master/notes_files/Screenshot_1.png), depending on the resolution and ground conditions of playback.
|
||||
|
||||
This issue can be solved by "teaching" `vdec` to recognize RTP/h26[4-5] using the *libavformat/avformat.h* library and still "streaming" on the camera via `majestic`. This requires the help of a C++ programmer, if you want to help the project with this - [contact](https://t.me/+BMyMoolVOpkzNWUy).
|
||||
|
||||
Example of configuring *GStreamer* on Mission Planner to play h265: `udpsrc port=5600 buffer-size=32768 ! application/x-rtp ! rtph265depay ! avdec_h265 ! videoconvert ! video/x-raw,format=BGRA ! appsink name=outsink`
|
||||
|
||||
Supported frequencies are from 5.2 GHz to 5.85 GHz, on atheros 2.3 - 2.4 GHz.
|
||||
|
||||
### How does everything start?
|
||||
|
||||
When booting Linux, the service `S98datalink` starts among the services from `init.d`, which is the starting point. It starts the script `/usr/bin/wifibroadcast`, which determines via lsusb which adapter is connected, loads its driver, switches to monitor mode, starts `wfb` for transmission or reception, for terrestrial it determines connections via USB, a second WiFi adapter or simply starts transmitting video to `udp_addr`. It takes data on the settings from `/etc/wfb.conf`. Also, when telemetry is enabled, it starts the script `/usr/bin/telemetry`, which does the same but for telemetry purposes, taking settings from `/etc/telemetry.conf`.
|
||||
|
||||
### Nuances on camera
|
||||
|
||||
There are two sensor drivers for this camera - "slow" 1080p@30fps and "fast" 720p@50fps. They can be switched on the fly using scripts from the examples in [root](https://github.com/OpenIPC/sandbox-fpv/tree/master/gk7205v200/root), if you upload the ["fast" driver](gk7205v200/lib/sensors/libsns_imx307_2l_720p.so) to the camera under a separate name and correct the path to it in its config [`imx307_i2c_2l_720p_50fps.ini`](gk7205v200/etc/sensors/imx307_i2c_2l_720p_50fps.ini#L15). All files for this camera are in the `gk7205v200` directory. If you run the camera with the "fast" driver in the majestic settings, the video transfer is jerky, so when you start the camera via `S95goke`, the "slow" driver settings are registered, after which you can turn on the "fast" one. At the moment, [work is underway](notes_cam_control.md) to control such camera settings via RC channels in mavlink.
|
||||
|
||||
### Nuances on the registrar
|
||||
Since the recorder has a great 16MB of spi flash memory relative to the camera, of which we can use about 5MB, we have access to the [RTL adapter driver](https://github.com/OpenIPC/sandbox-fpv/tree/master/hi3536dv100/88XXau-ko) which supports rtl8814au in addition to the popular rtl8812au. To do this, you need to upload it over the regular one to `lib/modules/4.9.37/extra`, not forgetting to rename it.
|
||||
|
||||
Recompiled [`mavlink-router`](https://github.com/OpenIPC/sandbox-fpv/tree/master/hi3536dv100/usr/bin), since the complete one from the firmware is compiled on musl for the air part (where it is not used), and the recorder firmware is on glibc.
|
||||
|
||||
It is also necessary to [disable hisilicon watchdog](note_nvr_wdt.md).
|
||||
|
||||
### Nuances of telemetry
|
||||
The current telemetry scheme looks like this:
|
||||
|
||||
|
||||
|
||||
~~Currently, using mavlink-routerd, only one-way telemetry via udp is possible, since it cannot use different rx/tx udp ports within one endpoint, as required by wfb, being launched by different processes `telemetry_rx` and `telemetry_tx`.~~
|
||||
Being started by different processes, `telemetry_rx` and `telemetry_tx` use different ports for receiving and transmitting data (by the way, these are just symbolic links to wfb_rx and wfb_tx created by the [telemetry startup](hi3536dv100/usr/bin/telemetry) script), and mavlink-router requires in the [configuration](hi3536dv100/etc/mavlink.conf) two UDP endpoints, which must be grouped:
|
||||
```
|
||||
[UdpEndpoint telemetry_tx]
|
||||
Group=wfb
|
||||
Mode = Normal
|
||||
Address = 127.0.0.1
|
||||
Port = 14550
|
||||
|
||||
[UdpEndpoint telemetry_rx]
|
||||
Group=wfb
|
||||
Mode = Server
|
||||
Address = 127.0.0.1
|
||||
Port = 14551
|
||||
```
|
||||
|
||||
The remaining endpoints are needed to communicate with the ground station, for example tcp:5760 to receive connections from Mission Planner. For the [attached config](hi3536dv100/etc/mavlink.conf) in the UDP link settings you need to specify the registrar address:
|
||||
|
||||
|
||||
|
||||
All that remains is to switch to /usr/bin/telemetry to use mavlink-routerd and there is no longer any need to connect the recorder's uart.
|
||||
|
||||
```
|
||||
/usr/bin/mavlink-routerd -c /etc/mavlink.conf &
|
||||
#/usr/sbin/mavfwd --master ${serial} --baudrate ${baud} --out 127.0.0.1:${port_tx} --in 127.0.0.1:${port_rx} &
|
||||
```
|
||||
|
||||
If you want to use uart, you can set the endpoint to /dev/ttyAMA0 or switch to mavfwd.
|
||||
In this case, you need to disable the ssh console from uart in /etc/inittab by commenting out the line:
|
||||
|
||||
```
|
||||
#console::respawn:/sbin/getty -L console 0 vt100 # GENERIC_SERIAL
|
||||
```
|
||||
Then telemetry will be available on the uart of the recorder instead of or in addition to udp over the network, and it can be used via the usb-uart adapter as a serial port. On QGC, to connect to serial, you need to disable flow control in advanced, otherwise it loads about half of the parameters and gives an error.
|
||||
|
||||
I compiled `mavfwd` for the DVR, supporting b230400, b500000, b921600 and b1500000 baud rates, to support higher rates when working with Mission Planner, tested on b500000 at b115200 / b230400 on the camera. For the DVR it can be taken [here](hi3536dv100/usr/sbin). For the camera: [here](https://github.com/OpenIPC/sandbox-fpv/tree/master/gk7205v200/usr/sbin). [Source](https://github.com/OpenIPC/sandbox-fpv/tree/master/mavfwd). On the camera it was possible to get a stable connection with the flight planner at a rate of 230400, higher than stm32f4 it was not possible. Setting the flight controller speed for ardupilot is done by the `SERIALx_BAUD` parameter, in my case: "230". Also, don't forget to set the `TELEM_DELAY` parameter to 10 (seconds of delay before starting to output telemetry), otherwise telemetry may stop the bootloader. Unfortunately, if the camera is restarted for some reason during the flight separately from the flight controller, then telemetry ~~will not let it boot~~ may not let it boot. ~~It is necessary to modify the u-boot bootloader so that it does not stop booting on any character.~~ ~~With [new u-boot](gk7205v200_u-boot-7502v200-for-telemetry.md),~~ which is interrupted only by Ctrl+C, and `bootdelay=0` this problem is not present according to tests. This U-boot is already included in all OpenIPC FPV firmware.
|
||||
|
||||
I also [put in it](notes_cam_control.md) the basics for monitoring selected mavlink RC channels and passing their values when changed in `/root/channels.sh` as parameters $1 (channel) and $2 (value).
|
||||
|
||||
### Current issues
|
||||
If the "fast" 720p driver is selected when loading the camera in majestic, the video is jerky, so in S95goke (majestic autostart) the "normal" 1080p driver is installed before starting. If you want to use 720p@50 by default when loading the camera, insert a call to the switching script in [`/etc/init.d/S95majestic`](gk7205v200/etc/init.d/S95majestic#L35) in the `load_majestic` function after loading majestic:
|
||||
```
|
||||
yaml-cli -s .isp.sensorConfig /etc/sensors/imx307_i2c_2l_1080p.ini
|
||||
yaml-cli -s .video0.size 1920x1080
|
||||
yaml-cli -s .video0.fps 30
|
||||
|
||||
start-stop-daemon -b -m -S -q -p "$PIDFILE" -x "/usr/bin/$DAEMON" \
|
||||
-- $DAEMON_ARGS
|
||||
status=$?
|
||||
if [ "$status" -eq 0 ]; then
|
||||
echo "OK"
|
||||
else
|
||||
echo "FAIL"
|
||||
fi
|
||||
|
||||
sleep .5
|
||||
/root/720.sh
|
||||
|
||||
return "$status"
|
||||
```
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
### Notes on NVR hi3536ev100 firmware on OpenIPC for FPV purposes
|
||||
[EN](en_notes_start_hi3536ev100.md)
|
||||
|
||||
This article is not relevant in terms of firmware, use https://github.com/OpenIPC/wiki/blob/master/en/fpv-nvr.md, this article may be useful in some aspects.
|
||||
|
||||
|
||||
<details>
|
||||
<summary>How memory works</summary>
|
||||
First, you should understand how the recorder's memory is arranged (and the camera's too) and what needs to be flashed. The data is stored on a 16mb spi-flash in the form of mtd blocks:
|
||||
|
||||
```
|
||||
cat /proc/cmdline
|
||||
mem=150M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),8192k(rootfs),-(rootfs_data)
|
||||
ls /dev/mtdb*
|
||||
/dev/mtdblock0 /dev/mtdblock1 /dev/mtdblock2 /dev/mtdblock3 /dev/mtdblock4
|
||||
```
|
||||
As follows from the output, the zero block is the u-boot bootloader; then comes the block for storing environment variables (`printenv`, `setenv` commands write to RAM, and `saveenv` saves exactly to this block); then the uImage kernel; then rootfs.squashfs (an immutable file system image); and finally rootfs_data or overlay - a variable part where differences from rootfs are written if you change any files. Thus, by clearing the overlay, we "reset" the file system to the "default":
|
||||
```
|
||||
sf probe 0 #select device
|
||||
sf erase 0xA50000 0x500000 #perform cleaning
|
||||
reset #reboot
|
||||
```
|
||||
It's even easier to reset to factory firmware using the `firstboot` command.
|
||||
|
||||
The address calculator for commands is available [here](https://openipc.org/tools/firmware-partitions-calculation). In our case, the rootfs partition is 8192kB, so the overlay start address will be 0xA50000. For a camera with 8mB flash, the rootfs size is 5120kB, the addresses will be different, including environment variables!
|
||||
</details>
|
||||
|
||||
The bootloader of this recorder does not have a password, and you can get into it via uart/115200 baud, pressing Ctrl+C several times at startup while connected to the debug-uart port of the recorder via a usb-uart 3v3 adapter (ftdi, ch340). Debug uart is located opposite the VGA connector on the opposite edge of the board and is signed as gnd/tx/rx. We do not need to flash the bootloader, burn is not needed. ENV (environment variables) are different from the factory ones, but it is easier to install them directly from the bootloader line by line:
|
||||
```
|
||||
setenv ipaddr '192.168.0.222' #here is the ip in your subnet from free ones
|
||||
setenv serverip '192.168.0.107' #address of PC with tftp server
|
||||
setenv netmask '255.255.255.0'
|
||||
setenv bootcmd 'sf probe 0; sf read 0x82000000 0x50000 0x200000; bootm 0x82000000'
|
||||
setenv uk 'mw.b 0x82000000 ff 1000000;tftp 0x82000000 uImage.${soc}; sf probe 0; sf erase 0x50000 0x200000; sf write 0x82000000 0x50000 ${filesize}'
|
||||
setenv ur 'mw.b 0x82000000 ff 1000000;tftp 0x82000000 rootfs.squashfs.${soc}; sf probe 0; sf erase 0x250000 0x800000; sf write 0x82000000 0x250000 ${filesize}'
|
||||
setenv bootargs 'mem=192M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),8192k(rootfs),-(rootfs_data)'
|
||||
setenv eighth '192M'
|
||||
setenv totalmem '256M'
|
||||
setenv soc 'hi3536dv100'
|
||||
#here we clear variables that are no longer needed
|
||||
setenv da; setenv du; setenv dr; setenv dw; setenv dl; setenv dc; setenv up; setenv tk; setenv dd; setenv de; setenv jpeg_addr; setenv jpeg_size; setenv vobuf; setenv loadlogo; setenv appVideoStandard; setenv appSystemLanguage; setenv appCloudExAbility
|
||||
saveenv #save the new environment of variables
|
||||
printenv #check if everything is ok
|
||||
```
|
||||
Original env and full chip dump (16mb factory firmware backup in case of recovery) are available [here](https://github.com/OpenIPC/sandbox-fpv/tree/master/hi3536dv100/original_firmware).
|
||||
|
||||
As you may have noticed, the uk and ur variables store macros for flashing uImage and rootfs with loading them from the [tftp server](https://pjo2.github.io/tftpd64/), specified in the serverip variable. All addresses correspond to the bootargs variable, the contents of which specify the file system layout for the kernel during boot. The layout differs from that usual for goke/hisilicone cameras, our kernel is like lite/fpv, 2 MB in size, but the file system is 8 MB, like ultimate. The remaining ~5 MB are used by the overlay (your changes to the files relative to the original rootfs). For flashing, use the official builds from the [openipc/firmware](https://github.com/OpenIPC/firmware/releases/download/latest/openipc.hi3536dv100-nor-fpv.tgz) release page. The archive contains the kernel and file system.
|
||||
|
||||
So, after setting the variables, you can start flashing the rest of the firmware. Start the tftpd server, put uImage.hi3536dv100 and rootfs.squashfs.hi3536dv100 in its root, select the appropriate network interface and run the macro in the bootloader: `run uk`. A number of commands should be executed, from the output of which it should follow that the uImage file has been downloaded and flashed to the flash. Similarly, run `run ur` to flash the rootfs. If the addresses are set correctly, but the download is stuck on "Downloading", change the registrar address to a nearby free one: `setenv ipaddr '192.168.0.223'`.
|
||||
If everything went without errors, do a `reset` and boot into the operating system, login root, password 12345.
|
||||
|
||||
The configs from the hi3536dv100 directory are not relevant, but they may be of interest regarding connecting the tablet via USB/WiFi/Ethernet hotspot, you can transfer them by analogy to the official firmware configs or format them as separate bash scripts. Usually, the essence of these changes is to determine the address of the connected tablet (which is the gateway for the recorder in cases where the tablet is a dhcp server) and specify this address in an additional instance of wfb_rx for the video stream and for telemetry streams.
|
||||
|
||||
The firmware update is performed via the Internet using the command `sysupgrade -r -k -n`.
|
||||
|
||||
<details>
|
||||
<summary>Update without Internet from /tmp</summary>
|
||||
In the future, you can update the firmware of the recorder by uploading the kernel and rootfs to the directory `/tmp` via WinSCP and executing `sysupgrade --kernel=/tmp/uImage.hi3536dv100 --rootfs=/tmp/rootfs.squashfs.hi3536dv100 -z`. The `-z` parameter is needed if you do not have an Internet connection (does not update the sysupgrade script), `-n` will clear the user fs (overlay).
|
||||
</details>
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
## Notes on flashing the IVG-G2S camera with OpenIPC firmware.
|
||||
|
||||
ATTENTION! Most of the information in this article is hopelessly outdated, all additional steps besides firmware are no longer relevant - they are included in the firmware, and everything works out of the box, you only need to copy the gs.key from the camera to the ground station and specify the correct channels on both.
|
||||
|
||||
|
||||
The purpose of this note is to help draw attention to the extremely promising topic of launching digital fpv on cheap cameras without a single-board computer on board.
|
||||
Feedback is **VERY** important to developers; if the project is popular, it will develop much faster with their help.
|
||||
Go to the [telegram chat](https://t.me/+BMyMoolVOpkzNWUy) specially created for this topic, ask questions that are not described here and at the links below, publish information about your successes and request help in solving problems.
|
||||
Once again - feedback is extremely important, even if you have everything worked out and it works - please, do not be lazy to describe your setup and publish a review in the chat. This will allow the project to develop with the participation of developers.
|
||||
|
||||
* [Main page on OpenIPC + FPV topic, must read](https://github.com/OpenIPC/wiki/blob/master/ru/fpv.md)
|
||||
* [Main project wiki](https://github.com/OpenIPC/wiki) (currently the EN version contains more information)
|
||||
* [Online instruction generator](https://openipc.org/supported-hardware/featured)
|
||||
|
||||
|
||||
### Terms
|
||||
|
||||
* Flash - in this context SPI flash, memory chip.
|
||||
* U-Boot - bootloader. There is a "native" one, there is one from OpenIPC. The native one is password protected. We need the one downloaded from the instruction generator.
|
||||
* uImage - Embedded Linux kernel, in the form of a bin file.
|
||||
* Root-FS - file system of the selected version (lite, ultimate, fpv), in the form of a squash-fs file [https://ru.wikipedia.org/wiki/Squashfs]. uImage and rootfs must be obtained through the instruction constructor, separate firmware u-boot and root-fs.
|
||||
* Shell - command line of the linux camera, accessible via uart and ssh (putty program). There is also a bootloader shell, only uart. Login root, no password.
|
||||
* Majestic - utility - video streamer, from the OpenIPC firmware package.
|
||||
|
||||
The boards are usually equipped with spi-flash of 8 or 16 MB. The ultimate version requires 16, you can re-solder it. For fpv purposes, 8 MB is enough.
|
||||
|
||||
If you don't have an ethernet cable to connect the camera to your switch/router, you can make one from half of a regular patch cord and a jst xh1.25 8pin connector. These were used in Omnibus F4 flight decks and many other places.
|
||||
The pinouts of the camera and connector are easy to google, you need to connect 4 lines: rx+, rx-, tx+, tx- on the cable and camera. The same connector supplies power from 5 to 12 V to pins 7 (gnd) and 8 (vcc).
|
||||
|
||||
I recommend flashing lite first, since it has the shell unlocked via uart (in the /etc/inittab file) and this will allow you to connect in emergency situations, such as when there is no network.
|
||||
|
||||
There are three ways to flash the ivg-g2s camera on OpenIPC. In order of complexity: coupler, burn, programmer.
|
||||
|
||||
- Coupler [https://github.com/OpenIPC/coupler] - this is loading the kernel and rootfs with one file through the camera's native web interface. Cons - the native password does not change
|
||||
bootloader, can only be done once, rollback or change of firmware only through other methods.
|
||||
Algorithm: find out the version in the native web interface, download the firmware based on it, download it as an update in the native web interface. For ivg-g2s/659A7 there is [firmware with bootloader](gk7205v200/659A7_OpenIPC_FPV.bin).
|
||||
|
||||
- Burn [https://github.com/OpenIPC/burn] - loading an unprotected u-boot bootloader from OpenIPC via the camera's uart and uart-usb adapter (for example, ch340) and further work in the bootloader, according to the OpenIPC instruction designer.
|
||||
There are no downsides, the bootloader changes, which allows you to download the required image from the tftpf server [https://pjo2.github.io/tftpd64/] at any time and flash it into flash.
|
||||
The algorithm is described in video instructions on the OpenIPC channel [https://www.youtube.com/@openipc/videos]. Next, having loaded the bootloader into RAM (only [choose your own](gk7205v200_u-boot-7502v200-for-telemetry.md) due to the nuances), we work through the instruction designer. Unpack uImage and root-fs and put them in the tftpd directory.
|
||||
I tried to forward usb-uart to archlinux under virtualbox and use burn from there, but the loading did not work, the connection with uart was one-way, only for reading. From windows 7 everything went normally.
|
||||
Use short wires both from the USB port to the adapter and from the adapter to the camera. The pinout of the uart on the camera is in the first article from the list above, you need to connect "crosswise" - tx adapter to rx camera and rx adapter to tx camera.
|
||||
If everything is OK, but tftp does not download the file - try changing the camera address to a nearby free one, `setenv ipaddr '192.168.0.223'`.
|
||||
|
||||
- Programmer - soldering out the flash or one leg and connecting to the programmer, flashing everything through the programmer.
|
||||
The most difficult method, this is the only downside.
|
||||
|
||||
On first boot you need to run the firstboot command.
|
||||
If the camera reboots cyclically, it is the watchdog from majestic (streamer). Most likely, you need to remove the lens cap and turn on the light. It is disabled in /etc/majestic.yaml, kill the process quickly: `killall majestic`.
|
||||
|
||||
You can manage the config parameters with saving via the cli shell utility:
|
||||
```
|
||||
cli -s .image.contrast 50
|
||||
cli -s .image.luminance 50
|
||||
cli -s .video0.codec h264
|
||||
cli -s .hls.enabled false
|
||||
cli -s .isp.sensorConfig /etc/sensors/imx307_i2c_2l_1080p.ini
|
||||
cli -s .video0.size 1920x1080
|
||||
cli -s .video0.fps 30
|
||||
```
|
||||
I recommend running these commands, this will set up majestic for initial attempts.
|
||||
|
||||
Switch to FPV version with update. Attention! In FPV version shell via uart is disabled (freed for telemetry work), after loading, only network access remains. The bootloader itself, of course, works via uart.
|
||||
```
|
||||
sed -i 's/BUILD_OPTION=lite/BUILD_OPTION=fpv/' /etc/os-release
|
||||
sysupgrade --force_ver -k -r -n
|
||||
```
|
||||
If you don't plan to use telemetry through this video link, you can turn it back on:
|
||||
```
|
||||
sed -i 's/#console::respawn:\/sbin\/getty/console::respawn:\/sbin\/getty/' /etc/inittab
|
||||
reboot
|
||||
```
|
||||
If the flash is locked (you somehow flashed the kernel of previous versions that cannot unlock the flash), then this and any other commands will not be executed.
|
||||
|
||||
Example output of `dmesg | grep bsp-sfc` to determine if a flash drive is locked:
|
||||
|
||||
Unlocked
|
||||
```
|
||||
bsp-sfc bsp_spi_nor.0: SR1:[02]->[00]
|
||||
bsp-sfc bsp_spi_nor.0: SR2:[02]->[00]
|
||||
bsp-sfc bsp_spi_nor.0: all blocks are unlocked.
|
||||
bsp-sfc bsp_spi_nor.0: Winbond: SR1 [], SR2 [QE], SR3 [DRV0,DRV1]
|
||||
```
|
||||
|
||||
Blocked
|
||||
```
|
||||
bsp-sfc bsp_spi_nor.0: SR1:[02]->[00]
|
||||
bsp-sfc bsp_spi_nor.0: SR2:[02]->[00]
|
||||
bsp-sfc bsp_spi_nor.0: all blocks are unlocked.
|
||||
bsp-sfc bsp_spi_nor.0: Winbond: SR1 [TB], SR2 [QE], SR3 [WPS,DRV0,DRV1]
|
||||
```
|
||||
|
||||
Trying to unlock flash from shell (didn't help me)
|
||||
```
|
||||
devmem 0x10010024 32 0x06;devmem 0x10010030 32 0;devmem 0x1001003C 32 0x81;devmem 0x14000000 16 0x0000;devmem 0x10010024 32 0x01;devmem 0x10010030 32 0;devmem 0x10010038 32 2;devmem 0x1001003C 32 0xA1
|
||||
#
|
||||
sysupgrade --force_ver -k -r -n
|
||||
```
|
||||
|
||||
The way to unlock flash is through loading a fresh kernel, unpacked by the archiver from a tgz file with the kernel and rootfs, taken from the instruction designer. After loading, it automatically unlocks flash. It is made from the bootloader, poured into RAM via burn.
|
||||
|
||||
```
|
||||
# Set the camera address and the tftpd server address
|
||||
setenv ipaddr 192.168.0.222; setenv serverip 192.168.0.107
|
||||
|
||||
# Set environment arguments (env)
|
||||
setenv bootargs 'mem=32M console=ttyAMA0,115200 panic=20 rootfstype=squashfs root=/dev/mtdblock3 init=/init mtdparts=sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs) ,-(rootfs_data)'
|
||||
|
||||
# Clear the RAM area for kernel download
|
||||
mw.b 0x42000000 ff 1000000
|
||||
|
||||
# Loading the uImage.gk7205v200 kernel from the tftpd server
|
||||
tftpboot 0x42000000 uImage.${soc}
|
||||
|
||||
# Launch the kernel
|
||||
bootm 0x42000000
|
||||
```
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
## Setting up buttons with their own functionality on the recorder
|
||||
|
||||
|
||||
|
||||
The recorder has a connector on board for connecting a front panel with buttons, an IR receiver:
|
||||
|
||||
|
||||
|
||||
The cn5 connector is signed on the back. The purpose of +3.3v and GND is clear, IR could not be used, the remaining pins lead to the processor GPIO:
|
||||
```
|
||||
Y2 ^17
|
||||
Y1 ^6
|
||||
X2 ^13
|
||||
Y3 ^8
|
||||
X1 ^7
|
||||
ALARM 10
|
||||
REC 11
|
||||
```
|
||||
|
||||
The symbol `^` means a pull-up resistor to +3.3, which means these pins need to be shorted to GND with the button and the value 0 should be caught. This is implemented in the file [`root/gpio_monitor.sh`](hi3536dv100/root/gpio_monitor.sh).
|
||||
When pin Y1 is shorted to ground, it restarts the [wfb](hi3536dv100/etc/init.d/S98wfb) service, which then restarts [telemetry](hi3536dv100/usr/bin/telemetry), for more convenient connection of a smartphone or tablet [via USB](usb-tethering.md), or after changing the wifi adapter. The monitoring script keeps a log of clicks, which can be observed by `tail -f /tmp/gpio.log`.
|
||||
Examples of using GPIO output can be found in [`testgpio.sh`](hi3536dv100/root/testgpio.sh), and you can connect the ALARM or REC pin to a low-power LED with a resistor to indicate processes, such as restarting wfb-ng as done in `gpio_monitor.sh`.
|
||||
|
||||
To run the monitor as a system daemon, we will create the file [`/etc/init.d/S99gpio_monitor`](hi3536dv100/etc/init.d/S99gpio_monitor) from where we will run our [`root/gpio_monitor.sh`](hi3536dv100/root/gpio_monitor.sh):
|
||||
```
|
||||
#!/bin/sh
|
||||
#
|
||||
# Start gpio monitor
|
||||
#
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
echo "Starting gpio_monitor daemon..."
|
||||
/root/gpio_monitor.sh &
|
||||
;;
|
||||
stop)
|
||||
echo "Stopping gpio_monitor daemon..."
|
||||
kill -9 $(pidof {exe} ash /root/gpio_monitor.sh)
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start|stop}"
|
||||
exit 1
|
||||
esac
|
||||
```
|
||||
|
||||
We reboot without a wifi adapter and/or usb modem, activate them after booting and make sure that by pressing the button (hold it for at least half a second) the services start.
|
||||
The list of running processes can always be viewed using the command `ps axww`.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
## Connecting a tablet or phone via a USB-ethernet device.
|
||||
|
||||
The device is a network card connected via USB to the tablet and looks something like this:
|
||||
|
||||
|
||||
|
||||
It is connected to the recorder via an ethernet cable, after which in [`/etc/wfb.conf`](hi3536dv100/etc/wfb.conf) `udp_addr=auto` is specified instead of a fixed address. On the tablet itself, the "Ethernet-modem" function must be enabled
|
||||
in the settings "Network and Internet > Access point and modem".
|
||||
|
||||
Then everything will be done by the services [`/usr/bin/wifibroadcast`](hi3536dv100/usr/bin/wifibroadcast) and [`/usr/bin/telemetry`](hi3536dv100/usr/bin/telemetry) when loading the recorder or restarting from the [front-panel](nvr_gpio.md).
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
### Installing usb_modeswitch on a camera with fpv, lite and NVR hi3536[ed]v100 firmware
|
||||
|
||||
We check with the e3372h modem.
|
||||
|
||||
Camera:
|
||||
```
|
||||
curl -o /usr/sbin/usb_modeswitch http://fpv.openipc.net/files/usb-modeswitch/musl/usb_modeswitch && chmod +x /usr/sbin/usb_modeswitch
|
||||
curl -o /usr/lib/libusb-1.0.so.0.3.0 http://fpv.openipc.net/files/usb-modeswitch/musl/libusb-1.0.so.0.3.0 && chmod +x /usr /lib/libusb-1.0.so.0.3.0
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so.0
|
||||
```
|
||||
NVR:
|
||||
```
|
||||
ntpd-Nnq
|
||||
curl -k -L -o /usr/sbin/usb_modeswitch https://github.com/OpenIPC/sandbox-fpv/raw/master/usb-modeswitch/musl/usb_modeswitch && chmod +x /usr/sbin/usb_modeswitch
|
||||
curl -k -L -o /usr/lib/libusb-1.0.so.0.3.0 https://github.com/OpenIPC/sandbox-fpv/raw/master/usb-modeswitch/musl/libusb-1.0.so .0.3.0 && chmod +x /usr/lib/libusb-1.0.so.0.3.0
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so.0
|
||||
ln -s -f /lib/libc-2.32.so /lib/libc.so
|
||||
```
|
||||
|
||||
|
||||
<details>
|
||||
<summary>alternative storage</summary>
|
||||
|
||||
```
|
||||
|
||||
curl -o /usr/sbin/usb_modeswitch http://fpv.openipc.net/files/usb-modeswitch/glibc/usb_modeswitch && chmod +x /usr/sbin/usb_modeswitch
|
||||
curl -o /usr/lib/libusb-1.0.so.0.3.0 http://fpv.openipc.net/files/usb-modeswitch/glibc/libusb-1.0.so.0.3.0 && chmod +x /usr /lib/libusb-1.0.so.0.3.0
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so
|
||||
ln -s -f /usr/lib/libusb-1.0.so.0.3.0 /usr/lib/libusb-1.0.so.0
|
||||
ln -s -f /lib/libc-2.32.so /lib/libc.so
|
||||
```
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
We enter this text for e3372h into the file `/etc/network/interfaces.d/eth1` (we will create the file if it does not exist):
|
||||
```
|
||||
auto eth1
|
||||
iface eth1 inet dhcp
|
||||
pre-up sleep 4
|
||||
pre-up if [ ! -z "`lsusb | grep 12d1:1f01`" ]; then usb_modeswitch -v 0x12d1 -p 0x1f01 -J; fi
|
||||
pre-up if [ ! -z "`lsusb | grep 12d1:14dc`" ]; then modprobe usbserial vendor=0x12d1 product=0x14dc; fi
|
||||
pre-up modprobe rndis_host
|
||||
pre-up sleep 2
|
||||
```
|
||||
|
||||
We jerk the modem, try `ifup eth1` or reboot. If the network has risen (there is eth1 in `ip a`), in interfaces we can replace manual with auto.
|
||||
|
||||
#### Problems
|
||||
If usb_modeswitch switched the modem to cdc_ethernet, then when rebooting the system, for example, via reboot, the interface does not come up - error ip: SIOCGIFFLAGS: No such device. Therefore, if you need to completely reboot the system for the modem to work, you need to disconnect the power supply to the modem before rebooting.
|
||||
|
||||
### Result
|
||||
The e3372h modem with hilink firmware should be displayed as the eth1 network interface and, with a working SIM card inserted, distribute the Internet to the camera:
|
||||
```
|
||||
Trying to send message 1 to endpoint 0x01 ...
|
||||
OK, message successfully sent
|
||||
Read the response to message 1 (CSW) ...
|
||||
Device seems to have vanished after reading. Good.
|
||||
Device is gone, skip any further commands
|
||||
-> Run lsusb to note any changes. Bye!
|
||||
|
||||
udhcpc: started, v1.36.0
|
||||
udhcpc: broadcasting discover
|
||||
udhcpc: broadcasting discover
|
||||
udhcpc: broadcasting discover
|
||||
udhcpc: broadcasting discover
|
||||
udhcpc: broadcasting select for 192.168.8.100, server 192.168.8.1
|
||||
udhcpc: lease of 192.168.8.100 obtained from 192.168.8.1, lease time 86400
|
||||
deleting routers
|
||||
adding dns 192.168.8.1
|
||||
adding dns 192.168.8.1
|
||||
OK
|
||||
```
|
||||
ifconfig:
|
||||
```
|
||||
eth1 Link encap:Ethernet HWaddr 0C:5B:8F:27:9A:64
|
||||
inet addr:192.168.8.100 Bcast:192.168.8.255 Mask:255.255.255.0
|
||||
inet6 addr: fe80::e5b:8fff:fe27:9a64/64 Scope:Link
|
||||
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
||||
RX packets:34 errors:0 dropped:0 overruns:0 frame:0
|
||||
TX packets:806 errors:0 dropped:0 overruns:0 carrier:0
|
||||
collisions:0 txqueue:1000
|
||||
RX bytes:4557 (4.4 KiB) TX bytes:822513 (803.2 KiB)
|
||||
|
||||
```
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
## Connecting a smartphone or tablet on android for FPV-VR and other GS programs to NVR via USB
|
||||
|
||||
USB Tethering, also known as USB Ethernet, is an Android OS function for using a phone as a USB modem, which appears as a network card. This allows us to connect the phone and NVR with a regular USB cable and get a fast network between them. Unfortunately, in most cases, USB terhering is only available on tablets with a SIM card module. If you do not have one, and the USB modem is not activated, you will have to connect via [usb-ethernet](usb-eth-modem.md) or [wifi](note-nvr-tab-ap.md).
|
||||
|
||||
You need to [install](notes_start_hi3536ev100.md#L47) [kernel](hi3536dv100/uImage.hi3536dv100) and [rootfs](hi3536dv100/rootfs.squashfs.hi3536dv100) with rndis_host support and upload [`/usr/bin/wifibroadcast`](hi3536dv100/usr/bin/wifibroadcast), [`/usr/bin/telemetry`](hi3536dv100/usr/bin/telemetry), and add the following to [`interfaces`](hi3536dv100/etc/network/interfaces):
|
||||
```
|
||||
#USB Tethering
|
||||
auto usb0
|
||||
iface usb0 inet dhcp
|
||||
pre-up modprobe rndis_host
|
||||
pre-up sleep 4
|
||||
```
|
||||
|
||||
To enable you need to:
|
||||
* Connect your smartphone or tablet with a cable to the disconnected recorder
|
||||
* Go to settings - Network and Internet - Access point and modem
|
||||
* Turn on the recorder
|
||||
* As soon as the USB modem item appears active in the Android menu, enable it.
|
||||
* Launch FPV-VR, select the Manually (stream) section in the settings, set the video settings to the codec used (rtp/264, rtp/265) and telemetry settings to mavlink.
|
||||
* Exit settings and run "Start video and osd".
|
||||
|
||||
Alternatively, you can use the QOpenHD application with similar functionality.
|
||||
|
||||
Also available [option without restarting](nvr_gpio.md) of the recorder.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
## Using the hardware as a joystick to transmit RC channels via mavlink
|
||||
|
||||
### Theory
|
||||
Ground station programs such as Mission Planner or QGroundControl are able to recognize connected joysticks or hardware in USB joystick mode and
|
||||
transmit axis values to the flight controller in the RC_CHANNELS_OVERRIDE packet (#70). However, QGC only transmits the first 4 channels (two axes), the rest can only be assigned to buttons,
|
||||
and MP can do it only under Windows, which is not always convenient. I wrote a simple application for the recorder, which recognizes the connected joystick and sends [RC_CHANNELS_OVERRIDE](https://mavlink.io/en/messages/common.html#RC_CHANNELS_OVERRIDE) packets in the mavlink protocol version 2 for supporting 18 channels directly to the telemetry_tx port, which is usually published on 127.0.0.1:14650 of the recorder. The port, address, time between sending packets, the number of axes and the device in the system can be reassigned, see `rcjoystick -h`.
|
||||
|
||||
```
|
||||
Usage:
|
||||
[-v] verbose;
|
||||
[-d device] default '/dev/input/js0';
|
||||
[-a addr] ip address send to, default 127.0.0.1;
|
||||
[-p port] udp port send to, default 14650;
|
||||
[-t time] update RC_CHANNEL_OVERRIDE time in ms, default 50;
|
||||
[-x axes_count] 2..9 axes, default 5, other channels mapping to js buttons from button 0;
|
||||
[-r rssi_channel] store rx packets per second value to this channel, default 0 (disabled);
|
||||
[-i interface] wlan interface for rx packets statistics, default wlan0;
|
||||
|
||||
```
|
||||
|
||||
For example, you can send not to telemetry_tx, but to mavlink_routerd, if you need it that way. Package for building in buildroot from OpenIPC [here](rcjoystick).
|
||||
|
||||
### Let's launch
|
||||
We need a kernel and rootfs with usb-hid support on the recorder. To do this, [flash](notes_start_hi3536ev100) them from the [`/hi3536dv100`](hi3536dv100) directory.
|
||||
~~You need to ensure that the `hid-generic.ko` module is running, to do this, add `modprobe hid-generic.ko` to [`S95hisilicon`](hi3536dv100/etc/init.d/S95hisilicon).~~ In a freshly built kernel, the `hid-generic.ko` module is loaded automatically.
|
||||
|
||||
Next, you need to copy the binary [`rcjoystick`](hi3536dv100/usr/bin/rcjoystick) to the /usr/bin registrar, via WinSCP and assign execution rights: `chmod +x /usr/bin/rcjoystick`.
|
||||
Reboot, connect the equipment to the recorder via USB and try to run `rcjoystick -v` in the console. If everything went well, then on the screen we should see the values of the axes when changing the position of the sticks and switches, and in the telemetry program, for example in QGC (analyse tools > Mavlink inspector > RC_CHANNELS_RAW) the channels should change. To run it permanently, you can register it in a separate service [`S99rcjoystick`](hi3536dv100/etc/init.d/S99rcjoystick), the main thing is that it starts after wifibroadcast.
|
||||
|
||||
### RSSI
|
||||
|
||||
Also in rcjoystick was added the function of injection of the analog of rssi (number of received from the air part of packets per second) for at least some indicator of reception quality, since there is no desire and sense to start a separate service for this, considering the low level of the registrar. In rcjoystick there is already most of what is necessary for injection.
|
||||
|
||||
We specify `-r 16` and, if the wfb interface is not wlan0, then its `-i wlanX` and the number of packets received by the ground per second will fall into the specified channel. For me it is around 800, you can see yours by using the verbose key (`-v`). Then we specify on the flight controller:
|
||||
```
|
||||
RSSI_TYPE 2
|
||||
RSSI_CHANNEL 16
|
||||
RSSI_CHAN_LOW 0
|
||||
RSSI_CHAN_HIGH 800 //your normal value, roughly average, not maximum or minimum.
|
||||
```
|
||||
The value will be sent to the flight controller, where it will process it and set 0..99 in rssi.
|
||||
|
||||
The project is still in the testing stage, so [send](https://t.me/+BMyMoolVOpkzNWUy) your feedback on attempts and wishes.
|
||||
|
||||
### Current issues
|
||||
Sometimes short freezes are observed if you actively hammer both sticks in all directions. Debug says that the driver does not receive any movement events at this time. This effect is not observed if you use a joystick "radio extender" (sbus-to-usb-joystick) in the form of an arduino pro micro, which parses SBUS from your receiver and translates it into a usb-hid-joystick.
|
||||
Loading…
Reference in New Issue