-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature proposal : Make QGroundControl work on the groundPi #172
Comments
It was not too hard to do a couple years ago.. QT was a pain at times and would be doing everything from command line and having to add a lot of dependency’s to the EZ build. |
This would indeed by a nice addition to the GroundPi. Since CPU load on the Groundside is rather marginal right now it should be able to run it. Thank you for bringing this up @Yes21 |
There are several issues:
|
Thank you for the explanation Nico. It all makes perfect sense.
Excuse me but I have a question about the GroundPI CPU load which is displayed in the OSD. I have noticed that is barely shows more than 10% (I’d say in average about 5%)… I have never seen it rise to more than 20%. With my AIO transmitter build I noticed however that the GroundPi CPU runs very hot. After about 1h the Raspi will even show the overheating „thermometer symbol“ in the upper right screencorner and the CPU temp shows in the OSD with about 82°C.
How does it come that the CPU runs so hot with so little CPU load?
You were mentioning way higher CPU usage in your message… maybe there is some error with the CPU usage display in the OSD? Maybe it just represents one core or the average calculation has a bug?
Best regards
… Am 05.11.2018 um 18:10 schrieb Rodizio ***@***.***>:
There are several issues:
QGroundcontrol requires the QT graphics library which is usually used with the X window system. The X window system needs quite a lot of ressources (CPU and RAM)
There is a way of using QT without X, but this is not straight-forward and not widely used, and also I'm not sure if it works at all on the Pi
There needs to be some way of switching between EZ Video/OSD and QGroundcontrol, which is also not trivial because hello_video and the OSD just draw 'above' everything, I'm not sure what happens when X is running, maybe it works, maybe it doesn't, maybe it creates strange issues (for example, having too many dispmanx layers can cause random hdmi signal drops).
QGroundcontrol itself needs additional CPU and RAM ressources
The additional CPU and RAM usage of QGC and X compete with existing applications, less RAM available means shorter recording time when using the ramdisk, less CPU available can mean lost wifibroadcast packets and/or delays/glitches
The CPU load being low on the RX depends on several factors, when using wbc with higher bitrates, more FEC, plus additional CPU-intensive features like forwarding the videostream via RTP, it can get quite high
And keep in mind, the CPU load being displayed is a sum of all four cores averaged over 0.5 or 1 second. However, a single core being loaded 99% for only 100ms can (and will) already lead to packetloss and/or delays/glitches. In general, I'd say we want to keep CPU load well below 50% (per core) to make sure process scheduling doesn't get too 'jittery'
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#172 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF3v2yCCD8dIIs8TnvUH-7bxxj7SWkQGks5usHEfgaJpZM4X8dDu>.
|
If you are can access terminal on GroundPi and run commands then you can try to run top command that would show PCU usage alternative if to pis not installed then ps should be there. And this command will show top 10 processes taking most CPU sorted with highest in top. ps -Ao user,uid,comm,pid,pcpu,tty --sort=-pcpu | head -n 10 |
Let's try to keep things on-topic please. Regarding the original topic: |
Alright - added a postponed label. I agree that this is a "chrome bar" that could maybe added in the future. It was initially thought about this because very low CPU usage was observed on the GroundPi - hence the idea war born that the GroundPi could easily handle more load. Will observe the CPU load topic on next occasion and open a dedicated issue for that if needed. |
Hi @Yes21 and you other guys! I'm the guy that got QCS working on the PI and made the howto @Yes21 referred to. I got QGCS running on the PI without a X system, but there was a problem regarding how QGCS handles new windows. Later I got QGCS running within PIXEL. I had to put the project on the shelf due to moving and refurbishing a new house. I will soon have my new workshop up and running, and I will make a new attempt on making this work. I just have to find some free time. For my new attempt I have ordered a PI3B+. My GCS setup uses two PI's and two 7" LCD's. One PI will be running the GCS software (QGCS) the other will handle telemetry, RC control and video link (EZWB). I will update my thread on the ardupilot forum when I get started again. Alex |
Hi @JAR4x4 welcome to you here. It's a great pleasure to meet you here !! Perhaps you know we are preparing EZ-WBC 2.0 ... |
Thanks @Yes21 ! I just got 1.6-RC6 up and running on my prototype PI0 FC running ArduCopter. I will try to build 2.0 as soon as i find some time. Now that I have a new diy FC to play with, I will try to work with the QGSC as well |
@JAR4x4 Perhaps the first thing to do would be to try to install QGC on a non modified latest raspbian. If it works, then we could try to install it over EZ-WBC, and see ... If you are interested in doing that, I can try to help you. If you are Ok, we could open a "PiQGC" project on github, to not pollute this github. |
@Yes21 hi again! Yes, my plan is to get QGCS working on a non modified raspbian install first. My current prototype setup consists of two PI's. My first plan was to use one to run the mission planning software and host the telemetry link and rc over mavlink with a custom joystick controller board. The other PI only video over gstreamer. I have installed it in a rugged Pelican case. With my previous QGCS attempt, gstreamer worked fine and with minimal video latency with a regular wifi connection. Now the "video PI" runs EZ-WBC with bidirectional telemetry and the second PI will hopefully run QGCS again. I deleted the SD card with working QGSC by accident. I'll try to compile QGCS again this week if I find some free time. If I can get it to work, I'll make a image that I can share with those interested. I'm not a coder either, I have learned the hard way (Google). I'm more of an hardware and mechanical solutions guy ;) Yes, a separate PiQGCS project on Github sounds like a good idea =) Alex |
Awesome! |
@JAR4x4 Ok, I will create tomorrow a new "PiQGC" project on github. Please, when you will try to compile again QGC, take notes of all you are doing, and try to do most things with linux command line (if you can ...). Then I will try to use your notes to write a bash script to automatize all the compiling sequence. If I don't manage to write this script, I'm sure that other more experimented contributors will help us to do it ... |
@JAR4x4 I've created the github. I've created an issue, where we can have a conversation. Is it convenient to you ? |
We did discusse this idea with @careyer yesterday ...
It would be awesome to have QGroundControl running on the groundPi, particularly for those who are building DIY RC with a Pi 7" touch screen. This could avoid the need of an external smartphone or tablet and latency problems between the groundPi and the smartphone/tablet.
With QGC we could switch between video and map, changed FC's parameters, do calibrations, upload waypoints, make the uav follow it in auto mode, etc ...
If we could make run QGC on the groundPi, it will be important to have the choice to display either the legacy OSD or QGC (with video stream from WBC and bidirectional telemetry).
In theory it is possible to compile QGC on raspbian, since it already compiles on Linux, Android, IOs, ... But this is really difficult because one should also compile QT.
The QGC developers are not interested in a RPI build !
A guy has succeed in cross-compiling it in 2018 : https://discuss.ardupilot.org/t/how-to-cross-compile-qgroundcontrol-for-raspberry-pi3/26790.
I've tried to follow his guide, but ran into errors from the first commands !!
If some one is interested in that subject, he could try to compile QGC on the latest @RespawnDespair image, because it has the Rasbian version that EZ-WBC 2.0 will use.
Give your opinion, and try to compile if you are interested in ...
The text was updated successfully, but these errors were encountered: