ndarray: could not broadcast array from shape: [2] to: [1] in item.loss.backward()

Describe the bug

My model can be trained when the batch size is one. But a fatal error happened when I set batch_size = 2.
=== PANIC ===
A fatal error happened, you can check the experiment logs here => './tmp/fsrs/experiment.log'
=============
thread 'training::test' panicked at 'ndarray: could not broadcast array from shape: [2] to: [1]', /Users/jarrettye/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.15.6/src/lib.rs:1529:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
   2: ndarray::ArrayBase<S,D>::broadcast_unwrap::broadcast_panic
             at /Users/jarrettye/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.15.6/src/lib.rs:1529:13
   3: ndarray::ArrayBase<S,D>::broadcast_unwrap
             at /Users/jarrettye/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.15.6/src/lib.rs:1538:21
   4: ndarray::impl_methods::<impl ndarray::ArrayBase<S,D>>::zip_mut_with
             at /Users/jarrettye/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.15.6/src/impl_methods.rs:2456:33
   5: ndarray::impl_methods::<impl ndarray::ArrayBase<S,D>>::assign
             at /Users/jarrettye/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.15.6/src/impl_methods.rs:2355:9
   6: burn_ndarray::ops::base::NdArrayOps<E>::slice_assign
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-ndarray/src/ops/base.rs:48:9
   7: burn_ndarray::ops::tensor::<impl burn_tensor::tensor::ops::tensor::TensorOps<burn_ndarray::backend::NdArrayBackend<E>> for burn_ndarray::backend::NdArrayBackend<E>>::slice_assign
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-ndarray/src/ops/tensor.rs:200:9
   8: <burn_autodiff::ops::tensor::<impl burn_tensor::tensor::ops::tensor::TensorOps<burn_autodiff::backend::ADBackendDecorator<B>> for burn_autodiff::backend::ADBackendDecorator<B>>::slice::Index<_> as burn_autodiff::ops::backward::Backward<B,_,1_usize>>::backward::{{closure}}
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/ops/tensor.rs:636:21
   9: burn_autodiff::ops::backward::unary
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/ops/backward.rs:78:20
  10: <burn_autodiff::ops::tensor::<impl burn_tensor::tensor::ops::tensor::TensorOps<burn_autodiff::backend::ADBackendDecorator<B>> for burn_autodiff::backend::ADBackendDecorator<B>>::slice::Index<_> as burn_autodiff::ops::backward::Backward<B,_,1_usize>>::backward
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/ops/tensor.rs:634:17
  11: <burn_autodiff::ops::base::OpsStep<B,T,SB,_,_> as burn_autodiff::graph::base::Step>::step
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/ops/base.rs:142:9
  12: burn_autodiff::graph::backward::execute_steps::{{closure}}::{{closure}}
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/graph/backward.rs:35:61
  13: core::iter::traits::iterator::Iterator::for_each::call::{{closure}}
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/iterator.rs:854:29
  14: core::iter::traits::iterator::Iterator::fold
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/iterator.rs:2482:21
  15: core::iter::traits::iterator::Iterator::for_each
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/iterator.rs:857:9
  16: burn_autodiff::graph::backward::execute_steps::{{closure}}
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/graph/backward.rs:35:27
  17: core::iter::traits::iterator::Iterator::for_each::call::{{closure}}
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/iterator.rs:854:29
  18: core::iter::traits::double_ended::DoubleEndedIterator::rfold
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/double_ended.rs:307:21
  19: <core::iter::adapters::rev::Rev<I> as core::iter::traits::iterator::Iterator>::fold
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/adapters/rev.rs:64:9
  20: core::iter::traits::iterator::Iterator::for_each
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/iter/traits/iterator.rs:857:9
  21: burn_autodiff::graph::backward::execute_steps
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/graph/backward.rs:33:5
  22: burn_autodiff::graph::backward::backward
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/graph/backward.rs:11:5
  23: <burn_autodiff::backend::ADBackendDecorator<B> as burn_tensor::tensor::backend::base::ADBackend>::backward
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-autodiff/src/backend.rs:42:9
  24: burn_tensor::tensor::api::float::<impl burn_tensor::tensor::api::base::Tensor<B,_>>::backward
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-tensor/src/tensor/api/float.rs:287:9
  25: fsrs_optimizer_rs::training::<impl burn_train::learner::train_val::TrainStep<fsrs_optimizer_rs::dataset::FSRSBatch<B>,burn_train::learner::classification::ClassificationOutput<B>> for fsrs_optimizer_rs::model::Model<B>>::step
             at ./src/training.rs:56:32
  26: burn_train::learner::epoch::TrainEpoch<TI>::run
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-train/src/learner/epoch.rs:108:24
  27: burn_train::learner::train_val::<impl burn_train::learner::base::Learner<B,M,O,LR,TO,VO>>::fit
             at /Users/jarrettye/.cargo/git/checkouts/burn-acfbee6a141c1b41/8808ee2/burn-train/src/learner/train_val.rs:131:21
  28: fsrs_optimizer_rs::training::train
             at ./src/training.rs:131:29
  29: fsrs_optimizer_rs::training::test
             at ./src/training.rs:157:5
  30: fsrs_optimizer_rs::training::test::{{closure}}
             at ./src/training.rs:149:11
  31: core::ops::function::FnOnce::call_once
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:250:5
  32: core::ops::function::FnOnce::call_once
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

To Reproduce
My model is complicated, so I haven't find a minimal script to reproduce the error.
For details, please see: https://github.com/open-spaced-repetition/fsrs-optimizer-burn/pull/16#issuecomment-1689326326
The code reproducing error: https://github.com/open-spaced-repetition/fsrs-optimizer-burn/pull/16/commits/23b8772eb2e8c56b1cda40cb66b08aa5d20772c8

@L-M-Sherlock does it work with other backends?

@L-M-Sherlock does it work with other backends?

It works with burn_wgpu. I haven't tested burn_tch because building torch-sys cost too much time.

I tested the tch backend. It was blocked by calculating loss.

Fixed with https://github.com/burn-rs/burn/issues/686


[pwrmgr] Verification sign-off for M2.5

This tracks open verification tasks for M2.5.
See effort estimation docs for details.

[ ] #17500
[ ] #14887
[x] Clean TODOs

CC @matutem @msfschaffner

@matutem I am not sure but we may be able to close https://github.com/lowRISC/opentitan/issues/18434 since it looks like you may already have done that.

The issue https://github.com/lowRISC/opentitan/issues/14887 was moved to backlog.


Cartridge loader exception

I think this one was fixed? I remember it being very annoying when it existed because guns would crash debug, and now they don't.


Link: New App - Initial Commit

Please ensure your pull request (PR) adheres to the following guidelines:

Please refer to our contributing documentation for any questions on submitting a pull request, link: Contribution Guide

Pull Request Checklist
Please check if your PR fulfills the following requirements:

[x] Testing of all the changes has been performed (for bug fixes / features)
[x] The readme.html has been reviewed and added / updated if needed (for bug fixes / features)
[x] Use the following format for the PR description: <App Name>: <PR Type> - <PR Description>
[x] Provide release notes as part of the PR submission which describe high level points about the changes for the upcoming GA release.
[x] Verify all checks are passing.
[x] Do NOT use the next branch of the forked repo. Create separate feature branch for raising the PR.
[x] Do NOT submit updates to dependencies unless it fixes an issue.

Pull Request Type
Please check the type of change your PR introduces:

[x] New App
[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation
[ ] Other (please describe):

Security Considerations (REQUIRED)

[ ] If you are exposing any endpoints using a REST handler,
please document them in the readme.html.
[ ] If this is a new connector or you are adding new actions

[ ] Please document in the readme.html all methods (eg, OAuth) used to authenticate
with the service that the connector is integrating with.
[ ] If any actions are unable to run on SOAR Cloud, please document this in the readme.html.

[ ] Are you introducing any new cryptography modules? If yes, please elaborate their purpose:
[ ] Are you are accessing the file system? If yes, please verify that you are only accessing paths returned through
the Vault API.
[ ] Are you are marking code to be ignored by Semgrep with nosemgrep?
If yes, please provide justification in an additional comment next to the ignored code.

Release Notes (REQUIRED)

Provide release notes as part of the PR submission which describe high level points about the changes for the upcoming GA release.

Initial commit of the Link utility app

What is the current behavior? (OPTIONAL)

Describe the current behavior that you are modifying.

What is the new behavior? (OPTIONAL)

Describe the behavior or changes that are being added by this PR.

Other information (OPTIONAL)

Any other information that is important to this PR such as screenshots of how the component looks before and after the change.

Pay close attention to (OPTIONAL)

Any specific code change or test case points which must be addressed/reviewed at the time of GA release.

Screenshots (if relevant)

Thanks for contributing!

Ready for review. All errors have been reviewed
"Min Number Log Statements" - using custom logging function (__print) to pass messages to save_progress and debug_print
"Licenses" - unknown what this requirements.txt file should look like
"Min Platform Version" - apps have existed for years and tested on many versions of phantom. 4.9.0 is intentional
"Repo Name Has Expected App Id" - unknown what the format of this json file should be
"Document Commonly Used Service Ports" - no ports need to be specified
"Action Names" - the app is named "link" and the action is "add link". This seems reasonable as is
"App Actions" - the action name "add link" should be left as is

Hi @zamastyle , we have checked your PR and added in our queue. We will soon start working on this and release the app


CourseCreation page says 'course successfully created' no matter what

I think this maybe a frontend issue? @Searay-330

Pretty sure it is, which is why I initially assigned myself. Don't know what Dave is up to.


[BUG] doom/increase-font-size increases modeline

What did you expect to happen?
Increase the font size everywhere via M-=, but keep the modeline size proportional to the font size. This might be related to #575.
What actually happened?
Increasing the font size works 100%, however the modeline is too tall.
Additional details:
See an extreme example:

Steps to reproduce:

Start Emacs
Keep pressing M-=

System information:

emacs   version    26.1
        features   XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LIBSYSTEMD LCMS2
        build      Apr 11, 2019
        buildopts  (--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd --with-pop=yes --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.1/site-lisp:/usr/share/emacs/site-lisp --with-sound=alsa --without-gconf --with-mailutils --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs-cQxEw2/emacs-26.1+1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro')
        windowsys  x
        daemonp    server-running
doom    version    2.0.9
        build      HEAD -> develop, origin/develop, origin/HEAD 318754c4d 2019-12-05 20:48:53 -0500
system  type       gnu/linux
        config     x86_64-pc-linux-gnu
        shell      /usr/bin/fish
        uname      Linux 5.0.0-31-generic #33-Ubuntu SMP Mon Sep 30 18:51:59 UTC 2019 x86_64
        path       (~/.local/bin /snap/bin /usr/lib/cargo/bin ~/x-tools/i686-w64-mingw32/bin ~/x-tools/i686-pc-linux-gnu/bin ~/x-tools/x86_64-w64-mingw32/bin ~/x-tools/sh2eb-elf/bin ~/.local/bin /snap/bin /usr/lib/cargo/bin ~/x-tools/i686-w64-mingw32/bin ~/x-tools/i686-pc-linux-gnu/bin ~/x-tools/x86_64-w64-mingw32/bin ~/x-tools/sh2eb-elf/bin ~/.local/bin /snap/bin /usr/lib/cargo/bin ~/x-tools/i686-w64-mingw32/bin ~/x-tools/i686-pc-linux-gnu/bin ~/x-tools/x86_64-w64-mingw32/bin ~/x-tools/sh2eb-elf/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /usr/lib/emacs/26.1/x86_64-linux-gnu)
config  envfile    nil
        elc-files  0
        modules    (:completion (company +auto) ivy :ui workspaces doom doom-quit hl-todo modeline nav-flash ophints (popup +all +defaults) unicode vc-gutter vi-tilde-fringe window-select :editor snippets fold multiple-cursors rotate-text :emacs dired electric vc :tools (lookup +docsets) eval editorconfig flycheck flyspell magit rgb :lang assembly cc common-lisp csharp data emacs-lisp markdown (org +dragndrop +attach +babel +capture +export +present) python (sh +fish) :config (default +bindings +smartparens))
        packages   (n/a)
        elpa       (n/a)

What have you set doom-font to?

I'm setting no font explicitly.
One more piece of info that I forgot to mention. I'm running Emacs (UI) via SSH forwarding on Windows.

Does the issue persist if you do explicitly set a font?

I forgot to mention that I have (setq doom-font-increment 4) set.
I removed it, and it looks less extreme.
I set (setq doom-font (font-spec :family "Fira Mono" :size 19)) with doom-font-increment, and it doesn't have the same problem.
It seems like doom-font-increment is what causes the issue.
Below is setting doom-font-increment to 16 and pressing M-= once, with doom-font set.

As of 84252d8 this issue should be resolved. Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!


Add support for nteract data explorer

https://data-explorer.nteract.io/
As easy as, adding the new mime type renderer from nteract:

User code change

import pandas as pd
pd.options.display.html.table_schema = True
pd.options.display.max_rows = None

Extension code change

Add mime support for mime type application/vnd.dataresource+json
Render using import DataExplorer from "@nteract/data-explorer";

Please also consider #10390


Fix TA config constraints

Change Summary

Related issue number
Fix #8326
Checklist

[x] The pull request title is a good summary of the changes - it will be used in the changelog
[x] Unit tests for the changes exist
[x] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

Selected Reviewer: @adriangb

A fix here might also help out with a fix for #8214

Closing this for now, as I don't think this is the approach we want to take (or at least, there are major things we'd need to fix). Can certainly be used as a reference in the future, though.


[tooling] Remove outdated step from GenerateDocs

This also removes the old setup for async APIs.

Docs Build status updates of commit 09615e9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

generate-docs/GenerateDocs.cmd
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/api-extractor.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/excel.d.ts
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/package.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/tsconfig.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/tsdoc-metadata.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a051493:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

generate-docs/GenerateDocs.cmd
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/api-extractor.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/excel.d.ts
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/package.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/tsconfig.json
:white_check_mark:Succeeded

generate-docs/api-extractor-inputs-excel-async/tsdoc-metadata.json
:white_check_mark:Succeeded

generate-docs/scripts/package-lock.json
:white_check_mark:Succeeded

generate-docs/scripts/package.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

@ElizabethSamuel-MSFT, good call. Removed the package.json statement.


Adds Low Bandwith Trajectory Follower implementation

@Zagitta  @gavanderhoorn  @ThomasTimm  - this is the promised pull request that implements Safe Trajectory Follower. It's a drop-in update - no public API changes, It should work out-of-the-box, you just need to add 'use_safe_trajectory_follower" as launch argument of the driver.
It is rather safe (it never "catches-up" dangerously by design), it behaves well and follows trajectory very well, it is resilient to communication problems, it works very reliable over WiFi (!) and it can run on heavily loaded PC. All that while controlling the position of the robot very precisely. It stops when the client disconnects (it finishes interpolation step before) and it is preemptible.
I believe for this specific case (no ros_control used, position-based control, MoveIt directly connected to the driver via "follow_joint_trajectory" action) - it has only advantages over the previous implementation and no disadvantages that I am aware of. I'd suggest that after some time it is proven, you might want to make it the default implementation (for this case). For now I added a switch "use_safe_trajectory_follower" which has to be set to true to enable it  (mutually-exclusive with ros-control). The nice side effect of the design I came up with is that you can freely control speedup of actual trajectory executed vs. the planned trajectory by MoveIt (basically Robot has it's own perception of time passing and we can control whether robot time flows slower, same, or faster than real time).  This is actually a very cool use case for research and development purposes. Note that the movies below are recorded at real time, it's the robot that moves faster :).
I prepared a set of snapshots from my tests showing several test cases (both movies and graphs showing how the robot behaved). Most of those tests were run with heavily loaded PC (normal camera + RGBD camera connected via ros node, recording of video, displaying point-cloud from RGBD camera in RVIZ). When we try to run the same case with "standard" Trajectory Follower under the load or with wireless connection, we got into dangeous "catch-up" almost immediately, This had never happened over my (already hours) of testing with the Safe Trajectory Follower. At most I got protective stop because I reached limits configured via robot setup, but it was always fully controlled behaviour, never uncontrolled "catch-up":
Here are the snapshots: https://drive.google.com/drive/folders/1N2Tu3OgWEZ6nip_XE0o9J0HvWkS4H5I1
Those are :

Wireless run with normal speed and heavily loaded PC
Wired run with 3x speed-up
Wired run wuth 3x speed-up and heavily loaded PC
Wireless run with 3x speedup and heavily loaded PC

The "normal speed wireless" charts are the most interesting ones - https://drive.google.com/open?id=1802exN_fbFWLpVbwtrop2SEFBcMAFTQp. It shows how well the driver handles delay situation that might inevitably happen when you use wireless even with my implementation. You can clearly see that it got delayed a bit and that then the "catching up" was really very local - it made the move a bit longer, but nothing dangerous happened.
All the documentation in README.md is updated - I explained the difference, parameters, and gave some examples of the speed-up configuration.
Note - the change is independent of my other pull requests - but it can be easily merged together (with small easy-solvable conflicts). I actually have also a separate branch where all the other pull requests are merged (NOMAGIC_ALL_MERGED). If you get to conclusion that we should merge all of them in one go - we could merge this branch (everything is rebased on top of the current master).
Also here is a context for some design decisions I made in this change - feel free to comment/or suggest other appraoches in case you have other ideas/suggestions for improvements, if you feel particularly unhappy about any of those.

minimal impact - first and foremost I implemented it with assumption to minimise impact on the current architecture of ur_modern_driver and implement it quickly. I think I managed to do both :).

supporting only V3+ - I decided to not implement support for pre V3 (servoj_gain + lookahead_time were added then). The driver will simply exit with helpful message in case someone tries to run it on earlier firmware. I think it is nice compromise between clarity and functionality - you can stil always disable safe trajectory follower if you want to connect to older firmware.

threading model/complexity of URSript - the architecture of the urscript is rather complex (especially threading model) - I have three threads that communicate with each other over global variables (protected with critical sections). Thanks to that I avoided impacting of potentially blocking operations (send/receive) on the control loop. Control thread runs the control loop independently from sending/receiving data. It's a bit complex but works very well - I can request and receive the next trajectory point while interpolating previous two points - without impacting the control loop at all. As a side note - this can be vastly simplified if we use RTDE interface. RTDE can handle send/receive exchange with the client using general purpose registries. I am planning to make another pyhon-only implementation of the driver (small subset of what the current ur_modern_driver does) using RTDE and then I will share my experience with you. It would be too much of an architecture change to implement RTDE in the ur_modern_driver as it is now (especially that python API is provided by UR). It seems that my design will allow eventually to run a smaller, RTDE-based python-only node for all UR communication for this specific case (not a full ur_modern_driver replacement)- those are my mid-term plans.

TrajectoryFollowerInterface - both Trajectory Follower and Safe Trajectory Follower implement the same interface (Trajectory Follower Interface). That allows me to use them interchangeably in the ActionServer. My relatively olde exprience cause some miusnderstanding of dynamic cast, but I think now it's relying on ros_control variable being mutually exclusive with Safe Trajectory Follower does the job. I decided that the interface will be pure-virtual (similar to Java interfaces) to make those two Followers more decoupled. There is very little potentially shareable code between those two and it's better to keep them decoupled.

add new/missing arguments to ur_common.launch - I added all new (and some old) arguments to ur_common.launch.. I see no harm in that as I added them with defaults. Having parameters in the default common launch might be helpful for other to understand that they can use different Follower. I have not added it for all the URX implementations though. I think common launch + README explanation is enough. Of course if you decide to switch to Safe Follower as default, you will have to update those :)

TCP/IP messages - I decided to use ASCII float array for sending trajectories rather than binary int array as was in the original follower. I do not really need to optimise it as it is send at few Hz and then it's easier to debug and understand what's going on when it is sent using plain ASCII (and the code is a bit simpler - no artificial multiplication to get to int from float and back). It seems to work very well even with ASCII.

Inefficiently reading line from TCP/IP server - Implementation of reading line from URscript using TCP/IP is quite inefficient (reading char-by-char). Classic. But since those messages are rather short - maximum 4 chararcter per message - it has no real impact at all. URScript only sends required next trajectory point number to the driver every time it starts doing interpolation for previous segment. I decided it's simpler to do it this way and not spend too much time to implement buffering (I'd love to use boost's read_until() but it's impossible without changing ur_modern_driver architecture to use asio - that would be far too big change.

I hope others who had similar problems will test it as well while you review it. I have friends in Poland at two universities that I asked to test it, and they said they will do. The "jerky" behavior is a pain for them as well. I hope we can get confirmation from others that it works as well for them. I'd love if we can merge it quickly and also that the whole refactor is merged into the main repo  - that would be awesome. The refactor makes it much easier for others - like me - to contribute.

@potiuk I have some time this Saturday to sit down and look through the code and let you know if I have any comments code-wise.
However I'm curious if you did any tests with PR #4 and whether it has any impact on your TrajectoryFollower?

@Zagitta Yep. I tested it at the very beginning - even before I implemented my low-bandwitdh code, and it seemed to help with the original driver a bit. In case of Low Bandwidth driver i think there is virtualy no impact, simply because we have so much less communication that neither of the settings has visible influence (and the whole algorithm is designed to handle any delays). TCP_NO_DELAY however (in theory) should be a a bit better, because it will immediately try to send any short message without waiting for few small mesages to batch (Nagle's algorithm). And we have no problems with unnecessary overhead because we have so small number of messages. It seems tha QUICKACK works better for the original trajectory follower, so maybe it's better to merge that change anyway, to improve it.

it might be great @axelschroth if you test again if you can see improvements after those changes (especially the precision). You can control how close you want to get with max_joint_difference parameter.

@potiuk sorry for my late reaction. First of all, great work this is a nice improvement! Unfortunately, we don't have access to the real UR any more, instead I did some testing with the official UR simulator. I measured a delay of ~0.2s as well (trajectory_follower needs ~0.1s) and the precision is much better than with the previous version of the low bandwidth driver.
However I still noticed, that with increasing speed/acceleration of the trajectories, precision gets worse. After doing some tests and examination (especially with low max_joint_difference values), I discovered following:

Since positions are transmitted as ASCII strings, precision of joint positions is 6 decimals in theory
Using higher velocities for a trajectory, the joint values may differ from goal by larger values as specified via max_joint_difference. Example:

This plot shows the end of the trajectory with measured joint value and goal position (max_joint_difference: 0.0001).
You can see a deviation of ~0.00015 which is higher than the specified max_joint_difference.
The reason for this behaviour lies in this line of URScript code:
while not is_final_position_reached(l_current_position):
    servoj(l_current_position,t=....

which should rather use l_end_pos instead of l_current_position:
while not is_final_position_reached(l_end_pos):
    servoj(l_end_pos,t=...

I've done some tests using this modification where max_joint_difference was also satisfied with high velocity and a max_joint_difference of 0.00001 (still using UR simulator).

Last point: in theory the robot may still be in motion when we reach the final positon. Maybe we should check whether we are at final position for a short period of time (or a few times) instead only once.

@potiuk I'm currently reviewing the code and I see that you've disabled LowBandwidthTrajectoryFollower for ROS control, are they fundamentally incompatible?
At first glance it seemed to me it should be possible to implement a execute method for a single position that works for both implementations if the if waypoint_received[0] == 0 check in LowBandwidthTrajectoryFollower could conditionally be disabled but it's likely I don't quite understand how the URScript works.

First thing first :). @axelschroth  - no problem with late reaction. I also do it partially on my free time/when I can, so I understand the delays, but it great that you are helping to test it at all!
I have not foreseen someone will test/notice that much precision differences, but Indeed you uncovered a flaw in the "adjustment" bit and your fix is a good one, although my final solution comes with one more change - only running the adjustment after the very last point in trajectory.
When I initially implemented the adjustment it was executed after every "coarse" trajectory segment - so not after every interpolation, but after every trajectory point provided by MoveIT. That's why I used l_current_position, because I thought it makes more sense.
If you look closely at the interpolation algorithm it will work fine also for points slightly outside the interpolated "segment" of the trajectory (so you can interpolate points also a bit after the l-end_time. since we have 0.008 (default) interval for interpolation, it might be that the last point calculated will be up to 0.007 s behind the actual trajectory time. And in case of trajectory points which are not the final ones, it makes perfect sense to adjust to position at that time (so current_pos as calculated by interpolation). Not so for the final position - because you want to end up precisely where you wanted, even if your time is longer than expected.  That was the intention, but I made a mistake :). If you look at the loop, current_pos was not calculated again if your time was after the segment time ended. It was calculated inside the if statement, and then the time was moved by TIME_INTERVAL but current_position was not calculated again! As the result, the previous calculation was used for current_pos which could be for time up to 0.007 BEFORE the final time, which explains the problem you noticed with not actually reaching the final position.
I tried to fix it and do the proper calculation, but it made me think that I made a wrong decision on "every trajectory point". Actualy I do not want to make adjustment for all the points in the trajectory - I only want to make adjustment for the very last point - because that's where I want to get precision. The way servoj works, even if on the way the actual positions for trajectory points are not perfect, it will automatically adjust as it will apply stronger forces if the expected position from previous servoj was not reached (because we are providing absolute joint values). So I realised I only should worry about the last point and there your end_pos fix makes even more sense. So in my fix I not only changed the end_pos but I  also moved it inside the "there are no more points in the trajectory" if: https://github.com/NoMagicAi/ur_modern_driver/commit/b4718ab4d251e5b564e85feb8ccc5185a8dd4780
Good catch!

@Zagitta : I fixed most of the comments. The remaining two are I think worth to think if this is a good time to fix them now (or at all). I might take a look but note I am on holidays this coming week and I have neither time nor the robot at hand to make any tests with it until 11th of Feb at least.
Please take a look and think if it's really important to fix those changes I have not implemented (moving params to ros_main, and ros_control-compatible version of LTBF).
I also made one more change which was not mentioned (https://github.com/Zagitta/ur_modern_driver/pull/9/commits/2ace46d824754eebda5c295258c7967fc5ac30ca).
That is a result of one of my friends testing it who have not yet commented here (he will!). He was using the urx_bringup* launch files and the safe trajectory follower parameters (and few of the original follower!) were missing/inconsistent there so he did not really realised initially that he was not using the LBTF. So my change brings all the urbringup launches also to a consisten state witha all arguments added.

Hello @potiuk, @Zagitta, @ThomasTimm. I wanted to let you know that we've been using your work in our application using a UR5, and it's working great for us. Excellent work. A few times when using the driver with ROS control before @potiuk 's changes during bringup the robot made a sudden swing from the base axis causing us to dash for the e-stop before something broke. I haven't seen this happen since using @potiuk  's pull request, but admittedly I have not tested with ROS control disabled pre-pull. I very much like @potiuk 's design where terminated communication still allows the robot to finish the move, and the robot does not have unpredictable fast catch-up movements.
I'm hopeful to see this great work merged into ROS industrial as a replacement to the current ur-driver because it is superior to what is currently there, and as it is now it's a pull request of a fork of a fork of a fork, and visibility is very low.

@psajecki: I'm rather confused: @potiuk's PR doesn't touch the hardware_interface, and ros_control 'mode' needs to be explicitly enabled in all versions of ur_modern_driver.

@gavanderhoorn , I don't claim to understand the reason why the sudden movement happened, and as I mentioned I did not test with ROS control disabled before merging in @potiuk  's code. I disabled ROS control to be able to use @potiuk  's work. The sudden unexpected movement did happen multiple times (one out of thirty or fourty runs or so?), and it did not occur since disabling ROS control and utilizing @potiuk 's work, and I thought this should be reported somewhere, and there has been discussion about ROS control.
My view that @potiuk  's design is a good one is not to say that @potiuk has fixed this issue. I very much like in @potiuk 's design how whole motions up to the stop are sent to the UR as a program because the thought of communication dropping while the servos are in motion otherwise is frankly scary.

My comment wasn't meant as criticism, I'm happy that the code is working for you. I was just confused, as, as I wrote, the ros_control code paths are not touched by this PR.

I very much like in @potiuk 's design how whole motions up to the stop are sent to the UR as a program [..]

afaict, that's not what is happening. The driver sends a trajectory point-by-point, depending on the responses of the program running on the controller.

@gavanderhoorn , no worries, I didn't take your comment as criticism.
About the workings of the driver, if you review @potiuk 's comments, when using the low bandwidth trajectory controller and sending trajectories using the follow_joint_trajectory action, the control-loop for the trajectory is run in URScript instead of the driver - at least that is the way I understand it.

Actually @psajecki I understand where it came from. The very same TrajectoryFollower is used  for ros_control with position control, so I'd expect exactly what you experienced.
I actually deliberately chose to disable the LowBandwidthTrajectoryFollower when ros_control is used, so I understand that you had to switch to direct interface. But the reason I've done it is quite prosaic - At Nomagic.ai we did not use ros_control in our setup from the very beginning and I would have to set it up for testing. I know it's likely fairly easy, but I wanted to focus on what we used - this way I could test it on a daiy basis, especially that (as you mentioned) it does not happen too often (but often enough to worry :)).
Actually it was also mentioned by @Zagitta in his code review from last week that it would be great to make it works also for ros_control  position based interface: https://github.com/Zagitta/ur_modern_driver/pull/9#pullrequestreview-93856924 but as I mentioned there - I am a bit reluctant to implement it and fully test on my own. However I don't think it's too complex to implement though and I could do it next week (after I return from my skiing holiday), providing that someone could help with testing it. So maybe @psajecki you could help with that if you have an easy way to switch back and run ros_control based interface ? Would that be possible?
And to explain a bit better - the control loop in LBTF is much more "tight" but it's in fact a "hybrid" solution. Fine interpolation is done in urscript, but coarse trajectory loop is done still over the network. The problem with the original implementation was that after some changes of the way the TCP/IP stack was implemented at UR, the unintended flaw of uncontrolled behaviour in case of network delays has amplfied. That was the main motivation for me to make the change - not only the control loop is tighter, but also by design, the LBTF will never loose control because of network delays (at expense of non-ideal/potentially delayed move timing).

I tested this work on our UR3 robot with Polyscope 3.4. It looks great. I didn't observe "catches-up" which are quite common on the robot with the default driver. Thank you!

@potiuk sorry for the delay in answering. I wanted to try some things on the real robot first, and haven't had a chance to until now. I can run your changes in ros_control mode, but I was having issues with ros_control before trying your work.

I never got vel_based_pos_traj_controller to work. I keep getting:

"[ WARN] [1518184110.886700187]: Controller /vel_based_pos_traj_controller failed with error code PATH_TOLERANCE_VIOLATED
[ WARN] [1518184110.886924487]: Controller handle /vel_based_pos_traj_controller reports status ABORTED
[ INFO] [1518184110.983198600]: ABORTED: Solution found but controller failed during execution
[ERROR] [1518184110.983278362]: Failed to move to first point"

After aborting the robot continues movement.
I tried increasing the allowed_execution_duration_scaling and allowed_goal_duration_margin but this did not seem to help. It works fine when not using ros_control, which I just determined this morning.
ros_control works for us with the pos_based_pos_traj_controller so that's what I was previously using.
2. When using ros_control, the base axis still randomly runs away on controller startup. It just happened again this morning, causing me to run for the e-stop. If I do not e-stop it, it will continue to spin until it tears apart the EOT wires.
I can try both the velocity and position based ROS controllers and tell you if there are any regressions, but since I never got the velocity based controller working under ros_control, I wouldn't be able to recognize regressions there unless your code somehow fixes the velocity controller for us. It could very well be a configuration problem on my part - it seems odd the position controller works and the velocity one does not though.

@psajecki - from my earlier analysis, it looks like velocity based ros_control is done entirely differently, but the position one uses the same trajectory follower that I used as a base for my implementation.
So the velocity based ros_control is not touched by the change. I will  make a small change asap to make it works for position one then - and I will let you know so that you can test it :).

@potiuk , sounds good.

@potiuk , I found a regression with your LBTF implementation. On slow and complex trajectory movements, moveit::planning_interface::MoveGroupInterface.execute(plan) returns before the robot is actually finished the move. If you try to send another movement after the previous call returns but before the robot movement actually finishes, the robot refuses to accept the new movement command and aborts with rejected communication. Disabling LBTF resolves this issue, as does increasing the velocity and acceleration. Could it be that the robot control loop is still going for a little while after the move has been reported as done to ROS?

@psajecki (and @Zagitta ) : I looked into the possibility of making the ros_control works with my changes, and I came to conclusion it's not going to be that easy as I thought. It looks like even the same Trajectory Follower is used for position based interface, completely different and unrelated method is used for it:
bool TrajectoryFollower::execute(std::array<double, 6> &positions, bool keep_alive) instead of bool TrajectoryFollower::execute(std::vector<TrajectoryPoint> &trajectory, std::atomic<bool> &interrupt). and the first one does not do any interpolation (there are no velocities), so it actually relies on providing the positions much more frequently. Since it is more complex than I thought, I don't think it's feasible (or needed) to enable LBTF for ros_control now (or even in the future). With this knowledge, I will try to make a small refactor in the way the followers are initialized though (responding to @Zagitta's code review) and propose something a bit cleaner (for the initialisation part). But then as result @psajecki  - there will be no need to test ros_control.

@psajecki  : for the regression - I think what actually happens is when there is some delay, the move executes a bit longer than originally planned. This makes MoveIT unhappy (it tries to cancel the Action when it takes longer than originally planned). Then it's lkely that the cancellation works only on a client side, but the URscript side for some time still continues. I will do some tests and will try to reproduce and remediate it. One of the options will be to relax MoveIt's checks on the actual timing of the move so that it does not try to cancel it even if it takes a bit longer (not sure if that's possible), another will be to not to allow to cancel the action. In any case we should handle the cancellation consistently. I will take a close look at that.

@potiuk I think you're right that it's not worth the effort to implement LBTF for ros_control. So once your small refactor of the init comes through I'll merge the code 😃

ros_control is a wholly different sort of approach to interacting with the robot.
I don't believe it's amenable to the approach implemented by @potiuk.

@Zagitta - it took a bit of time (I was distracted to do other parts of our system) but since we achieved another milestone I could come back and do this small refactor. It's now much nicer I think :).  I  only create the follower dynamically in "no-ros control" case and I named it ActionTrajectoryFollowerInterface as it is only used in Action. Makes much more sense now.

@psajecki  I think for the problem you have, you can try to mitigate the problem by using the trajectory execution launch configuration. It's in trajectory_execution.launch.xml in generated moveit config - and there are parameters that configure scaling and margin for allowed execution time among others. The relevant parameters are trajectory_execution/allowed_execution_duration_scaling (default 1.2) and trajectory_execution/allowed_goal_duration_margin (default 0.5). The first one is factor that scales execution time, the second is margin that is added on top of the scaled one. You can increase either of those values to make moveit executor more "tolerant" to execution delays.
There is also another parameter trajectory_execution/execution_duration_monitoring (you can set it to true/false). It is not mentioned in the generated configs but it seems to work. You can read about it here https://answers.ros.org/question/196586/how-do-i-disable-execution_duration_monitoring/
I think this is the "official" way of handling the problem you experience, because the root cause is indeed that moveit monitors the execution duration and LBTF by definition will not try to catch up in case of any delays, so increasing the tolerance of moveit executor seems to be a good idea. I will make a comment in README.md

@Zagitta -> I think It should all be ready to merge now (maybe if @psajecki confirms that the suggestion of increasing moveit tolerance works).

Thanks @potiuk. I'll be happy to try it out on Monday.

@potiuk I only had a very short time to be able to test Monday. It was enough to determine I had similar issues. My allowed_execution_duration_scaling was 1.3, and my allowed_goal_duration_margin was 2. I did not have a chance to try disabling execution_duration_monitoring. I hope to be able to test again Thursday in more depth.

Hey @Zagitta - any chances for merging (and merging your fork to the main repo afterwards?)

Yes, I was actually waiting for @psajecki's feedback but I suppose there's no harm in merging now.
Regarding the main fork it all depends on @ThomasTimm, I'm not entirely sure why he hasn't merged the changes yet and it's only gonna get more and more painful to merge it the longer he waits...

@Zagitta, @potiuk , I apologize for the delay. In general I have not been able to use the robot, but as it happens I had access today, and I tried your latest pull. Today I did not see the problems I had earlier. It was configured with allowed_execution_duration_scaling 1.3, and, allowed_goal_duration_margin of 1. Our program does more between movements now so it's possible there are additional delays that were not there in my initial testing. This will take more testing to determine. I do intend to be on the robot again on Monday.

@potiuk , @Zagitta , sorry my testing is a day late. The low bandwidth trajectory follower has not been working well for me today unfortunately. It seems to work when the speed is within a certain range, but too fast or too slow it will fail to work. The error I keep getting is this:
[ERROR] [1522161481.964797186]: Failed to accept incoming robot connection [ERROR] [1522161481.964823349]: Failed to start trajectory follower!
At 25% speed it seems fine.
At 50% speed it makes incorrect movements then errors out with the above.
at 0.06 - 0.10%  speed, it stops mid movement with the error above.
After this error, it attempts to do the next motion in the program and fails
(or possibly it attempts to do the next motion early because the move command terminates before the move is actually done and silently errors)
On Friday it was doing the slow movements (0.06-0.10%) fine. I'm not sure what changed today.
This may be my first time trying at 50% speed, so it's the first time I've seen this issue.
I've set the following parameters to make sure it's not related to motion timeouts:
trajectory_execution/allowed_execution_duration_scaling=1.5
trajectory_execution/allowed_goal_duration_margin" value=2
trajectory_execution/execution_duration_monitoring=false
With use_lowbandwidth_trajectory_follower set to false, everything works as expected.

@potiuk , @Zagitta , I've tested the new pull in ROS controller mode. It seems to work as well as before. The velocity based positional controller does not seem to work for me, but the positional based one works fine. May I suggest making the positional based control the default for ROS control? I'm hoping the runaway base axis moves on startup are related to the velocity controller, so if it defaults to the positional one, it will solve this potentially dangerous problem.
In my testing today I did not see the runaway base axis movement, but it does occur fairly infrequently so I may have just been lucky.

@psajecki -> Is it possible to get morecomplete logs when you run LBTF? Both from ros and maybe from the robot ? There is a URControl.log file when you login to the robot, I believei in Home directory of the root user. It looks like for some reason the connection back cannot be established from the robot, which could be because of urscript compilation problems (but it has not changed for months now :(. I'd really love to understand what's going on.

@potiuk , Can you please try writing a simple program that runs linear movements (i.e. use the eef_step parameter) between two points using 0.6%, 25%, and 50% velocity and acceleration scaling in a loop? Set velocity and acceleration scaling equal. Use an eef step of 0.01. I think it will be more time efficient for both of us if you can reproduce the issue on your robot, and I think this will do it.
Below is a code snippet of how we move the robot. You can see we are doing it in a form of an action server, so just replace goal->poses with hard-coded poses and remove setting the result in the error handling.
`
moveit::planning_interface::MoveGroupInterface move_group(move_group_name);
std::vector<geometry_msgs::Pose> waypoint_poses(goal->poses);

moveit_msgs::RobotTrajectory trajectory_msg;
double ratioCompleted = move_group.computeCartesianPath(
    waypoint_poses,
    eef_step,
    jump_threshold,
    trajectory_msg);

if (ratioCompleted != 1.0)
{
  result.status_code.val = moveit_msgs::MoveItErrorCodes::PLANNING_FAILED;
  goal_handle.setAborted(result);
  return;
}

robot_trajectory::RobotTrajectory trajectory (
    move_group.getCurrentState()->getRobotModel(),
    move_group.getName());

trajectory.setRobotTrajectoryMsg(
    *move_group.getCurrentState(),
    trajectory_msg);

trajectory_processing::IterativeParabolicTimeParameterization iptp;

bool success = iptp.computeTimeStamps(
    trajectory,
    max_velocity_scaling,
    max_acceleration_scaling);
if (!success)
{
  result.status_code.val = moveit_msgs::MoveItErrorCodes::PLANNING_FAILED;
  goal_handle.setAborted(result);
  return;
}
trajectory.getRobotTrajectoryMsg(trajectory_msg);
moveit::planning_interface::MoveGroupInterface::Plan plan;
plan.trajectory_ = trajectory_msg;
MoveItErrorCode error_code = move_group.execute(plan);

`

@psajecki  - I can try but not very soon -  this time I might be bottleneck, because we are entering pretty busy period in our project, so It can take quite some time until a) I get the hold of robot b) will find time to test it.

Hi all, first of all thanks @potiuk and others for the new driver. We use to control the universal robot ur3. We have done some tests and the behavior sometimes is good sometimes we have problems. Setup that we use is the following: we use 2 robots (KUKA and UR3) together with some other IoT devices like conveyor, Tablet, etc. We have a windows PC with VM-Ware server hosting the VMs (for controlling KUKA and UR3). That windows PC is connected over a gigabit router and then a switch to the real robot controllers from KUKA and UR3.
What we observed sometimes is that the connection between the ur driver and the real robot controller breaks. In particular, the connection on port 30003 for receiving the joint_states simply breaks down and no more joint_states updates come from the controller to the driver. It did not happen however on the port 30002, that still kept sending data. The connection on 30003 broke down when the ur3 is not in action and even did not get any command to execute. When I kill the ur driver and start it again the joint_states start to come again and the communication works fine. I have checked the .log file both on ros side and on the robot controller and i do not see any errors. I have also attached the files here. Could you please have a look?
Many thanks in advance.
log_history.txt
ros_network_problems_the_best_example_1.log

Hi all,
I have investigated the problem further and observed the following. If I stress the network, for example using the iperf tool, I observed that the ur_driver works fine at the beginning and some latency in the moves can be seen in the rviz which is expected since there is a packet loss in the communication and some of the robot joint_states get lost. After some time, the rviz representation does not move at all even if I move the robot using the pendant manually. I checked the joint_states topic and there is no published joint_states, it looks like it is frozen. I also run the wireshark with the filter: ip.src==robot_ip and tcp.port==30003, and no messages are displayed which means that there the communication on the port 30003 is lost. In the ros logs I do not see any errors, also not the messages showing that the producer or pipeline ended or any disconnection happened. I have attached the ros log  file. There are some more log messages that i introduced for the testing purposes. I have also deleted some of the messages because the file is too big.
rosout.log
Many thanks.
Regards, Dr. Srdjan Stevanetic

@SrdjanStevanetic wrote:

In the ros logs I do not see any errors, also not the messages showing that the producer or pipeline ended or any disconnection happened. I have attached the ros log file. There are some more log messages that i introduced for the testing purposes. I have also deleted some of the messages because the file is too big.

If you're 'stressing the network', I don't expect specific errors to pop-up in the ROS logs, unless the driver node is able to detect problems with the connection(s).
Most of the traffic will be between the driver node and the UR controller, and the way you describe your setup, I doubt there is much ROS traffic leaving the VM.
As to the problem of seemingly lost connections: not sure how to approach this. One experiment I can think of: try running nc ip.of.ur3.controller 30002 > /dev/null and nc ip.of.ur3.controller 30003 > /dev/null. Don't start any driver(s). Now repeat what you did with iperf and check with Wireshark. If that shows the same behaviour (ie: traffic stops), then the driver is not involved. If that keeps working, there would seem to be something in what the driver does to the TCP connection that makes it lose connection (or at least, makes the traffic come to a halt).
It would be good to also take a look at TCP window sizes: do you see those increasing or decreasing significantly for the connection to 30003?

@gavanderhoorn Thanks for the feedback. Yes there is much traffic outside of VMs, e.g. between the VMs and the robots, etc. I have run the analysis with nc tool as you proposed and observed the same problem. After some time the tcp connection to the robot freezes and there are no messages any more. It happened for both 30003 and 30002 ports but the 30003 port get frozen faster. Regarding the tcp window size I observed the window size of the connection to the port 30003 on the VM that communicates with the robot and saw that it remains the same, just for the time when the packets start coming periodically (because of the network stress the packets come all the time at the beginning, then there are some breaks and then at the end no more packets come) no window_size is captured. So the plot for the window_size is like a dashed line. I created it using Statistics -> TCP Stream Graph -> Window Scaling Graph in the wireshark.

We cannot unfortunatelly remove the VMs from our software, but I can try the test without the VM which I think is not the problem here. We have a high traffic volume (~10MBs = 80 Mbps) because we use the camera for scanning the scene.

Hm. Is that with the changes in this PR, or in the base fork by @Zagitta?

it's in this one, low bandwith trajectory follower

Regarding the previously mentioned connection problems when the network is heavily stressed I have implemented a solution using the select() function with timeout, that actually says when there is something to be read from the interfaces 30002 and 30003, then after that function the call to recv() is made as before. The read() function in the tcp_socket.cpp file looks now like this:
bool TCPSocket::read(uint8_t *buf, size_t buf_len, size_t &read)
{
read = 0;
if (state_ != SocketState::Connected)
return false;
struct timeval timeout;
fd_set rfds;
FD_ZERO(&rfds);
FD_SET(socket_fd_, &rfds);
timeout.tv_sec = 10;
timeout.tv_usec = 0;
int recVal = ::select(socket_fd_ + 1, &rfds, (fd_set *)0, (fd_set *)0, &timeout);
ssize_t res=-1;
switch(recVal)
{
case(0):
{
//Timeout expired
LOG_ERROR("TCPSocket select(): Timeout expired!");
return false;
break;
}
case(-1):
{
//Error
LOG_ERROR("TCPSocket select(): Error value returned!");
return false;
break;
}
default:
{
res = ::recv(socket_fd_, buf, buf_len, 0);
}
}
if (res == 0)
{
state_ = SocketState::Disconnected;
return false;
}
else if (res < 0)
{
LOG_ERROR("TCPSocket recv(): NOTHING received (response<0)!");
return false;
}
read = static_cast<size_t>(res);
return true;
}
To enable the driver to reconnect to the interfaces 30002 and 30003 I have also changed minimally the tryGet() function in the producer.h file which now looks like this:
bool tryGet(std::vector<unique_ptr>& products)
{
// 4KB should be enough to hold any packet received from UR
uint8_t buf[4096];
size_t read = 0;
// expoential backoff reconnects
while (true)
{
if (stream_.read(buf, sizeof(buf), read))
{
// reset sleep amount
timeout_ = std::chrono::seconds(1);
break;
}
  if (stream_.closed())
  {
    return false;
  }
  LOG_WARN("Failed to read from stream, reconnecting in %ld seconds...", timeout_.count());
  std::this_thread::sleep_for(timeout_);

  stream_.disconnect();

  if (stream_.connect())
    continue;

  auto next = timeout_ * 2;
  if (next <= std::chrono::seconds(120))
    timeout_ = next;
}

BinParser bp(buf, read);
return parser_.parse(bp, products);

}
Only the stream_.disconnect(); command is added. Now the driver reconnects automatically to the given interfaces when the network load decreases and continues its normal operation. Without the given changes the driver stays waiting forever in a blocking call of recv() in the TCPSocket::read(...) function and needs to be restarted in order to wok properly.

Regarding the sockets issue @simonschmeisser mentioned, we noticed that the socket was not closed properly. Instead of using shutdown() we should really close sockets, see this commit.
First tests using simple movements were successful without increasing number of socket descriptors. I am currently doing some further tests. Any concerns about using close() instead of shutdown() here?

As an update: as part of the repository maintenance activities that will be initiated next month (September), this PR will be merged into this fork of ur_modern_driver.
If anyone has any serious objections to this, now would be the time to make them heard.
We will not request additional changes from the submitter (@potiuk), so enhancements or small fixups will be done after the initial merge.

In the launchfile of ur3_bringup_joint_limited.launch the value of servoj_lookahead_time is currently set to 1. In the ScriptManual, the range is 0.03 to 0.2. Is setting this value to 1 a typo or does it disable lookahead when this parameter is out of range? With my tests (See table below) I had best results with the default parameters: 300 for servoj_gain and 0.1 for  servoj_lookahead_time ...
I've done some tests to compare lbtf and ros_control (velocity) against different values and different UR software version for goal pose precison. Test E gives the best results in term of goal precision which uses LBTF. I have tested other goal poses and it seems to always be precise (+- 300 micrometers). Some additional tests must be done but this new way of controlling the robot seems promising. I will test soon on a real robot.

Base (base_link)
Target
lbtf(A)
ros_control (B)
lbtf(C)
ros_control(D)
lbtf(E)

X (mm)
-400
-400.31
-399.844
-401.47
-399.864
-400.076

Y (mm)
0
-0.764
0.006
-3.1
0.006
-0.13

Z (mm)
5
4.972
4.56
6.25
4.564
4.812

RX (rad)
PI
3.14332
3.14238
3.1456
3.14238
3.14172

RY (rad)
0
0.00744
0.00166
0.0225
0.00156
0.00372

RZ (rad)
0
-0.0002
0.0014
-0.0072
0.00184
0.00054

Test A: LBTF (URSim <IP_ADDRESS>)
Test B: /vel_based_pos_traj_controller (URSim <IP_ADDRESS>)
Test C: LBTF (URSim <IP_ADDRESS>195)
Test D: /vel_based_pos_traj_controller (URSim <IP_ADDRESS>195)
Test E: LBTF (URSim <IP_ADDRESS>195) + max_joint_difference = 0.001
CLICK (Test case)
Starting pose for each test is the HOME (vertical) from URSim.
I added a tabletop and a mounting plate in the urdf.
The values in the cells are the mean of 5 tests and represents the data (acquired in URSim) from the Base point of view of the UR3. The PID have not been adjusted when testing ros_control.

ur3_bringup_joint_limited
Value

time_interval
0.008

servoj_time
0.008

servoj_time_waiting
0.001

max_waiting_time
2.0

servoj_gain
300

servoj_lookahead_time
0.1

max_joint_difference
0.01 (0.001)

MoveIt (C++)
Value

GoalPositionTolerance
0.00001

GoalOrientationTolerance
0.001

MaxVelocityScalingFactor
0.5

frame_id
base_link

x
0.4

y
0

z
0.005

r
M_PI_2

p
M_PI_2

y
0

ur3_controllers.yaml
P
I
D
I_Clamp
Trajectory
Goal

Shoulder_pan
30
0
0.1
1
0.1
0.1

Shoulder_lift
30
0
0.1
1
0.1
0.1

Elbow
30
0
0.1
1
0.1
0.1

Wrist_1
30
0
0.1
1
0.1
0.1

Wrist_2
30
0
0.1
1
0.1
0.1

Wrist_3
30
0
0.1
1
0.1
0.1

Many thx to all who contributed to this driver!!

Thanks @potiuk for all the work. :+1: :100: :fireworks:
Please don't understand the long time to merge as an underappreciation of your efforts.
Good luck with your company and perhaps talk to you later.

You're welcome. I no longer work with UR (moved back to more cloud and open-source Apache projects) but I am happy I could help with the driver :).


Make the 'else' part explicit in parse trees

Currently, it is rather cumbersome to detect the 'else' part of an 'if-else' construct in the parse tree because the 'else' part is flattened. This PR makes the parse tree more explicit by fields for the if-else-parts. This makes the grammar more robust and in line with other grammars like Java.

Thanks!


Offcanvas Backdrop Disappears On Wire:Click

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
I am a Laravel/Livewire developer and I use Bootstrap for many things, including modals and offcanvas. The issue is that when I have offcanvas on, and I make any interaction which involves Livewire, the backdrop is removed and the body becomes scrollable.
Let me say that this issue does not happen with modals at all. And I think it is because the way modals are designed is a bit different from offcanvas. For modals, the div (for example) structure looks like:
.modal > .modal-dialog > .modal-content (which contains modal-header, modal-body, modal-footer)
And if I am correct, the backdrop for modal is tied to modal-dialog.
However, for offCanvas, the structure is just .offcanvas which contains the header, body and footer.
Can the Bootstrap Team look into this and try to replicate offCanvas like modal?
Reduced test cases
nill
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome
What version of Bootstrap are you using?
v5.3.x

I fixed this by creating a custom CSS class .canvas-backdrop and tied it to both data-bs-toggle="offcanvas" and data-bs-dismiss="offcanvas".
CSS Code:
.canvas-backdrop {
	display: none;
	position: fixed;
	top: 0;
	left: 0;
	background-color: rgb(0, 0, 0);
	overflow: hidden;
	width: 100vw;
	height: 100vh;
	z-index: 1040;
}
.canvas-backdrop.show {
	display: block;
	opacity: .5;
}

jQuery code:
$('[data-bs-toggle="offcanvas"]').on('click', function() {
		$('.canvas-backdrop').toggleClass('show');
	});

	$('[data-bs-dismiss="offcanvas"]').on('click', function() {
		$('.canvas-backdrop').removeClass('show');
	});

And this solved the issue permanently.


Merge test_real_s3.rs and test_real_azure.rs

Having two files test_real_s3.rs and test_real_azure.rs creates a maintenance burden because changes need to be done to both. Ideally we'd only have one such file.
I would propose to:

use rstest instead of test_context for providing the fixtures
parametrize the tests using rstest's parametrization support to use both S3 and Azure
rename everything to use generic naming.

as a bonus, rstest also has a timeout functionality which we can attach to tests where this was a problem.

No ability to do async in rstest fixture teardown would be an adoption blocker: https://github.com/la10736/rstest/issues/94


[UI] Email address does unnecessary check after send forget email success.

SHOULD also refine the reset_password

close it as fixed.


guzzlehttp instead of guzzle

Hi!
guzzle for now is guzzlehttp, you have to update your composer requirements

I'm sorry but this library about to become abandoned, due to Meetup.com change in policy.


Update Sphinx theme

Summary
Updates to new Ecosystem theme. This is a draft PR to test the build first.
Total file size increased (5.45 MB -> 26.7 MB)
index.html size increased (15 KB → 252 KB)
Build time increased (93s → 958s)
For more information: https://github.com/Qiskit/qiskit_sphinx_theme/issues/232

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 86.74%

Totals

Change from base Build<PHONE_NUMBER>:
0.01%

Covered Lines:
8707

Relevant Lines:
10038

💛  - Coveralls

I do not see too big of an issue with the increase in file size.

Build time increased (93s → 958s)

But this build time increase is pretty rough. I see that the main change under the hood was to switch to a different theme. But have other changes been made to the Sphinx setup? From the top of my head I could see that the use of different class documentation templates with or without inherited members might not work. This will cause many dependencies to be pulled in (e.g. in the qiskit_nature.second_q.circuit.library classes) which has been a time-consuming process in the past, too.
Here are some potentially relevant PRs from the past:

https://github.com/qiskit-community/qiskit-nature/pull/229
https://github.com/qiskit-community/qiskit-nature/pull/1175

But this build time increase is pretty rough. I see that the main change under the hood was to switch to a different theme. But have other changes been made to the Sphinx setup?

Yeah, we know about it and Arnau will work on improvements. It's due to issues with Furo, the base theme we use. See https://github.com/Qiskit/qiskit_sphinx_theme/issues/328.

Thanks a lot @mrossinek, typo corrected!

Thanks @mrossinek! Should Arnau cherry-pick these changes to stable/0.6?
We're hoping to deploy the change soon because it's a priority to kill the old Pytorch theme with the Qiskit top nav bar (branding issue).

We can try backporting but I am honestly not sure about the state of the stable branch right now.
0.7 should be going out soon though, so if this is not required to be out before the end of October, waiting for up to 2 weeks is probably easiest for everyone.


Define YAMLSerializerField in its own file

Move the definition of YAMLSerializerField to a separate field file.

The new "fields" folder must have a init.py file otherwise it would not be considered a package, so it might not be included at build time.


Fix non-strict search in CompositeDisposable Fixes #107

Fixes #107

Coverage remained the same at 95.835% when pulling ba2ba75ccfd947647e05f18c6c3b527fbfba3902 on mbonneau:issue107 into 7c7d8584dc8d92337fdaedbe74c4ced5f95e9a69 on ReactiveX:master.

Coverage remained the same at 95.835% when pulling ba2ba75ccfd947647e05f18c6c3b527fbfba3902 on mbonneau:issue107 into 7c7d8584dc8d92337fdaedbe74c4ced5f95e9a69 on ReactiveX:master.


ProcessException: Process "D:\Workshop\FlutterExercise\app_clone\android\gradlew.bat" exited abnormally:

Steps to Reproduce

...After creating project on 'flutter run' I 'm getting error message 'Oops; flutter has exited unexpectedly.' I tried every possible sotution suggested on Github and Stackoverflow but none of them worked for me.
https://gist.github.com/ashuhitman/bd51dccd76feedd00327ab44090523ee.js

Logs

flutter run --verbose

## exception

ProcessException: ProcessException: Process "D:\Workshop\FlutterExercise\app_clone\android\gradlew.bat" exited abnormally:
Unzipping C:\Users\ashu8\.gradle\wrapper\dists\gradle-4.10.2-all\9fahxiiecdb76a5g3aw9oi8rv\gradle-4.10.2-all.zip to C:\Users\ashu8\.gradle\wrapper\dists\gradle-4.10.2-all\9fahxiiecdb76a5g3aw9oi8rv

Exception in thread "main" java.util.zip.ZipException: error in opening zip file
	at java.util.zip.ZipFile.open(Native Method)
	at java.util.zip.ZipFile.<init>(ZipFile.java:219)
	at java.util.zip.ZipFile.<init>(ZipFile.java:149)
	at java.util.zip.ZipFile.<init>(ZipFile.java:163)
	at org.gradle.wrapper.Install.unzip(Install.java:214)
	at org.gradle.wrapper.Install.access$600(Install.java:27)
	at org.gradle.wrapper.Install$1.call(Install.java:74)
	at org.gradle.wrapper.Install$1.call(Install.java:48)
	at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
	at org.gradle.wrapper.Install.createDist(Install.java:48)
	at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:128)
	at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
  Command: D:\Workshop\FlutterExercise\app_clone\android\gradlew.bat -v

flutter run --verbose
exception
ProcessException: ProcessException: Process "D:\Workshop\FlutterExercise\app_clone\android\gradlew.bat" exited abnormally:
Unzipping C:\Users\ashu8.gradle\wrapper\dists\gradle-4.10.2-all\9fahxiiecdb76a5g3aw9oi8rv\gradle-4.10.2-all.zip to C:\Users\ashu8.gradle\wrapper\dists\gradle-4.10.2-all\9fahxiiecdb76a5g3aw9oi8rv
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:219)
at java.util.zip.ZipFile.(ZipFile.java:149)
at java.util.zip.ZipFile.(ZipFile.java:163)
at org.gradle.wrapper.Install.unzip(Install.java:214)
at org.gradle.wrapper.Install.access$600(Install.java:27)
at org.gradle.wrapper.Install$1.call(Install.java:74)
at org.gradle.wrapper.Install$1.call(Install.java:48)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
at org.gradle.wrapper.Install.createDist(Install.java:48)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:128)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Command: D:\Workshop\FlutterExercise\app_clone\android\gradlew.bat -v
#0      runCheckedAsync (package:flutter_tools/src/base/process.dart:259:7)
<asynchronous suspension>
#1      _initializeGradle (package:flutter_tools/src/android/gradle.dart:225:9)
<asynchronous suspension>
#2      _ensureGradle (package:flutter_tools/src/android/gradle.dart:206:37)
<asynchronous suspension>
#3      _readGradleProject (package:flutter_tools/src/android/gradle.dart:134:31)
<asynchronous suspension>
#4      _gradleProject (package:flutter_tools/src/android/gradle.dart:111:34)
<asynchronous suspension>
#5      getGradleAppOut (package:flutter_tools/src/android/gradle.dart:105:29)
<asynchronous suspension>
#6      AndroidApk.fromAndroidProject (package:flutter_tools/src/application_package.dart:160:23)
<asynchronous suspension>
#7      ApplicationPackageFactory.getPackageForPlatform (package:flutter_tools/src/application_package.dart:47:32)
<asynchronous suspension>
#8      FlutterDevice.runHot (package:flutter_tools/src/resident_runner.dart:352:56)
<asynchronous suspension>
#9      HotRunner.run (package:flutter_tools/src/run_hot.dart:251:39)
<asynchronous suspension>
#10     RunCommand.runCommand (package:flutter_tools/src/commands/run.dart:469:37)
<asynchronous suspension>
#11     FlutterCommand.verifyThenRunCommand (package:flutter_tools/src/runner/flutter_command.dart:478:18)
<asynchronous suspension>
#12     FlutterCommand.run.<anonymous closure> (package:flutter_tools/src/runner/flutter_command.dart:383:33)
<asynchronous suspension>
#13     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29)
<asynchronous suspension>
#14     _rootRun (dart:async/zone.dart:1124:13)
#15     _CustomZone.run (dart:async/zone.dart:1021:19)
#16     _runZoned (dart:async/zone.dart:1516:10)
#17     runZoned (dart:async/zone.dart:1463:12)
#18     AppContext.run (package:flutter_tools/src/base/context.dart:152:18)
<asynchronous suspension>
#19     FlutterCommand.run (package:flutter_tools/src/runner/flutter_command.dart:375:20)
#20     CommandRunner.runCommand (package:args/command_runner.dart:197:27)
<asynchronous suspension>
#21     FlutterCommandRunner.runCommand.<anonymous closure> (package:flutter_tools/src/runner/flutter_command_runner.dart:396:21)
<asynchronous suspension>
#22     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29)
<asynchronous suspension>
#23     _rootRun (dart:async/zone.dart:1124:13)
#24     _CustomZone.run (dart:async/zone.dart:1021:19)
#25     _runZoned (dart:async/zone.dart:1516:10)
#26     runZoned (dart:async/zone.dart:1463:12)
#27     AppContext.run (package:flutter_tools/src/base/context.dart:152:18)
<asynchronous suspension>
#28     FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:356:19)
<asynchronous suspension>
#29     CommandRunner.run.<anonymous closure> (package:args/command_runner.dart:112:25)
#30     new Future.sync (dart:async/future.dart:224:31)
#31     CommandRunner.run (package:args/command_runner.dart:112:14)
#32     FlutterCommandRunner.run (package:flutter_tools/src/runner/flutter_command_runner.dart:242:18)
#33     run.<anonymous closure>.<anonymous closure> (package:flutter_tools/runner.dart:62:22)
<asynchronous suspension>
#34     _rootRun (dart:async/zone.dart:1124:13)
#35     _CustomZone.run (dart:async/zone.dart:1021:19)
#36     _runZoned (dart:async/zone.dart:1516:10)
#37     runZoned (dart:async/zone.dart:1500:12)
#38     run.<anonymous closure> (package:flutter_tools/runner.dart:60:18)
<asynchronous suspension>
#39     AppContext.run.<anonymous closure> (package:flutter_tools/src/base/context.dart:153:29)
<asynchronous suspension>
#40     _rootRun (dart:async/zone.dart:1124:13)
#41     _CustomZone.run (dart:async/zone.dart:1021:19)
#42     _runZoned (dart:async/zone.dart:1516:10)
#43     runZoned (dart:async/zone.dart:1463:12)
#44     AppContext.run (package:flutter_tools/src/base/context.dart:152:18)
<asynchronous suspension>
#45     runInContext (package:flutter_tools/src/context_runner.dart:56:24)
<asynchronous suspension>
#46     run (package:flutter_tools/runner.dart:51:10)
#47     main (package:flutter_tools/executable.dart:62:9)
<asynchronous suspension>
#48     main (file:///C:/b/s/w/ir/k/archive/flutter/packages/flutter_tools/bin/flutter_tools.dart:8:3)
#49     _startIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:299:32)
#50     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:172:12)

flutter doctor
[✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Microsoft Windows [Version
    10.0.18362.239], locale en-US)
    • Flutter version 1.7.8+hotfix.4 at C:\Users\ashu8\Desktop\flutter
    • Framework revision 20e59316b8 (2 weeks ago), 2019-07-18 20:04:33 -0700
    • Engine revision fee001c93f
    • Dart version 2.4.0

[!] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at C:\Users\ashu8\AppData\Local\Android\Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = C:\Users\ashu8\AppData\Local\Android\Sdk
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    ✗ Android licenses not accepted.  To resolve this, run: flutter doctor
      --android-licenses

[✓] Android Studio (version 3.4)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 38.1.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[✓] IntelliJ IDEA Community Edition (version 2018.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.2.1
    • Flutter plugin version 34.0.1
    • Dart plugin version 182.5215

[✓] VS Code, 64-bit edition (version 1.36.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.2.0

[✓] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.1.0 (API 27)
      (emulator)

! Doctor found issues in 1 category.

Analyzing app_clone...
No issues found! (ran in 40.8s)

 Flutter (Channel stable, v1.7.8+hotfix.4, on Microsoft Windows [Version
    10.0.18362.239], locale en-US)
    • Flutter version 1.7.8+hotfix.4 at C:\Users\ashu8\Desktop\flutter
    • Framework revision 20e59316b8 (2 weeks ago), 2019-07-18 20:04:33 -0700
    • Engine revision fee001c93f
    • Dart version 2.4.0

[√] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
    • Android SDK at C:\Users\ashu8\AppData\Local\Android\Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-28, build-tools 28.0.3
    • ANDROID_HOME = C:\Users\ashu8\AppData\Local\Android\Sdk
    • Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)
    • All Android licenses accepted.

[√] Android Studio (version 3.4)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin version 38.1.1
    • Dart plugin version 183.6270
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1343-b01)

[√] IntelliJ IDEA Community Edition (version 2018.2)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.2.1
    • Flutter plugin version 34.0.1
    • Dart plugin version 182.5215

[√] VS Code, 64-bit edition (version 1.36.1)
    • VS Code at C:\Program Files\Microsoft VS Code
    • Flutter extension version 3.2.0

[√] Connected device (1 available)
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.1.0 (API 27)
      (emulator)

Duplicate of https://github.com/flutter/flutter/issues/36282


ENH: Allow QAP to accept adjacency matrices of different sizes

Reference issue

What does this implement/fix?

This PR implements "padding" to the quadratic_assignment() function in scipy.optimize, allowing users to input matrices A and B of different sizes. Two different padding schemes are implemented here, and the user is given the option to choose between the two. adopted (default) padding matches the appropriate induced subgraphs, and naive matches the appropriate subgraphs. More information can be found in section 2.5 of "Seeded Graph Matching"
Additional information

@mdhaber please take a look when you have a chance!

@mdhaber let us know if you need anything else from else prior to reviewing this, thanks!

@jovo Thanks for your patience. It would help if we could improve the testing.

Can you explain how the existing test works?  As I'm not very familiar with all this, it doesn't jump out to me what the assertion is after and how strong of a test that is (e.g. how wrong the code could be and still pass the test). Also, why is an "Erdos-Renyi graph" used?
Can the existing test be adapted so that more than one node is removed? Perhaps it doesn't matter at all, but without thinking carefully about what is going on, one might assume that a test where the inputs are nearly the same size is "easier" to pass than one in which the inputs are very different sizes.
The existing test is only on col_ind . Is there some sort of test you can perform on the resulting objective function value (even if it's just a bound of some sort)? I know that may be difficult.
Would it be possible to add a test in which you pass in a matrix that has been manually padded in a way that is obviously correct and, e.g., confirm that you get the same result as if you let quadratic_assignment do the padding?
Ideally, can you add a test that validates against a published result or code? I know that's not always possible. If not, can you construct an example in which the optimal solution is obvious and check the result?
Especially if we can't do 3-5, let's add a few tests that check the result of _adj_pad. I'm sure we can check that against an expected result.
The current test only checks the case in which the second input needs to be padded. Can we add a test in which the first input needs to be padded? (It's ok if it's essentially the same but the inputs are swapped.)

The logic looks right; I'm just trying to think of ways we can confirm that this will do the right thing.

@mdhaber no worries, I understand the (often thankless) difficulties of maintaining high quality packages.  I'll talk to @asaadeldin11 and we'll address all those concerns right away, thanks!

Thanks for the feedback!

First, some questions:

Can you explain how the existing test works?  As I'm not very familiar with all this, it doesn't jump out to me what the assertion is after and how strong of a test that is (e.g. how wrong the code could be and still pass the test).

This is a relatively weak test, it was basically just a sanity check to make sure nothing was broken. I agree that we need stronger tests, please see my suggestions below.

Also, why is an "Erdos-Renyi graph" used?

No particular reason, just that it is a simple graph model. The main strength of this padding is to find subgraphs in a larger graph, so it's applications are mainly in the graph matching side of things, though it does also work with the QAP

I haven't looked carefully - does the padding work correctly with all of the existing options (e.g. partial_match and P0)?

P0 now must be the size of the larger graph (among A and B) so I will add that to the docs. For partial_match, I will clarify in the type check that the indices must be within the sizes of original input graphs pre-padding (all entries of seedsA must less than len(A), as with B). Other than that these options work as intended.

Can the existing test be adapted so that more than one node is removed? Perhaps it doesn't matter at all, but without thinking carefully about what is going on, one might assume that a test where the inputs are nearly the same size is "easier" to pass than one in which the inputs are very different sizes.

Sure. I can generate three 25 x 25 ER graphs of different probabilities (say 0.6, 0.1, 0.2), and construct A as the block graph [[0.6, 0.1],[0.1, 0.2]] and B as just 0.6, so A is 50 x 50 and B is 25 x 25. Then i would expect the nodes from 1-25 to map to each other from A to B.

The existing test is only on col_ind . Is there some sort of test you can perform on the resulting objective function value (even if it's just a bound of some sort)? I know that may be difficult.

Yes, for the above test I can make sure that the objective function value is between 0 and 25^2 as well

Would it be possible to add a test in which you pass in a matrix that has been manually padded in a way that is obviously correct and, e.g., confirm that you get the same result as if you let quadratic_assignment do the padding?

sure. I can make small graphs of different sizes and manually pad one, then just make sure they get the same objective function value, if you think that's sufficient?

Ideally, can you add a test that validates against a published result or code? I know that's not always possible. If not, can you construct an example in which the optimal solution is obvious and check the result?

Since the padding section of the SGM paper is pretty short, the only result they show is essentially figure 3, which I recreated here. This is more of a structural/visual result, so I'm not sure if it would be appropriate to put it in the tests.

Especially if we can't do 3-5, let's add a few tests that check the result of _adj_pad. I'm sure we can check that against an expected result.
The current test only checks the case in which the second input needs to be padded. Can we add a test in which the first input needs to be padded? (It's ok if it's essentially the same but the inputs are swapped.)
Please consider the ideas above for both naive and adopted. We need to test both.

Sounds good on the above three.

The logic looks right; I'm just trying to think of ways we can confirm that this will do the right thing.

@mdhaber Let me know if have comments on my above suggestions, thanks!

Thanks for the responses. Yeah, I think all that would help. Only comment is about:

objective function value is between 0 and 25^2 as well

Sure. I suppose I was hoping for something a little stronger. Isn't this algorithm supposed to get within twice the optimal objective function value or something? Maybe that's only for the graphs being the same size?

Sure. I suppose I was hoping for something a little stronger. Isn't this algorithm supposed to get within twice the optimal objective function value or something? Maybe that's only for the graphs being the same size?

The actual objective function range in the tests will be much more narrow than this, I just wasn't exactly sure what those values would be off the top of my head. I just meant that the range would be between 0 and 25^2 since those are the absolute bounds (in the tests it will likely be something like 250-350 to be more exact)

I know. I just wonder whether you can provide a bound from theory that is tighter than the (what I called trivial) absolute bound.

@asaadeldin11 @jovo Were you still interested in this? I may be able to help finish it up now if the new tests are stronger.
On the other hand, we haven't received any bug reports, enhancement requests, or attention from other maintainers for QAP, so I'm not sure how much the enhancement would be used. We could consider keeping this on the backburner until there is more interest.

@bdpedigo what do you think? you are in charge of this now :)


[WFLY-15115] Upgrade WildFly Core 17.0.0.Beta5

JIRA: https://issues.redhat.com/browse/WFLY-15115
Signed-off-by: Jeff Mesnil<EMAIL_ADDRESS>
Dev tag: https://github.com/wildfly/wildfly-core/releases/tag/17.0.0.Beta5
Diff to previous integrated release: https://github.com/wildfly/wildfly-core/compare/17.0.0.Beta4...17.0.0.Beta5

Release Notes - WildFly Core - Version 17.0.0.Beta5
        Feature Request

[WFCORE-5464] -         Add environment variables as a source for model expression resolution

        Bug

[WFCORE-4035] -         operation-requires-reload message is missing

[WFCORE-5406] -         For JDK 16+ server requires --add-opens to allow reflective access to JDK classes

[WFCORE-5521] -         Close resource - potential resource leak

[WFCORE-5524] -         *ConfigurationChangesHistoryTestCase fails on Windows

[WFCORE-5536] -         list-snapshots() doesn't include snapshot file with a custom name

[WFCORE-5540] -         Patch file entries should be validated before being used

[WFCORE-5545] -         CompositeIndexProcessor does not make Jandex indices built via static module class scanning available to WarAnnotationDeploymentProcessor

[WFCORE-5546] -         "JAVA_OPTS" is not correctly set in standalone.bat

[WFCORE-5556] -         Add back setAllowNull, required by Keycloak SAML adapter

[WFCORE-5558] -         Wildlfy app not starting: cause: ApplicationRealm is not getting intailized throwing : FIPS mode: only SunJSSE TrustManagers may be used

[WFCORE-5566] -         Fix FIPS detection so that it also works with Java 17

[WFCORE-5568] -         Clean up after JandexIndexCachingTestCase

        Task

[WFCORE-5502] -         Fix deprecated constructors

[WFCORE-5547] -         DistributableWebDeploymentProcessor should run before ModuleSpecProcessor

[WFCORE-5550] -         Deprecate ModelTestControllerVersion-s older than EAP_7_4_0

[WFCORE-5552] -         Manage the -jakartaee9 artifacts from undertow

        Component Upgrade

[WFCORE-5534] -         Update wildfly-galleon-plugin to 5.2.2.Beta2

[WFCORE-5535] -         Upgrade to JBoss Invocation 1.6.3.Final

[WFCORE-5541] -         Upgrade Undertow to 2.2.10.Final

[WFCORE-5562] -         Upgrade JBoss DMR 1.6.1.Final

[WFCORE-5565] -         Upgrade slf4j 1.7.32

        Enhancement

[WFCORE-5543] -         Operation-scoped caching of static module Jandex indices

[WFCORE-5570] -         Add a profile to disable compilation to facilitate testing with a different JDKs

WF Preview tests:
https://ci.wildfly.org/viewLog.html?buildId=270317&tab=buildResultsDiv&buildTypeId=WF_WildFlyPreviewLinuxJdk17
https://ci.wildfly.org/viewLog.html?buildId=270313&tab=buildResultsDiv&buildTypeId=WF_MainElytronJdk17_2

@kabir Once that PR is merged, #14376  can also be merged


tar_resources_aws or tar_resources seem to require a region name.

I originally got this error.
r$> targets::tar_make()
Error in get_region(cfgs$credentials$profile) : No region provided
✖ Problem with the pipeline.
ℹ Show errors: tar_meta(fields = error, complete_only = TRUE)
ℹ Learn more: https://books.ropensci.org/targets/debugging.html
Error:
! problem with the pipeline.

After adding a random region here (AWS_REGION="us-east-1"), the error has gone.
https://github.com/noamross/targets-minio-versioning/blob/8c2dde713ba1e7d4b7b73c7174b8b4527418fead/_targets.R#L7-L10
r$> targets::tar_make()
• start target data
• built target data
• start target model
• built target model
• end pipeline: 0.213 seconds

Sorry for the confusion. I tried it again and it's actually skipped building.
 r$> targets::tar_make()
✔ skip target data
✔ skip target model
✔ skip pipeline: 0.153 seconds

I can also access to a new bucket (different name) in the min.io server but I still need to specify AWS_REGION. I copied the minio version. The R environment is as in renv.lock. Someone may experience the same problem, so I just wanted to share. Thank you for the great tutorial!
> minio --version
minio version RELEASE.2022-07-17T15-43-14Z (commit-id=b6eb8dff649b0f46c12d24e89aa11254fb0132fa)
Runtime: go1.18.4 darwin/arm64
License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
Copyright: 2015-0000 MinIO, Inc.

Hi there,
I ran into the same problem. Without an AWS_REGION set it fails. I get:

targets::tar_make()
Error in get_region(cfgs$credentials$profile) : No region provided
x Problem with the pipeline.
i Show errors: tar_meta(fields = error, complete_only = TRUE)
i Learn more: https://books.ropensci.org/targets/debugging.html
Error:
! problem with the pipeline.
Called from: signal_abort(cnd, .file)

If I set it, for example as suggested above to AWS_REGION="us-east-1" it works fine. And it skips making the targets and finds them in minio. I can see it access the bucket when I Watch the bucket in the minio console.
Note when grepping for region we do find it in the meta file as region=NULL and setting AWS_REGION="NULL" works as well. It seems that paws::get_region(..) requires a region or will stop. It's unclear what the region is used for, but maybe it's adds it to the meta file when properly set?
Note: I used renv::restore(..) to get the project dependencies as documented - but I had to upgrade two packages (cpp11  [0.4.6], igraph [1.5.1]) to succeed on this. I'm on R 4.1 not 4.2 and on Windows.
Thanks for finding the workaround @mattocci27  btw!

I realized that even though I don't have AWS_REGION set, I do have a region set in my .aws/credentials file.  Since targets uses the paws package for AWS/S3 interaction, and that is AWS-specific, my guess is that the paws specification is looking for region even though non-AWS services may not need it.


Feat: add bar chart for top 10 countries

@Anupriya-Sri could you add a screenshot of what it looks like to this PR please?


Fixes Deprecated Strategy

Changed
Rollup has a limitation (https://github.com/rollup/rollup/issues/1693) where namespace exports are frozen using Object.freeze. This PR works around this to allow changing PIXI namespaces (e.g. PIXI.utils)
Also, this PR resolves the proper way to inject deprecations into the build file as well as is overall a better strategy for deprecated method on the bundle only.

+380 −280
I dont like the balance. Are you sure? Please count how many times you export/import the same thing here, just for us to know how many times we need to change something if we change the class name or add a new one.

Like, user with notepad needs to add X lines of code per new object in some of inner modules. At the same time, user with IDE has special operations.. ok, i dont think IDE's will help us even in renaming this.
We need clear instructions. If Object.freeze is the only thing that adds 100 more lines, then lets remove it or make it only in the bundle after all things are ready to be frozen.

I have a pull-request into Rollup (https://github.com/rollup/rollup/pull/1696) to allow opt-out of Object.freeze. Who knows when that'll happen.
I don't like importing and export all things explicitly. But right now we have no way to add proper deprecations. For instance Object.defineProperty(PIXI.utils, 'whatever') will not work. This throws Cannot define property baz, object is not extensible.
I've been grinding on this issue for awhile without a good option. I don't want to fork Rollup to accomplish what I want. Any other ideas?

Fork it or remove deprecations for some time. I dont think incremental deprecations is a good thing here, we are changing lots of API's, its better to look at the result and then add necessary deprs.

Also, you dont have to fork rollup, just use "bigtimebuddy:master" in package.json for now

Couldn't deprecations be it's own package? And then within the src folders are a way for us to fine tune version deprecations.
For example, when v5 is released, there is a 'v4 -> v5.0' folder.
But if v5.1 is released with deprectations, there is a new 'v5.0 -> v5.1' folder.
Maybe for developer builds this is bundled in automatically, but for release builds not?

I had thought about the deprecations being another package like you suggested @themoonrat. I think there’s something user friendly about it just working. Particularly the pixi.js bundle. Some JS projects also build a compatibility mode which is designed to be more backward compatible. I want to try to find the right balance. Including another package seems a little annoying, but I’m not convinced either way.

That is what used for our examples: https://github.com/ivanpopelyshev/pixi-legacy . It works with v3->v4 and back.
Anyway, temporary roolup fork in our case is a right move.

Okay, I'm going to close and try again with a less intense workaround.


Add SQL schema

Create SQL DDL for ISARIC schema

Will be using FHIR database as storage, if existing FHIR server does not work, will re-evaluate


On-Premise Sentry and On-Premise HipChat integration error

I'm getting the following error when running the Install an integration from a descriptor URL within our HipChat instance.  The error returned indicates Failed to validate field 'action' list schema: "Field 'url' is required by field 'target'".  Is this something that HipChat is expecting for integration?

That's interesting. I will have a look at this. I wonder if Atlassian changed something.


Not able to edit font-style or font-weight in Roulette

Currently it is possible to change font-size and font-family in Roulette. However, it is not true for font-style and font-weight. It's something that is nice to have.

@somewonderfulguy we added fontWeigth and fontStyle options (as global props or individual options) in version 1.4.1, hope it helps!


Scale virt-launcher to pick up config changes during tests

What this PR does / why we need it:

The config changes are only half picked-up because the functests only scale virt-api and virt-controller. virt-handler needs to be scaled too.
Don't deploy the test-infra via the test-binary. The test-infra is also needed during development. The test-binary deploys it for the usual development-flow too late and also does not keep the test-infra.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Alternative solution to #1869.
Special notes for your reviewer:
Release note:

NONE

@lukas-bednar @slintes had to update it again. See the updated commit message. I think we need to still deploy the test-infra in our scripts, because we also want the test infra to be available during development.

ci test please

Seems like some lanes had temporary connectivity issues:
local-volume-provisioner-slrxd   0/1       ImagePullBackOff   0         24m

For reference:
http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/2984/artifact/ci_build_summary.html

ci test please