text:
The VG Performance with only image input

Thanks for your great work! May I know whether have you done the VG experiment with image only input?

Another question is that in the visual grounding task, it seems that each query will only predict the logit to represent it is/ isn't the target object. However, I wonder how to obtain the 3D bounding box for each query?

Thank you for your interest in our work~

We have not conducted a rigorous experiment in this codebase. In our early study, image feature alone has > 5% performance drop compared to image + voxel + point feature.
3D bounding box can be computed by using mask for each query.

So actually, the visual grounding task involves two heads: mask head and grounding head? The former is used to generate the instance masks, and the latter is used to produce the score for each mask whether it belongs to the target object.

authors: ZCMax zhuziyu-edward


text:
"Invalid lineage in group, verify the contents of the group call"

What happened?
Using the query from https://github.com/PRQL/prql/issues/3490#issuecomment-1712962873, I get an "Invalid lineage" message with the Playground (PRQL 0.10.1)
Is this still a victim of #3111 ?
PRQL input
from inv=invoices
join item=invoice_items (==invoice_id)
join t=tracks (item.track_id==t.track_id)

group {inv.billing_country, t.name} (
  aggregate (c=count t.name)
)

group {billing_country} (
  aggregate (
    sort (-c)
    take 1
  )
)

SQL output
Playground shows:

"Invalid lineage in group, verify the contents of the group call"

Expected SQL output
N/A

MVCE confirmation

[x] Minimal example
[X] New issue

Anything else?
No response

I don't think this is related to #3111, but it does look like a bug. Here's the example minimized:
from invoices

group {billing_country, customer_id} (
  aggregate (c=count invoice_id)
)

group {billing_country} (
  aggregate (
    sort (c)
    take 1
  )
)

Woah, this is a really bad error, as it does not give much information. It would be better if we panicked here.

Using main, this query now generates "pipeline expected type [{*..}], but found type func infer -> infer"

source: gharchive/issue

authors: aljazerzen max-sixty richb-hanover

repo: PRQL/prql

license_type: permissive

license_source: github-api


text:
false positives Archer 2.0.0 clang 6.0

Context
we are currently using Archer to develop a library for particle simulations:
https://github.com/AutoPas/AutoPas
With archer v1.0.0 no warnings were printed and tests showed that archer worked as it should (it only reported real errors)
We recently tried upgrading from archer v1.0.0 and clang v4.0 to archer v2.0.0 and clang v6.0 and were confronted with a lot of warnings:
Bug
With archer v2.0.0 we get a lot of warnings, mostly in pthread's mutex locking/unlocking see
archerlog.txt
They have the forms:
a) (clearly from the mutexes)
WARNING: ThreadSanitizer: data race (pid=811)
10:   Atomic read of size 1 at 0x7b6800005f40 by main thread:
10:     #0 pthread_mutex_lock ??:? (runTests+0x5a64a7)
...
10:   Previous write of size 1 at 0x7b6800005f40 by thread T8:
10:     #0 pthread_mutex_init ??:? (runTests+0x58f96a)
...
10:   Location is heap block of size 1504 at 0x7b6800005a00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T8 (tid=820, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_pthread_mutex_lock

or b)
10: WARNING: ThreadSanitizer: data race (pid=811)
10:   Write of size 8 at 0x7b6800005100 by thread T4:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10:   Previous read of size 8 at 0x7b6800005100 by thread T7:
10:     #0 memcpy ??:? (runTests+0x596f1c)
10:     #1 copy_icvs(kmp_internal_control*, kmp_internal_control*) /ArcherBuild/openmp/build/../runtime/src/kmp.h:1794 (libomp.so+0x86593)
...
10:
10:   Location is heap block of size 1504 at 0x7b6800004e00 allocated by main thread:
10:     #0 malloc ??:? (runTests+0x5b7d6c)
10:     #1 ___kmp_allocate_align(unsigned long, unsigned long, char const*, int) /ArcherBuild/openmp/build/../runtime/src/kmp_alloc.cpp:1492 (libomp.so+0x205a2)
...
10:   Thread T4 (tid=816, running) created by main thread at:
10:     #0 pthread_create ??:? (runTests+0x58f57b)
10:     #1 __kmp_create_worker /ArcherBuild/openmp/build/../runtime/src/z_Linux_util.cpp:853 (libomp.so+0xc40c9)
...
10: SUMMARY: ThreadSanitizer: data race ??:? in memcpy

Steps to reproduce:

Download autopas:

git clone https://github.com/AutoPas/AutoPas.git AutoPas

Use our docker image to reproduce the warnings:

cd AutoPas
mkdir build
cd build
docker run -v `pwd`/..:/autopas/ -w /autopas/build/ -it autopas/autopas-build-archer:latest bash -i -c "CXXFLAGS=-Wno-pass-failed CC=clang-archer CXX=clang-archer++ cmake -G Ninja -DCMAKE_BUILD_TYPE=DEBUG -DUSE_VECTORIZATION=OFF .. && ninja -j 4 && ctest --verbose"

Further information
I have tested it with the clang/llvm 6.0 version in ubuntu 16.04 (clang 6.0.0), as well as the latest official release from http://apt.llvm.org/ (also ubuntu 16.04, xenial).
The openmp reposity versions I tested are:

release_60 (d5aa29c)
latest properly working version from master (b1a95ef, from May 25, 2018), mainly before they started renaming a few things, e.g.,  ompt_frame_t to omp_frame_t

I only tested the archer master, as the v2.0.0 tag is actually identical to it.
All configurations I tested produced the same warnings.
The dockerfile can be found here:
for v2.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/blob/master/buildenv/archer/Dockerfile
for v1.0.0:
https://github.com/AutoPas/AutoPas-Dockerfiles/tree/master/buildenv/archer-v1.0.0
Closing words
I did not yet find the time to just test archer 2.0.0 on an example, so sorry for that.
Help would be appreciated :)

Please try:
export TSAN_OPTIONS="ignore_noninstrumented_modules=1"
This should remove these reports.

Thanks!

authors: SteffenSeckler dongahn jprotze

repo: PRUNERS/archer


text:
Snapdragon: some parameters don't want to stick

The param PWM_DISARMED just doesn't seem to stick/get saved on Snapdragon.
Also reported by @blandry.

The param seems to appear and work after param set PWM_DISARMED 900 has been called once.
@LorenzMeier any idea why this is necessary?

So you're saying that accessing it via MAVLink doesn't work, but on the shell does? Which shell? qshell or Linux side?

With param set PWM_DISARMED 900 I mean the Linux side.
When QGC/mavlink is used, it is also set on the Linux side, however, the save happens on the QURT side. During the save, the written param is not in the list here:
https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/param/param_shmem.c#L986

I'm pretty sure that the list logic there is wrong i.e. its dirty bit is not set or evaluated correctly. Note that there is a "unsaved", "non-default" and "used flag" and those have to be used correctly.

The "used flag" is not used on Snapdragon.
I just checked, and you can set a param from default to something in QGC/mavlink and it won't get saved with either: param save or qshell param save.

The problem seems not to be the "unsaved" flag here:
https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/param/param_shmem.c#L980

@mcharleb this is the param sync issue that I was telling you about earlier.

The problem is essentially that the local list of changed parameters on the DSP side is not kept up to date with what is changed from looking at the shared memory.
The local list not in sync is param_values in https://github.com/PX4/Firmware/blob/master/src/modules/systemlib/param/param_shmem.c#L971.
If you do qshell show param PWM_DISARMED it will update the local list and realize that it has been changed.
@LorenzMeier any advice how to patch this?

We need a param update / check API on the DSP side and then register it with the existing always-running daemons (e.g. the HRT) to run regularly.

But that would cause a race with the param save because you want to do the update before you do a save.

The right way to do this is to establish a lock so they can't race and of course always run the param update before a save.
It actually sounds like this is all what you need to do for now, since the param changed publication makes it to the DSP and we don't need a background process?

Ok, right. So I guess, the param update needs to loop through all params and check whether they have been changed. I'm trying to find the param from looking at the changed bit, that would be less cycles.

authors: LorenzMeier julianoes


text:
implement MAV_CMD_DO_MOTOR_TEST

Options -
Override in pwm module or turn motor_test into a module and disable attitude controller output?
Should we make motor_ramp a part of this?
https://github.com/mavlink/mavlink/pull/580

I think we need a direct actuator_passthrough topic to which all the topics subscribe and what they put onto the output. We could implement it accordingly: A flag wether this is scaled (-1..1 or PWM) and what the timeout should be. While the timeout is still running the mixer would be locked out.

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.
(This is an automated comment from GitMate.io.)

Still relevant I guess.


text:
How to get lower PWM output?

I am probably doing something wrong but here is a log file (1.5.3) when PWM_MIN, PWM_AUX_MIN and PWM_AUX_DISARMED are all set to 900.
However, as seen in the log and also verified before arming with a PWM reader the output was never below 1000.
Is this intended behavior? And in that case how do you activate the PWM_AUX_DISARMED parameter?

If you use a Pixracer there is only the main outputs, so you would need to change those parameters.

Ok thanks, but the question remains, how to actually get a lower output than 1000?
I tried again with:
PWM_MIN = 900
PWM_AUX_MIN = 900
PWM_DISARMED = 900
PWM_AUX_DISARMED = 900
When measuring the output on the throttle pin the PWM signal is never lower than 1000. Am I doing something wrong?

These values get applied to the outputs selected with the set PWM_OUT 1234 parameter (this is for the caipirinha). So they will only apply to ports 1-4 for this airframe. For other airframes they might apply to less ports. You would need to work with your airframe config and with pwm info to work out what is not set up correctly.

I believe this was an airframe issue. Please reopen if I'm wrong.

authors: CarlOlsson LorenzMeier dagar


text:
Aerotenna OcPoc failing to engage Auto in master

running master 3293fe4
successful flight with auto take-off and rtl as part of mission:
https://logs.px4.io/plot_app?log=593203b8-e65b-4a5a-9a9a-9cbd65ac5127
after landing, armed again but Auto would not engage
took off manually and still, Auto was not responsive:
https://logs.px4.io/plot_app?log=9fb47e82-36d9-4600-a868-c09b1df59bb0
swapped batteries and Auto still not responsing:
https://logs.px4.io/plot_app?log=0b6bd97b-721f-4acf-aacd-d7147bf9c73a

flashed current master ca42483
no change

@santiago3dr
I compiled a fresh PX4 binary from commit 13f2315 today(July 31).  I was able to load a mission, engage auto then execute the mission.  After the mission was complete I was able to toggle to manual, then back to auto and execute the mission a second time.  Would you please attempt to recreate your original scenario using the linked commit and see if this has any affect?

flashed latest master, mission upload looks to be working, will test fly later in the day.

I hope your flight went well!  Please do not forget to tag this issue if closed if you are satisfied.

Original issue happened again with some odd results
setup and execution:
flashed master daeb2d8
connected to qgc and loaded a flight plan
armed in stabilized and then engaged auto, successful flight:
https://logs.px4.io/plot_app?log=3d55c42a-00bd-44a4-8d07-ad0b4d442842
landed from previous flight and without a power cycle, armed in stabilized, switched to auto but qgc reported no valid mission:
https://logs.px4.io/plot_app?log=eef47b3d-5180-4347-b73d-86c29ae18912
Swapped batteries and without re-loading a mission, was able to execute mission successfully:
https://logs.px4.io/plot_app?log=0aff1b66-d387-4631-ad33-3ff840cc8333
landed from previous flight and without a power cycle, armed in stabilized, switched to auto.
successful take-off but copter idled at about 2 meter altitude without executing the mission
https://logs.px4.io/plot_app?log=5a3a391e-3aae-47b6-ad40-7fe7a37c55ce
qgc reported the vehicle was in Mission
Given the flight plan was not removed from the vehicle, this is only a minor inconvenience and I can simply power cycle between flights.
Thoughts?

Hi, I got an additional question, this is my first time see people using Aerotenna OcPoc, could you please send me some references about this flight control unit? Which version do we use for this, fmu-v5 or something else? Thanks in advance.

@santiago3dr Today(Aug -10) we rebuilt PX4 off commit 'daeb2d8'.  We where able to execute the same mission multiple times, adjust the mission, upload adjusted mission, and re-execute all in the field with no issues.  I would recommend clearing the SD card(personally I would re partition too). Then rebuild the firmware and load it all fresh.
@JohnSnowball  PX4's OcPoC documentation ,  OcPoC also has it's own User Hub.

i'll give it a shot

authors: JohnSnowball andrewmegaris santiago3dr


text:
DShot: updated driver to use NuttX DMA functions

Switch from bare-metal driver to NuttX DMA driver.
The code looks cleaner and it is easier to port to other boards by using NuttX drivers.
DShot will use NuttX DMAMAP naming as other components.
Know issue explained:
The problem was happening because of timer peripheral was running freely. That caused unsynchronised the first DShot bits while DMA started filling the DMAR register. Sometimes there was a bit missing sometime there was an extra bit.
image

Solution:
In burst mode, the timer trigger should be enabled after the DMA module. This is done with enabling UDE (Update DMA request enable) flag in timer after DMA is enabled. After DMA transfer is done UDE is disabled with the callback function because it needs to be disabled for the next cycle.

@Igor-Misic - Is DShot like one shot where there is only one pulse train sent per output cycle?

@davids5, yes. DShot drivers should be triggered externally (for example from the PID loop), but frequently enough that the ESC does not disarm motors.

@Igor-Misic - in that case I would expect to use the timers synchronously to the DMA not in repeat mode. Is that what is being done?

@davids5 - timers are used in burst mode (check TIMx_DMAR) and internal mechanisms take care that DMA is in synchronization with timer. We are only preparing data length, content and then we are enabling DMA and timer flag for DMA transaction. DMA then starts loading data to timer registers (CCR1 ... CCR4) over the DMAR register.
All PWMs (DShot bits) are triggered at once. If there are 4 channels per timer it means it will be triggered 4x16 PWMs at once.

@Igor-Misic If the bust is completed, why is the fix for the missing/extra pulse to use a call back as opposed to just clear the UDE flag prior to the DMA set up/start call?

@davids5 DMA is not able to put the data in the timer before UDE is set. Setting UDE will start DMA transfer and timers at the same time. If we clean UDE in callback when transfer is complete we can be sure that next time when we call DShot again, timer and DMA will be in sync.

@davids5 It works. It's a much cleaner solution.

@bkueng - I wasn't able to rebase because changes on the repo at commit 45c320  so I used  Merge branch 'master' into pr-dshot-nuttx-dma.

@bkueng do you consider this to be safe to go in to the release as well?

It should be, but as it's only a refactoring, there's no benefit and only risk in adding it.

Yer, I'm asking because I don't think we have a release branch yet, so we need to check.

source: gharchive/pull-request

authors: Igor-Misic bkueng davids5 julianoes


text:
Set default node id to 1, default bitrate to 1M

This change would allow to get the bus running on default settings, if the PX4 parameter system is unavailable (e.g. in APM).

Applied to master, thanks!

authors: LorenzMeier hsteinhaus


text:
Descend when GPS is lost in auto modes

We shouldn't just drift off when GPS is lost but descend.
This has been tested in SITL using gpssim stop but definitely needs outdoor testing. We'll need to come up with a way to fake GPS lost in flight.
@tumbili: thoughts?
@LorenzMeier: comments?
Fixes #4534.

@tumbili feedback please.

Bump @tumbili, @LorenzMeier please feedback!
A user just reported the same thing in #4674.
We need to merge this, it's better than what we have.

Can you rebase and not change the GPS check? That will fail arming for anyone wanting to fly manually.

@LorenzMeier I iterated more on this and found more things that seem not working at all, for instance the NAV_RCL_ACT param.
I'll do more testing before we can merge it.

@LorenzMeier I would say this is now a minimal change.

I have flown this outside on a Pixfalcon racer, and RTL worked on RC loss, however it didn't auto disarm on landed but went back into RTL.
I couldn't test GPS failure, we'll have to rely on SITL for this, I guess.
I think we can merge this once the RTL-landed-RTL toggle is fixed.

Ok - sounds like the toggle should be quickly fixable.

It's tricky because we need the landed check because we don't want to RTL if we're already landed.

Don't think so. How about staying in RTL instead? We can then switch to HOLD / loiter on auto-disarming

Hm, we could prevent the navigator from starting a RTL sequence if landed, maybe that's already in there.

Yes, it should be:
https://github.com/PX4/Firmware/blob/master/src/modules/navigator/rtl.cpp#L103

I cherry-picked 7481632c81a1019997f6b2d7fe61448963ce41cb but it doesn't seem to be enough.
It toggles between landed/in-air somehow, I'll need to dive deeper why that happens:
INFO  Landed: no
INFO  throttle: 0.40
INFO  Landed: no
INFO  throttle: 0.40
INFO  Landed: yes
INFO  LANDING DETECTED
INFO  throttle: 0.40
INFO  Landed: no
INFO  TAKEOFF DETECTED
INFO  RTL: on activation
INFO  RTL: land at home
INFO  throttle: 0.40
INFO  Landed: yes
INFO  RTL: completed, landed
INFO  LANDING DETECTED
INFO  throttle: 0.40
INFO  Landed: no
INFO  TAKEOFF DETECTED
INFO  RTL: on activation
INFO  RTL: land at home
INFO  throttle: 0.40
INFO  Landed: yes
INFO  RTL: completed, landed
INFO  LANDING DETECTED
INFO  throttle: 0.40
INFO  Landed: no
INFO  TAKEOFF DETECTED
INFO  RTL: on activation
INFO  RTL: land at home
INFO  throttle: 0.40
INFO  Landed: yes
INFO  RTL: completed, landed
INFO  LANDING DETECTED
INFO  throttle: 0.40
INFO  Landed: no
INFO  TAKEOFF DETECTED
INFO  RTL: on activation
INFO  RTL: land at home
INFO  throttle: 0.40
INFO  Landed: no
INFO  throttle: 0.40
INFO  Landed: no
INFO  throttle: 0.40
INFO  Landed: no
INFO  throttle: 0.40
INFO  Landed: no
INFO  throttle: 0.40

This is the nominal case when RTL is commanded:
INFO  throttle: 0.48
INFO  Landed: no
INFO  throttle: 0.48
INFO  Landed: no
INFO  throttle: 0.48
INFO  Landed: yes
INFO  RTL: completed, landed
INFO  LANDING DETECTED
INFO  throttle: 0.48
INFO  Landed: yes
INFO  throttle: 0.48
INFO  Landed: yes
INFO  throttle: 0.48
INFO  Landed: yes
INFO  throttle: 0.48
INFO  Landed: yes

@LorenzMeier: I've fixed the problem where it goes back into RTL after having landed on RC loss. It needed @ender-chen's commit, as well as one on top because I had added another switch case for POSCTL that needed the same fix.
I've tested this on SITL, and bench tested it with Pixhawk, and flown a previous version on Pixfalcon earlier, so I think this is safer than what we had before and therefore good to merge.

@LorenzMeier, @tumbili Can anyone review or test fly this? I'd like to get it merged as soon as possible.

@julianoes Can you suggest a safe way to test this?

The way I tested it in SITL is by using QGC joystick input as RC input, so when you close QGC it reports it as RC lost.
For GPS loss, I typed gpssim stop in SITL.
In outdoor flights, all I tested was switching off RC and checking if it RTLs. That's not particularly safe but not too crazy either with my small racer. Unfortunately, we don't have an easy switch to kill GPS on the fly yet.

Thanks. Now that you mention it, I have one 250 with GPS, so I could do the same with it. Or hack in an RC command to simulate both RC and GPS loss.

Does RTL actually mean return and land? My copter descended to perhaps 10m AGL, then went back up again.

@kd0aij you should set RTL_LAND_DELAY to not -1

Did any testing happen here? If not, I'm strongly suggesting to get it in.

This has been flown on a Pixfalcon quad again yesterday and everything was as expected. Let's wait for the CI checks after the last rebase before merging.

Ah this got merged, thanks :)

authors: LorenzMeier julianoes kd0aij whyscience


text:
drivers/mtd: add support to Macronix MX25LF25635F serial NOR flash

Add support to Macronix MX25LF25635F SPI NOR flash

Is this a backport from upstream NuttX or new work?

@dagar No, it is not a back port, the upstream doesn't include support to MX25LF25635F. However the SPI driver can be shared for series of MX25L NOR flash. The patch itself only adds necessary IDs and geometry information to the driver to recognize it.

Upstreamed and back ported here https://github.com/PX4/NuttX/pull/39

@davids5 oh, what a surprise, Thanks for the helping ;)

authors: Lampoo dagar davids5


text:
[Avoidance SITL] How to get PX4 ulog

When performing Avoidance SITL, I cannot find where firmware ulog is located.
In sitl_gazebo, ulog should be located in as in such as {path_to_px4_firmware}/build/px4_sitl_default/logs/
However, I couldn't find any ulog generated from Avoidance SITL
I'd like to know how can I get access to PX4 ulog for further debug.
Thank you.

If you are running SITL, one approach(which I find quite convenient) you can try is to log from QGC and upload to flight review automatically.

The flight controller logs are in ~/.ros/log/ divided by date. So a log from today would be in ~/.ros/log/2019-08-13

@Jaeyoung-Lim Thank you for sharing tip.But mavlink logging from QGC takes quite resources, causes lag on my desktop.
@mrivi I found the log in the exact path you mentioned, but it is little bit difficult to navigate, can we move SITL ulog to be stored under the directory somewhere like ~/.ros/px4_log.
It is just a suggestion, thank you.

authors: Jaeyoung-Lim SwiftGust mrivi


text:
[Backend] Add RKNPU2 backend support

PR types
New features
PR changes
Others
Describe
新增rknn backend

scrfd模型测试(屏蔽nhwc转nchw的代码)，几乎不存在误差
onnx推理结果

rknn推理结果

yolov5模型测试(onnx模型为yolov5 6.0固定shape为(1,3,640,640)),rknn模型存在比较大的误差
onnx模型推理结果

rknn模型推理结果

arcface模型测试(使用的模型为ms1mv3_arcface_r100 固定输入shape为(1,3,112,112))，存在一定误差，但是并不明显
onnx推理结果
--- [Face 0]:FaceRecognitionResult: [Dim(512), Min(-2.309219), Max(2.372197), Mean(0.016987)]
--- [Face 1]:FaceRecognitionResult: [Dim(512), Min(-2.288257), Max(1.995103), Mean(-0.003400)]
--- [Face 2]:FaceRecognitionResult: [Dim(512), Min(-3.243412), Max(3.875865), Mean(-0.030682)]
Detect ArcFace In Cpu Done! Cosine 01: 0.814385, Cosine 02: -0.059388

rknn 推理结果
--- [Face 0]:FaceRecognitionResult: [Dim(512), Min(-2.310547), Max(2.371094), Mean(0.016962)]
--- [Face 1]:FaceRecognitionResult: [Dim(512), Min(-2.287109), Max(1.996094), Mean(-0.003369)]
--- [Face 2]:FaceRecognitionResult: [Dim(512), Min(-3.242188), Max(3.873047), Mean(-0.030661)]
Detect ArcFace In Cpu Done! Cosine 01: 0.814365, Cosine 02: -0.0594706

yolov5问题初步判断是方框部分推理出现问题。
判断过程如下：
我输出了nms前的label和confidence，发现并无明显差异（误差1%以内），因此基本排除是label和confidence部分出错。
onnx nms前label和confidence
before_nms_onnx.txt
rknn nms前label和confidence
before_nms_rknn.txt
我输出了nms后的方框信息，发现存在较大差距，且体现在定位上，因此基本上可以认为是方框部分推理不准确，导致nms并没有过滤掉这部分本该“重叠”的方框。
onnx nms后的方框信息
after_nms_onnx.txt
rknn nms后的方框信息
after_nms_rknn.txt

目前测试出来的推理Bug的模型(2022-10-18)，等3588板子到了以后排查:

yolov5 6.0（坐标点计算出现问题）
MobileNetV3_small_x0_35_ssld（计算不准）

目前测试出来的需要重写后处理的模型(2022-10-18)

PaddleDetection系列（导出时集成了NMS等后处理操作，RKNPU2不支持，需要重写后处理）

repo: PaddlePaddle/FastDeploy


text:
sync recompute doc btw zh and en, test=document_preview

Sync recompute doc btw the Chinese document and the English document.

repo: PaddlePaddle/FluidDoc


text:
请提出你的问题
pipeline中语义检索示例运行报错。
运行python rest_api/application.py 8891后，报错：
11/23/2022 11:12:07 PM YAML version (1.1.0) does not match with pipelines version (0.1.0a0). Issues may occur during loading. To fix this warning, save again this pipeline with the current pipelines version using Pipeline.save_to_yaml(), or downgrade to pipelines version 0.1.0a0.
Traceback (most recent call last):
  File "C:\Users\riddle\code\PaddleNLP\pipelines\rest_api\application.py", line 35, in <module>
    from rest_api.controller.router import router as api_router
  File ".\rest_api\controller\router.py", line 17, in <module>
    from rest_api.controller import file_upload, search, feedback, document
  File ".\rest_api\controller\search.py", line 45, in <module>
    QA_PAIR_PIPELINE = Pipeline.load_from_yaml(Path(PIPELINE_YAML_PATH),
  File "C:\ProgramData\Miniconda3\envs\pipl\lib\site-packages\paddle_pipelines-0.1.0a0-py3.9.egg\pipelines\pipelines\base.py", line 274, in load_from_yaml
    return cls.load_from_config(
  File "C:\ProgramData\Miniconda3\envs\pipl\lib\site-packages\paddle_pipelines-0.1.0a0-py3.9.egg\pipelines\pipelines\base.py", line 820, in load_from_config
    pipeline_definition = get_pipeline_definition(
  File "C:\ProgramData\Miniconda3\envs\pipl\lib\site-packages\paddle_pipelines-0.1.0a0-py3.9.egg\pipelines\pipelines\config.py", line 51, in get_pipeline_definition
    raise KeyError(
KeyError: "Cannot find any pipeline with name 'query_qa_pairs' declared in the YAML file."

环境：
Windows10
CPU版本
paddle：2.3.2
python：3.9.1

please refer to this pr. https://github.com/PaddlePaddle/PaddleNLP/pull/3864
https://github.com/PaddlePaddle/PaddleNLP/pull/3864/files#diff-94255faa97c19cf211aebf24ee69352dbf3a9c2e85add003baefacaacfa00546
Add try exceptions:
try:
    QA_PAIR_PIPELINE = Pipeline.load_from_yaml(
        Path(PIPELINE_YAML_PATH), pipeline_name=QUERY_QA_PAIRS_NAME)
except Exception as e:
    logger.warning(f"Request pipeline ('{QUERY_QA_PAIRS_NAME}: is null'). ")

repo: PaddlePaddle/PaddleNLP