I am operating robot vaccums since the Mi Robot Vaccum came out. Actually I stayed with the Mi Robot Vaccum quite a long time until I decided to upgrade to a Roborock S7 Pro Ultra (white). I bought it right at its release and I was very satisfied with the cleaning it was doing.
Lately I read about the S8’s new feature: It can dynamically extend it’s side brush to better reach edges and corners. Some research later I noticed the Qrevo Master which has two rotating mops instead of one vibrating mopping pad. I think on a tile floor the rotating mops could probably do a better job.
When I finally read that the Qrevo Master can even extend one of it’s mops I decided to buy one. So now, let’s see if it was worth it…
First impression of the Qrevo Master
I am not an unboxer so we will skip the images but I can say as always Roborock did a very good jop packaging the device. It comes in a cardboard box with tons of packaging material. So it should be super safe even if it gets dropped from the delivery car.
Then attaching all the parts together I notiec the dock is quite a bit less wide but higher than the S7 Ultra dock. Also the dust bag has moved from the top to the “middle floor” and is about twice as big. The tanks for fresh and grey water seem to be a bit bigger, too. (This is not a tech comparison advert review but an experience report so forgive me, I did not check the technical details)
The dock now also features a hot air mop dryer as well as hot water washing just as the S8 one does, too.
Most important features for me
As I already said, for me the “killer features” were the ability to extend the side arm(s). I was hoping to get the area at the kitchen base cleaned (which the S7 failed on). It is always these last few – about 10 – centimeters below the drawers. They are exactly 1mm higher than the robot itself so the robot does not drive below them.
Also another feature I wanted was the reactive AI as I always had issues with the S7 getting stuck on the base of my bar stools and the feet of the clothes horse which is only a horizonal 15mm pipe.
First try
So after unboxing and assembly (whch took me just about 10 minutes) I placed the dock where the S7 dock was before. I removed everything that was laying around to give the bot a fair chance for its first journey.
That said, I should probably also say that I did not clean up the floor for a few days at all for the robot to have a challenge.
I allowed the bot to map my ground floor and then I started a first cleaning eith its default settings. The cleaning took about as long as with the S7 but the bot is a lot more silent. I observed parts of it’s work and took some pictures to describe the issues I am seeing (next section).
After the Qrevo master finished its first cleanup, I reviewed the results and I unfortunately have to say: It does not look more clean than with the S7.
Problems observed with Qrevo Master
#1 Doors
The first thing I noticed, was that while the robot has its extendable arm, it handles it wrong. What I mean is, that it does unextend the arm when driving abround a “sharp angle” and extend it again too late. This causes a “blind sport” as you can see in the picture below.
#2 Outside Corners
I put a box on the ground. Same issue as with the door so it does not matter if its a door or an actual 90 degree corner.
#3 Door stopper
Whoops… This one is even worse! Guess it’s the same issue in the navigation logic
#4 Bar stools
This one is bad. The reactive AI feature detected my bar stools as posts and decided to omit them. While this is a wise choice, as my S7 always got stuck as it tried to climb the bases, I don’t understand why it does not drive through the corridor between them. There is plenty of space for the bot to pass through
#5 Kitchen dirt
This was left over by the bot (after I left it over for him actually). It did not detect this and did not try to clean it again. A manual second cleanup with higher suction power solved this.
#6 Kitchen base
Uh oh! The Qrevo master does sweep dirt under the table. Well not actually the table, but the kitchen base. The picture might make it look as if the space is very deep but the dirt actually is laying just about two centimeters beneath the front edge.
How the Qrevo Master performed
In the end I have to say all these issues are not worse than the S7 pro ultra performed for me. But it is not what I expected from the Qrevo master.
Why? The extendable arm does not reach its full potential in its current state. I think a firmware update can solve this but roborock will have to invest more into the navigation code to make this valuable in my eyes.
The Bar stool thing is probably a result of the camera viewport and could also be improved by software. Unfortunately I only have the option to totally ignore this.
The Kitche Base issue is the thing that really annoys me. I was hoping that an extendable side brush as well as an extendable mop would make this much better. But it does not. The result is actually exactly the same as with my S7 pro ultra here.
The only thing that is noticably better is the room edges or edges around furniture (except the corners) as well as the cleaning under the hanging toilet. The S7 always left a small spot which the qrevo “master”s perfectly well.
Worth it?
If I would sell my S7 pro ultra combo I’d probably have a chance of getting it sold for about 400-550€. The Qrevo master costs 1099€ at the moment so the invest is about 600€.
Actually I am not sure if the upgrades are actually worth the 600€ they cost. If the arm would perform better and the AI would do a better job on the bar stools I’d say yes. Unfortunately there will probably be no way to get the robot driving a few centimeters unter the kitchen base. The LIDAR is higher than the edge. To clean up the floor completely it would need to allow the bot’s main shell to go beneath tha. I guess I won’t get this with any new model right now.
A positive finding I have to share is, that it did not get stuck anywhere at all. Except the main brush when it tried to eat a clothespin. (AI? Where have you been? 🙂 ) Also the carpet cleaning works noticably better than with the S7 Pro. The stronger suction power of 10.000 pa ist a great upgrade.
I will be writing to roborock, showing them this article to see what they say about my observations. Maybe this helps in deciding if I will keep the Qrevo master in the end.
Links in this article are affiliate links. By buying stuff from amazon using these links, I will get a share from amazon. This way you are supporting my doing without any extra a cost.
Lately I got my hands on a cool new project, utilizing a Cisco PrecisionHD TTC8-02 Telepresence camera (More to come…). In this blog post I want to comapre two different methods to capture this camera, using a HDMI grabber, in 1080p30 (1920×1080 pixels with 30 FPS), using a Raspberry Pi 4B (2GB in my case).
Preparation
Before starting, I installed Pi OS (Bullseye) on my device. I did all the following tests, using a WIFI-Connection on the Pi and OBS (media source) as a client. As the builting WiFi was not feasible enough in my case, I added an external WiFi-Stick. This post will not cover installing OBS, a Wifi Driver or Pi OS etc.
To use the hardware acceleration for encoding, we have to add this line to /boot/config.txt:
dtoverlay=vc4-fkms-v3d
Why external WiFi?
Originally I wanted to use Dicaffeine to NDI-Stream the HDMI source using a cheap USB HDMI Grabber (Ref-Link) from Amazon.
I did not manage, to receive the vido on my PC. I always saw the source, but never received a frame. Even with a custom-compiled FFmpeg I got no success using NDI at all. Not even a 720p5 test video. On Ethernet, all worked fine.
This lead me to further diagnostics… In my environment, WiFi is a nighmare. Long story short, I did some download tests:
Connection
Measured speed
Builtin WiFi 2,4GHz
300 kB/s
Builtin WiFi 5GHz
0.5 – 1 MB/s
External ancient WiFi “g-Standard” dongle (2.4 GHz)
3 MB/s
New external WiFi Dongle with external antenna
160 MB/s
I think the results and my reasons to use an external adapter are quite clear. In my case, the driver had to be compiled manually and required setting arm_64bit=0 in config.txt. I am pretty sure it will also work with internal WiFi in cleaner air 😉
Test environment
I created a busy scene on my desk. Then I positioned the camera and did wire it directly with the USB grabber, which is connected to the Pi’s USB2 interface (The stick is only using USB2).
For the CSI module tests, I got my hands on this CSI-2 connected HDMI-grabber. For these tests, I removed the cable from the USB-Grabber and connected it to the CSI-Grabber.
All hardware configurations have been made before the tests, so the environment is identical on all tests. Both grabbers were always connected but the other inactive at the time of testing.
The Pi sits in a case (ref link) that is cooled by a small “Pi Fan”.
I installed gstreamer from the official repo using th following command. Please not, it installs quite everything…
Installing the USB-Grabber is easy. Connect it -> works. It does not require any configuration or setup.
The CSI-Grabber is a bit more complicated:
First of all, update your system (apt update && apt -y full-upgrade), then enable the overlay by putting this line into /boot/config.txt:
dtoverlay=tc358743
This can be a second line, right below the previously added line.
Then we need to edit /boot/cmdline.txt and add cma=96M to the beginning, The whole line will start like this:
cma=96M console=tty1 root=PARTUUID=...
After a reboot, the device should be up and running.
Warning: In the following commands, I am always using /dev/video0 for the CSI and /dev/video1 for the USB-Grabber. Adapt the commands to your setup. If you only have one, it is likely /dev/video0
Setting up OBS
You can use any receiver software of course, but I an using OBS as this camera will be used for streaming later on. The media source must be set up like this (use your Pi’s IP address instead of 111.222.333.444):
The important settings are marked with red arrows. Actually, I did not notice any difference without latency=0 but I read somewhere, this was an option to reduce buffering.
Running an SRT-Stream using the USB-Grabber
Now that OBS is set up, we can start the stream (or we could do this before OBS is up). The following command works pretty well for the USB-Grabber:
Using this command, the delay (cam to OBS) is about 1 second in my environment. The color quality is good and the framerate is consistent after a few minutes runtime.
This command lowers the delay to about 0.8 seconds by using the basline profile but the color quality is much worse (see the comparison below). CPU-Usage and framerate are widely identical:
Then I did the same expriment, using the CSI module (ref link) C790 from Geekvideo. Here we need some more setup before we are able to stream. Unfortunately this need to be done after each reboot, else GStreamer will not start. Again: this is not a tutorial but a technical experiment and report, so maybe I will come up with a solution later.
Step 1: Create an EDID file
Create a file, called edid.txt, containing the following – copy exactly!
This file controls the capabilities, the adapter advertises on HDMI to the source device. This specific variant locks it to 1920x1080p30. The file can of course be re-used for later reboots.
Step 2: Apply EDID-Info and configure Video4Linux driver
First, apply the EDID-File to the device using
v4l2-ctl --set-edid=file=edid.txt -d /dev/video0
Next, we configure Video4Linux to the correct timings:
This variant caused slightly higher system load than the “bad color” USB variant, causing a lower delay of only 0.4 – 0.6 seconds
Image comparison
I created a side by side comparison image using the two grabbers. From top to bottom:
USB with baseline profile / USB with main profile / CSI with main profile
Regarding load: A second try caused much lower CPU-Usage on Test 2, so maybe the CPU-Usage is not accurate.
As you can see, the USB-Main variant has the best image quality, directly followed by the CSI-Variant. I think this could possibly be tuned further but as we’re using the same encoding settings, I fear that it comes largely from the chip. Regarding load, the CSI-Approach is the clear winner when relating quality with load.
The next day… RGB!
A day later, I remebered that I read somewhere, this CSI-Thing would be capable of UYVY as well as RGB. So I gave this another shot. Here is the commandline:
And this is the result comparison. Delay is identical to the UYVY variant, system load is slightly higher. I think the colors are a little better (bottom is RGB, top is UYVY)…
…but compared to the USB-Grabber, the result is still worse – USB top, CSI bottom:
I also got knowledge about a new chip (Thank’s to pr3sk from JvPeek’s Discord), built into newer USB 3 grabbers. I just ordered one of these and will report in a seperate post, if those are maye “the solution” to everything 🙂
Interestingly, the CPU-Usage while grabbing from USB was much lower this time.. I got no idea why… Maybe the load comparison from yesterday was garbage…
End-Results
I can say that both approaches seem to work. It looks like the USB-Variant is a bit less stable (in a few tries, the stream freezed after a few seconds).
After all, I am not really sure how to proceed. The CSI-Variant is much more performant and never had an outage while testing. Regarding image quality the USB-Variant (with main profile) is clearly better.
I am not a gstreamer pro, so maybe someone has ideas on how to improve these pipelines? Feel free to comment!
Updates
August, 22: Added source declaration and further explaination to EDID-File
August, 22: Added section “The next day”
Manage Cookie Consent
Wir verwenden Cookies, um unsere Website und unseren Service zu optimieren.
Funktional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
