I recieved my RT1062 yesterday and compared to the H7 its a realy big Step.
Some questions:
In the April Tag examples are still the "if omv.board_type() == “H7”… and so they ar not running without deleting these lines of code.
Apriltag detection works with ROI up to 500x500 widows size (this is really great). If the window ist larger it doesn t crash anymore but you dont get any findings.
In the mjpeg_streamer_ap: The IP Adress is “http://192.168.4.1:8080/” and the SSID is “PYBDF905” and not “OPENMV_AP”. (I did not change the column: "SSID = “OPENMV_AP” )
How could this be?
The frame rate on my pc is much higher than on my smartphone. Is that correct?
The rtsp video stream is somehow working (i get the message 20 fps in the serial monitor) but on the VLC player (Windows) and on the RTSP Player (Androidphone) I only get a black screen with some “flickering”. If i change the resolution of the camera the size of the VLC - window is also changing so some information is comming through.
Could i run a apriltag finding on the images before sendig them ?
One more questions:
are there any plans for a much more powerfull hardware? (i know there ist open CV and a lot of software for the Jetson but your software is so nice and easy to work with… )
Thx alot and kind regards
Julian Tacke
P.S. looking deeper inside the Problem with the RTSP Viedeostrem i found an app working but there is a one second latency (sadly not possible to reduce the buffer). The freeware app (RTSP Player) seems to display a small and a larger picture successively resulting in a black flicker…
Hi, thanks for pointing that out. Yes, I can get those examples fixed.
Regarding the SSID default name. That gets set in the main.c file. We can change that default. However, it’s supposed to be assigned when you create the AP. Can you post another thread about that as a separate issue. There may be a bug there.
Regarding AprilTags, yeah, once the resolution gets really high on that the algorithm starts get into some memory allocation patterns that we don’t optimize the code for. Basically, we are building a malloc heap inside of a stack to deal with its allocations. I optimized the code for smaller resolutions. I can put some work into it though to make it go at a higher res… but, given the frame rate is down near 1 FPS once you ge that large I’m not sure if it makes sense to. We have a pending action item to actually update to AprilTag 3 which may make more sense to do.
Regarding RTSP streaming, please use FFMPEG. You can play a stream from the video tools in the IDE. There’s some type of issue with handling our JPEG image formats that causes no video to display for VLC and other players. I’m not sure why our JPEG files are not accepted. They are valid baseline jpegs. This is though something to debug more. Note, once we enable OV5640 jpeg mode on the RT1062 we can stream those directly as they are accepted by VLC as okay versus what is produced by our jpeg compressor. Our default FFMPEG launch command from the IDE should give you under 1 second of latency.
Yes, you can do whatever you like to the image before streaming it.
As for a higher end model, yes, we’ve got plans. I don’t want to say much more right now. But, please stay tuned over the coming year. 2024 will be big for OpenMV. Orders upon orders of magnitude more performance.
That said, there will still be bugs, there are always bugs. Got fix ‘em and move on.
Thank you so much for your very fast reply.
Using the FFplay from the IDE or from the shell gives these messages (I don t get a video window):
…
[rtsp @ 000002023c02b900] RTP: PT=1a: bad cseq 8f8c expected=8174
[rtsp @ 000002023c02b900] max delay reached. need to consume packet
[rtsp @ 000002023c02b900] RTP: missed 3609 packets
[rtsp @ 000002023c02b900] Received packet without a start chunk; dropping frame.
[rtsp @ 000002023c02b900] Received packet without a start chunk; dropping frame.
Last message repeated 7 times
[rtsp @ 000002023c02b900] Reserved q value 100
[rtsp @ 000002023c02b900] Received packet without a start chunk; dropping frame.
Last message repeated 3 times
[rtsp @ 000002023c02b900] max delay reached. need to consume packet
[rtsp @ 000002023c02b900] RTP: missed 2 packets
[rtsp @ 000002023c02b900] Received packet without a start chunk; dropping frame.
… (and so on, i just copied a short sequence)
Or is this a problem with my PC?
So the 1 second lag is normal using rtsp streaming?
Do you happen to know why streaming to a Browser on my PC using “mjpeg streamer app” works great and without lag, but to a browser on a cell phone it is slow and often stops for 2 or 3 seconds (I tried three browsers on two cell phones).
Many thanks in advance.
Julian Tacke
I’m so interested in streaming because if I want my robot to follow me using April tags, it would be incredibly practical to see on my phone what the bot sees… would make everything a lot easier.
Regarding the difference in browsers, it’s related to app. It’s not actually a device issue. Many systems assume MJPEG is recorded video so they don’t try to deliver frames in real time. In our FFMPEG command we explicitly tell the software to have a low lag.
Regarding faster video to the PC. I would like to spend some time getting WiFi debug working on the RT1062. However, it’s not a priority right now so I can’t comment when we can get WiFi working via the IDE and debug back to it. This would offer the best performance as we could make it the most real time.
Operatung System is Windows 10 (no second video window is opend).
But please don t waste your time in checking this. This matter is not important. I dont need streaming to my PC.
Maybe there was a misunderstanding, but video on the browser on the PC works great.
Faster Streaming to a mobile Phone either via browser or via RTSP would be great.
But as far as I understood you, I just had to be patient a little.
I will look for a Mjpeg player app for my smartphone maybe this also will solve my problem.
It’s weird that MJPEG from to the phone doesn’t work. That’s such a simple protocol that there’s really nothing going on there. The only thing I can think of is that our jpeg images aren’t liked. They probably all use the same library backend.
FFMPEG appears to handle any valid JPEG type. However, VLC can only handle YUV422 JPEGs in RTSP mode. When reading MJPEG videos from disk it can handle all formats. Your phone programs are probably suffering from the same issue.
Anyway… what I can do is downgrade our JPEG code to output YUV422 images always via some type of settings or whatnot. I’m not sure what the approach will be. But, this is very fixable.
On the RT1062. Set the jpeg quality to 50 from 70 in the example script and you’ll see the video immediately start working since this selects our internal YUV422 path. Note, the lag in the video is not related to our code. That’s buffering on the program side. You have to disable that via the program.
Setting the quality lower than 35 will break the video again as then we switch to YUV420 which cannot be processed by VLC. FFMPEG has no problem with this.
Finally, as for the network issues you were having. The MJPEG overread 8B issue appears to be a problem with FFPMEG, that can be ignored. I debugged our final format and found no issues with our JPEG files. However, if you see dropped frames and segments and etc that’s just wifi packet corruption. you need a better signal and etc. in that case.
…
Note, I noticed VLC cannot handle grayscale JPEGs too. So, it will only work with color YUV422 images.
Thank you so much.
Maybe a last question: In the discription it says, i can connect a external UF.L Antenna but i could not find a documentation or a Antenna plug on the camera…
It’s a build option. The chip antenna can be removed and a UFL antenna installed instead.
You can technically do this by hand with a soldering iron if you want. But, it’s more for anyone who purchases a large volume of cameras and wants a different build style.
Hi, I was wondering if you could help please - I could do with some more wifi range on the test camera I have, as I am on the limit. I can see the pads for the UFL antenna. What do I need to do to disconnect the built in one?
Hi, there’s an inductor in the middle of the uFL pad and another small 0201 cap. Remove those and then solder on the UFL connector and you are good to go. You don’t need to remove the chip antenna.
If you want to go back to the chip antenna the inductor and 0201 cap aren’t necessarily needed. So, you don’t need to save the parts per say
Hi, I could get one pad down, but not two before the u.fl connector disintegrated. So I had to stop after about 6 attempts. What would the minimum order quantity be for the factory to do this?
Hi, I didn’t mention the cause of the unscheduled disassembly of the u.fl connectors. I didn’t manage to get any solder onto the gnd pads. The main aerial pad was easy. But whatever I did I could not tin the gnd pads in the first place (or by attempting to solder the aerial which was fine and then the gnd pads - just in case there was enough solder from the reflow process already there.)
