controller

few questions:
can i connect to the switch any controllers and nxbt recognize them?
can i use ps4 or xbox 360 wireless controller?
does it works only with bluetooth or with usb too?
can i connect more then one controller?

To answer your questions:

NXBT recognizes and enables use of an arbitrary controller through the web interface by using the JavaScript Gamepad API. So a typical workflow would be: Install NXBT with pip on the device that will sit near the Switch, start the webapp (sudo nxbt webapp), navigate to the browser page on the device or on another device on the same network, ensure that you've got a controller connected to the device with the browser tab open, use the controller on the Switch.
Any controller that works with the Gamepad API will work with NXBT's webapp. If you want to test compatibility, this site works well for that.
If you're asking about NXBT itself, unfortunately, emulating a controller over Bluetooth is the only format supported. If you're asking about which controllers are supported for use through NXBT, the answer is that most will work (Bluetooth or USB). Again, check the site above in your browser for compatibility. If it's detected on there then it will work with NXBT.
You can connect as many controllers as you have Bluetooth adapters. This means that a single Raspberry Pi out-of-the-box, for instance, will only support emulation of one controller. You can, however, plug in more Bluetooth USB adapters (almost any cheap adapter off of Amazon will work) and more controllers will work. NXBT will take advantage of new USB Bluetooth adapters in real-time.

Hopefully this answers your questions. If not, let me know!

Closing issue due to lack of activity


[Bug] Select2_multiple with no pivot

Bug report
I'm trying to define a multiple select on a form. I'm using Laravel 8.x, Backpack 4.1, on a mongo database.
I can visualize the multiple choice just fine, but I cannot seem to be able to save it on the db. I'm trying to save the field as a json array. This situation is totally undocumented and it's hard to understand what I should do. mutate to array or string don't work either way. With no mutators, it just doesn't save anything and gives no error.
What I did
   // warranty model
    public function product()
    {
        return $this->belongsTo(Product::class);
    }

   // product model
    public function warranties()
    {
        return $this->hasMany(Warranty::class);
    }

    protected $casts = [
      ...
      'warranties' => 'array'
    ];

        CRUD::addField([
            'label'     => "Warranty",
            'type'      => 'select2_multiple',
            'name'      => 'warranties', // the method that defines the relationship in your Model

            // optional
            'entity'    => 'warranties', // the method that defines the relationship in your Model
            'model'     => Warranty::class, // foreign key model
            'attribute' => 'code', // foreign key attribute that is shown to user
            'pivot'     => false
        ]);

What I expected to happen
It should save the array a string in mongodb (as it does for select_from_array or selects)
What happened
I get:

json_decode() expects parameter 1 to be string, array given

What I've already tried to fix it
??
Backpack, Laravel, PHP, DB version
### PHP VERSION:
PHP 7.4.15 (cli) (built: Feb 27 2021 18:23:50) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.15, Copyright (c), by Zend Technologies

### LARAVEL VERSION:
v8.32.1@7c37b64f8153c16b6406f5c28cf37828ebbe8846

### BACKPACK VERSION:
4.1.38@90cf9d0613848144c1e5f3822892bf2a7afa860f

Hello @MeerKatDev did you tried with pivot => true ?

@pxpm I didn't, but in fact I don't want to use a pivot table, I don't need it. I need an array there.

@MeerKatDev pivot is just an way of how under the hood the relation is handled. Can you setup 'pivot => true' ? I have other hasMany working with pivot => true, so I think it might be some documentation issue. (the part that hasMany technically does not have a pivot table is beeing addressed in other PR)

I get this when adding pivot => true:

Call to undefined method Jenssegers\Mongodb\Relations\HasMany::sync()

After all I created a new component.


How to CA Certificates for when downloading adapters?

Currently Unable to download Any adapters as I'm getting self-signed certificate error due to my Netskope client (MITM) on my work machine. It doesn't seem like this debugger uses the custom user CA bundle as I'm supplying the bundle with the private CA roots.
Is there a way to configure this package to use/honor the sublime user ca bundle? Or is there a way to toggle ssl verification for the adapters download?
Thank you!

No there is not and looking at package control it doesn't seem that trivial to support what you are asking. If you or someone else wants to support self-signed certificates like package control you can open a pull request for it. The logic for performing network requests is here https://github.com/daveleroy/SublimeDebugger/blob/master/modules/adapters/util/request.py.
Disabling ssl verification isn't something I am willing to expose in a setting but you are free to modify the implementation yourself.


No resolvers on the list

It is already 2 days and there is no resolver listed
already reinstall SimpleDnsCrypt but still no resolver
screenshot here

Got the same problem. I noticed it just crashes when i try to start the service

Replace fallback_resolver = '<IP_ADDRESS>:53' with fallback_resolver = '<IP_ADDRESS>:53' in the configuration file.

which config is that? I've look at SimpleDnsCrypt.exe.config but there is no option for fallback_resolver

In the .toml

thanks for the help


rbac: add DNS SAN as principal

Description: Adds support for DNS SAN as Principal in RBAC filter.
Risk Level: Low
Testing: Added automated tests
Docs Changes: Updated
Release Notes: Added
Fixes #7836

@lizan @mattklein123 PTAL

@lizan can you PTAL when you get chance?

Can you merge master?

@lizan merged master. PTAL

@htuch turns out this PR needs your approval


Hello Moe Poi,can I ask you for something

I like the style of your previous personal website very much. Could you please tell me the source? Thank you very much

i wanna know to


⚠ Fortnite has degraded performance

In db35c84, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1591 ms

Resolved: Fortnite performance has improved in 04bd817.


Review initial convergence measurement models

Need to review and provide feedback regarding the initial structure and content of the convergence measurement models.
https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/open-traffic-generator/models-convergence/main/artifacts/openapi.yaml

Looked at it, didn't fully understand the egress and ingress portion of get_convergence.  Will the convergence statistics be returned in those containers?

The flow_names along with none or one of the ingress / egress containers specify the set of keys for each returned object.
There will then be one convergence measurement object for each combination of flow name + (ingress item | egress item).

I have little confusion related to the response of get_convergence (events). It looks like events section is used to configure an events. I am expecting it will return type of events.

@alakendu the get_convergence response has been updated to reflect the correct event component schema.


Verify that everything came out of Preservica correctly

Required for https://github.com/wellcomecollection/platform/projects/9
We need to verify that every file in Preservica is either:

Migrated successfully to the storage service; or
Safe to delete (Preservica holds every copy of every file it’s ever seen, even if files are replaced – we’d only have migrated the newest versions)

We probably can't do this unless we can connect to the Preservica database (wt-dhaka) from inside the Wellcome building. My home connection is too flaky (and slow) to be usable for this work.
I've attached some code which walks the list of files in Preservica and extracts:

The filename
The collection and deliverable unit names (which give a clue as to which bag the file will be in)
The file size and SHA-1 checksum (yes, really)

The checksums in particular pose a problem: Preservica has SHA-1, the storage service has SHA-256. Once we've extracted the data we need from the Preservica DB, we should walk the file list and check whether:

A file with that name exists in the storage service
The file has the correct size
Read the file out of Preservica, verifying the SHA-1 and SHA-256 checksums match what we'd expect

Stragglers get flagged for manual inspection/intervention.
If there's a way to do it, we could delete files as we go along, so Preservica will only contain what’s “interesting”.
This is going to involve reading ~40TB of data from various places, so we'll need to coordinate it carefully so as not to rack up a massive bill (for S3 egress costs or my home broadband!).

get_files_from_preservica.py
#!/usr/bin/env python

import contextlib
import json
from pprint import pprint

import tqdm

@contextlib.contextmanager
def preservica_cursor():
    cnxn = pyodbc.connect(
        driver="{ODBC Driver 17 for SQL Server}",
        server="wt-dhaka",
        database="WELLCOME_SDB4",
        trusted_connection="yes",
        readonly=True
    )
    yield cnxn.cursor()
    cnxn.close()

def get_fixity_algorithms():
    with preservica_cursor() as cursor:
        cursor.execute("SELECT * FROM FixityAlgorithm")
        return dict(cursor.fetchall())

FIXITY_ALGORITHMS = get_fixity_algorithms()

def get_collections(digital_file):
    """
    Returns the collection code/titles for this file reference.
    """
    collection_names = set()

    with preservica_cursor() as cursor:
        cursor.execute(
            """
            SELECT CollectionCode, Title
            FROM Collection
            WHERE CollectionRef in (
                SELECT CollectionRef
                FROM Accumulation
                WHERE AccumulationRef in (
                    SELECT AccumulationRef
                    FROM Accession
                    WHERE AccessionRef in (
                        SELECT AccessionRef
                        FROM IngestedFileSet
                        WHERE IngestedFileSetRef=?
                    )
                )
            )
            """,
            (digital_file["IngestedFileSetRef"],)
        )

        for collection in cursor.fetchall():
            for name in collection:
                collection_names.add(name)

    return collection_names

def get_deliverable_unit_ref(digital_file):
    with preservica_cursor() as cursor:
        cursor.execute(
            """
            SELECT CatalogueReference
            FROM DeliverableUnit
            WHERE DeliverableUnitRef in (
                SELECT DeliverableUnitRef
                FROM DeliverableUnitManifestation
                WHERE ManifestationRef in (
                    SELECT ManifestationRef
                    FROM ManifestationFile
                    WHERE FileRef=?
                )
            )
            """,
            (digital_file["FileRef"])
        )

        return {row[0] for row in cursor.fetchall()}

def get_checksums(file_ref):
    with preservica_cursor() as cursor:
        cursor.execute(
            """
            SELECT FixityAlgorithmRef, FixityValue
            FROM DigitalFileFixityInfo
            WHERE FileRef=?
            """,
            (file_ref,)
        )

        result = {}
        for algorithm_ref, value in cursor.fetchall():
            result[FIXITY_ALGORITHMS[algorithm_ref]] = value

        return result

def get_digital_files():
    with preservica_cursor() as cursor:
        cursor.execute(
            """
            SELECT FileRef, Name, IngestedFileSetRef, FileSize
            FROM DigitalFile
            """
        )

        fieldnames = [desc[0] for desc in cursor.description]

        file_data = cursor.fetchone()

        while file_data is not None:
            result = dict(zip(fieldnames, file_data))
            yield result
            file_data = cursor.fetchone()

if __name__ == "__main__":
    for digital_file in tqdm.tqdm(get_digital_files()):
        print(digital_file)
        print(get_collections(digital_file))
        print(get_deliverable_unit_ref(digital_file))
        print(get_checksums(digital_file["DigitalFileRef"])
        break

A bit more research, now I can actually get the tables out! This is the structure of the "interesting" tables:

Green = “has something interesting, like a filename, file size, checksum or catalogue reference”
Yellow = “internal DB we have to join over”
So the plan is:

For each of the 41M files, use these database connections to get:

the original filename (from DigitalFile)
the file size (from DigitalFile)
the SHA-1 checksum (from DigitalFileFixityInfo)
some catalogue references (from DeliverableUnit and Collection)

Now go through every file, and use the catalogue references to guess which bag the file is likely to be in. Look for files with a matching filename and size (born-digital might make this trickier, because Archivematica has “sanitised” all the filenames), compare the SHA-1 checksums.
If they match: great! We can tick off this file.
If they don't match: boo! This file needs more inspection.

There are 41,990,996 files in Preservica.
As of 31 March, I’ve verified or reviewed 41,670,0302 files. 320,694 files remain.
Method:

If a file in Preservica has a matching file in the storage service, then it’s verified. (Based on filename, size, SHA-1 checksum.)

When we did the digitised content migration, there were a number of b-numbers in Preservica that were now deleted (search for the “unbagged errors” spreadsheet in Slack). Any files in these b number have been marked as “not for migration”.
I’ve asked Ashley/DST to review another 150 b-numbers which have files in Preservica but not in the storage service.

(Today) If there are two files in Preservica with the same filename and b-number, and the newer version of the file has been successfully ingested, then I'll mark the old file as “not for migration”.


Fix: Do not disconnect before update

Motivation
InfiniteScroll didn't trigger intersection always.
Changes

Do not disconnect observer before update.

@peterpeterparker please review
Was the reason to disconnect before update only to avoid a layout shift? I found a bug on mainnet that it's not requesting the voting history in the neuron details page.
I was able to replicate it by:

Refresh in a neuron detail page
Scroll down to the voting history
The voting history is updated correctly with infinite scroll
Go back to neurons page.
Click on the same neuron as before.
Scroll down to the voting history.
The voting history is not updated with the infinite scroll.

As described in code

We disconnect previous observer before any update. We do want to trigger an intersection in case of layout shifting.

i.e. we do not want to trigger unnecessary query and update on proposal list views.

The problem was that the observer somehow didn't connect again then...
I'll keep playing, but have you replicated the issue in mainnet?

Not yet, I'll have a look tomorrow or next week

ok, no worries.

@lmuntaner thanks for the reproduction details, very useful 👍
I found the root cause of the issue and implemented a workaround so that it preserves the existing feature which is useful for the "Proposal list" view 👉 https://github.com/dfinity/gix-components/pull/142
Therefore I close this PR but for sure reopen it if I am missing something.

@peterpeterparker thank you, that's perfect!


Support required in struct tag

Is your feature request related to a problem? Please describe.
I know how to specify a param as required, but didn't find how to mark a custom struct field as required.
Describe the solution you'd like
Maybe like this: https://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-5.4.3 ? We need to add sth like required: true such struct tag to mark the struct field is required.
Describe alternatives you've considered
Additional context

type Example struct {
      Name string `validate: "required"`
}

Thanks! I don't see any document about this, so there is confusion.


Rule Hashing Duplicates plyara Function

Looking at the differences between generate_logic_hash from plyara.utils and calculate_rule_hash from the CCCS-Yara validator_functions, I can't see a significant benefit from duplicating the capability.
Is there an issue with the plyara function that hasn't been raised there?

The calculate_rule_hash had been originally created as an adaptation of the Florian Roth algorithm as noted in the code. When I found out about the generate_logic_hash and performed some testing there appeared be a few cases where the calculate_rule_hash generated the same hash but generate_logic_hash did not.
Unfortunately all of that testing was done on a machine I do not have access to at the moment. In attempting to recreate that testing from memory I have only found one use case where there is a difference. I will be discussing it with my team this week but I suspect there is not significant benefit as you noted.

I am working with the plyara team to use SLY instead of PLY. In the draft, the hashing is a method in the rule object.


rhash is following symlinked directories even if the --follow option is not specified

Reproduce by running the following in the top-level directory of the rhash sources
% ln -s /etc docs/etc
% rhash -r docs
Observe that rhash is trying to hash all of the etc directory, even though --follow option is not provided.
What should have happened:
% ./rhash -r docs
; Generated by RHash v1.4.0 on 2020-08-29 at 20:49.24
; Written by Kravchenko Aleksey (Akademgorodok) - http://rhash.sf.net/
;
;         1877  19:48.34 2020-08-29 docs/CONTRIBUTING.md
;         3215  19:48.34 2020-08-29 docs/LIBRHASH.md
docs/CONTRIBUTING.md BA72845B
docs/LIBRHASH.md D66F30BA

Thank you for reporting the bug and fixing it!
P.S. It seems, when accepting PR via Github UI (to mark it as accepted), Github forcefully rebases the commit instead of fast-forwarding it.

I'm seeing a "done" label on this issue, but the issue is still open. I am running 1.4.0 under Cygwin on Windows 10, and it appears the buggy behaviour is still present. When I specify -r to recurse through directories, it automatically enables --follow despite it not being present on the command line. I tried adding "follow=off" in the rhashrc, but to no effect.

Aha... while http://rhash.sourceforge.net/changelog.php does not show a release date for 1.4.0, I see on https://github.com/rhash/RHash/blob/master/ChangeLog that it was July 14, pre-dating this fix. I anxiously await the upcoming version then. :-)

The fix is included into RHash v1.4.1.

The fix is included into RHash v1.4.1.


Version 0.17 reverted the fix for #1415

Version 0.16 works with Angular 1.2, version 0.17 reports errors using $animate.on.
Looks like this commit.

Can you submit a PR?


"Lower" URL query does not properly set the lower bound for the random number(s)

Fixed. Arguments needed to be parsed as integers before being used


Fix class attribute documentation generation

The default class template behavior for documenting attributes needs to be updated. For example, when docstrings are written for class variables, the docs render both the docstring content and the variables as links to empty pages:

We should enforce documenting these variables in docstrings and not render them in the attributes section. The solution in #983 is to skip them manually in conf.py, but there should be a way to automatically ignore them.

I would love to contribute , can you assign this to me @coruscating

@nitin-pandita Have you started working on this? Happy to assign it to you if you're still interested.
Another issue that needs fixing is classes that inherit from a built-in class, for example dict, renders built-in methods that are not helpful: https://qiskit.org/ecosystem/experiments/stubs/qiskit_experiments.visualization.PlotStyle.html
Ideally these should not be rendered.

@nitin-pandita Have you started working on this? Happy to assign it to you if you're still interested.
Another issue that needs fixing is classes that inherit from a built-in class, for example dict, renders built-in methods that are not helpful: https://qiskit.org/ecosystem/experiments/stubs/qiskit_experiments.visualization.PlotStyle.html
Ideally these should not be rendered.

I would love to work on it, just need a time extension , busy with my semester exams. Hope you understand

@nitin-pandita No worries, there's no rush.

@nitin-pandita No worries, there's no rush.

Thank you, i will try my best to complete it as soon as possible


Revert "Upgrade the k8s libraries we use to version 1.17.9"

Why is this PR needed?
Upgrading the vendored skuba modules in 4.2.2 caused a wrong use of hypekube images, in fact, k8s was not using hyperkube image.
What does this PR do?
This reverts commit 925f9381befa55d9e4fb9d8d8f00455e1e55c288.
Upgrading this vendor library affected the use of hyperkube image.
Anything else a reviewer needs to know?
Special test cases, manual steps, links to resources or anything else that could be helpful to the reviewer.
Info for QA
This is info for QA so that they can validate this. This is mandatory if this PR fixes a bug.
If this is a new feature, a good description in "What does this PR do" may be enough.
Related info
Info that can be relevant for QA:

link to other PRs that should be merged together
link to packages that should be released together
upstream issues

Status BEFORE applying the patch
How can we reproduce the issue? How can we see this issue? Please provide the steps and the prove
this issue is not fixed.
Status AFTER applying the patch
How can we validate this issue is fixed? Please provide the steps and the prove this issue is fixed.
Docs
If docs need to be updated, please add a link to a PR to https://github.com/SUSE/doc-caasp.
At the time of creating the issue, this PR can be work in progress (set its title to [WIP]),
but the documentation needs to be finalized before the PR can be merged.
Merge restrictions
(Please do not edit this)
We are in v4-maintenance phase, so we will restrict what can be merged to prevent unexpected surprises:
What can be merged (merge criteria):
    2 approvals:
        1 developer: code is fine
        1 QA: QA is fine
    there is a PR for updating documentation (or a statement that this is not needed)

I have added following (thanks @mjura) to this PR and the upgrade passed \o/
diff --git a/pkg/skuba/actions/node/upgrade/apply.go b/pkg/skuba/actions/node/upgrade/apply.go
index 42cf718f..2eef7cf4 100644
--- a/pkg/skuba/actions/node/upgrade/apply.go
+++ b/pkg/skuba/actions/node/upgrade/apply.go
@@ -103,7 +103,7 @@ func Apply(client clientset.Interface, target *deployments.Target) error {
                // This updated UseHyperKube field in-memory (unsets it).
                // Note: The cluster cm is uploaded at the end of the kubeadm process, as usual.
                // The whole paragraph can be removed when upgrading from 1.17 is removed.
-               if currentClusterVersion.Minor() == 17 {
+               if currentClusterVersion.Minor() > 17 {
                        initCfg.UseHyperKubeImage = false
                }

Node caasp-master-th-422-update-0 (<IP_ADDRESS>) successfully upgraded against s:4.2.2
when I ran node upgrade on worker - Node caasp-worker-th-422-update-0 is up to date - it did nothing apparently
also ./skuba -v5 addon upgrade apply after the update ... [apply] Successfully upgraded addons
so except the version detection it works - all pods up and running

Closing in favor of https://github.com/SUSE/skuba/pull/1292


Added support for<EMAIL_ADDRESS>for tests

Instead of latest version<EMAIL_ADDRESS>is used because it supports<EMAIL_ADDRESS>Updated all the tests to use<EMAIL_ADDRESS>Test case writing interface has been changed to BDD from EXPORTS.

I didn't realize the syntax changes were going to be this brutal, thanks so much for working through all of these @vmalaviya-splunk! Appreciate all the work here

I didn't realize the syntax changes were going to be this brutal, thanks so much for working through all of these @vmalaviya-splunk! Appreciate all the work here

Always a pleasure Tim.


Fix for issue 984 and 992

PLEASE READ THIS BEFORE MERGING THE PULL REQUEST
This PR populates 15 previously empty expected output files used in the JUnit template tests. These files are associated primarily with state machines. Before merging this PR, someone needs to verify that the output I've added is correct given the existing input .ump files. I've done my best to do this, but I'm not that familiar with state machines.
For example, someone needs to look at stateMachineWithStringComparisonGuard.ump and verify that the output added to stateMachineWithStringComparisonGuard.php.txt is the output one would expect if Umple was run with stateMachineWithStringComparisonGuard.ump. There are around 15 such verification steps required. I think this might be a good task for @jblang94, it might be best to create a new issue to address this task. Please see this commit for a complete list of the expected output files that were populated.
Description
This PR adds a check to assertFileContent to make sure that the expected output file in not empty. Adding this check revealed 15 expected output files that were empty. I have run Umple on the input files associated with these empty expected output files and populated them with the results. Verification is required before this PR can be merged with master.
This PR also fixes issue 992 (see this commit).
Tests
This PR populated all the empty expected output files uncovered by the issue 984 fix, and deleted one duplicate test. It also modifies an existing test case and adds more test cases to ensure that the fix introduced to address issue 992 is correct.
Closes #992, #984

Failed tests are from your changes
[junit] Running cruise.umple.implementation.java.JavaInterfaceTemplateTest
[junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 0.056 sec

@Nava2 Yeah, I added some bit more code to a couple of the .ump files. I guess it would be better to just split it into a second file, I'll do that instead.

Though I don't understand why it would be green for me locally but fail the build in travis?

@Nava2 Thanks for catching that

In the following example, Umple doesn't generate default implementation to the method in the interface I.
interface I{
  void test();
}
interface I2{
  isA I;
  void test2();
}
interface I3{
  isA I2;
  void test3();
}
class A{
  isA I3;
}

BTW, Please always make sure to request a separate PR for each issue. Never mix them, except if it's about typos in  wiki

@opeyemiAdesina please check the test cases related to your work.

I'll have a look at that issue, thanks. I was originally going to make this PR just for 994, but 994 can't be resolved until the interface hierarchy stuff in 992 is dealt with (one of the tests that was blank was testing the interface hierarchy stuff).

I checked the code related to state machines in Java and it looks ok.
Regarding the empty files, please check the history of them. Looks like they were ok until someone completely removed them. Check this  out

Hm, that's weird.  Did you find that for any other files aside from the stuff testing the interface hierarchy? I did a check of some of the other blank files and they seem blank from the beginning.

I'll use the old tests for the interface hierarchy stuff if there are any discrepancies between the the test I added and the old tests.

@I didn't see. Please explore the necessary ones. Good luck :-)

@vahdat-ab I've pushed a fix for the interface hierarchy code and added the test case for it you provided to the JUnit tests. I've also checked the expected output files for the interface tests, there aren't any significant differences between the output I added and the original stuff from 2011. All the other expected output files started empty.
Whenever the remaining expected output files have been verified I think this PR can be merged.

@opeyemiAdesina I wonder if you will be able to have a look at the modified examples related to your work in this PR soon?

Thanks @opeyemiAdesina
@AdamBJ Please update your repository to see new modification done by @opeyemiAdesina. If everything is fine, let me know and I'll merge it.

@AdamBJ pay attention that there is a conflict because Opeyemi updated his files.

@opeyemiAdesina I had a look at the file you added, seems like it's the same as the one I originally deleted. The reason I got rid of it is because these two tests:
 @Test //@Ignore
	  public void ExampleFile()
	  {
		assertUmpleTemplateFor("alloy/ExampleFile.ump","alloy/ExampleFile.alloy.txt");
		Assert.assertEquals(true, (new File(pathToInput + "/alloy/ExampleFile.als")).exists());
	  }

	  @Test //@Ignore
	  public void BankingSystem()
	  {
		assertUmpleTemplateFor("alloy/BankingSystem.ump","alloy/BankingSystem.alloy.txt");
		Assert.assertEquals(true, (new File(pathToInput + "/alloy/BankingSystem.als")).exists());
	  }

Seem to be exactly the same. BankingSystem.ump is identical to ExampleFile.ump, as are ExampleFile.alloy.txt and BankingSystem.alloy.txt. It seems like the tests are testing the exact same thing, so I got rid of one of them. If that was a mistake let me know.

@opeyemiAdesina I wonder if you can have a look at this PR and if it's ok then I can merge it.

@vahdat-ab @opeyemiAdesina We just need to decide whether to keep the ExampleFile() test or not. I don't think we should, since it's identical to the BankingSystem test below it.

I have always used the file for testing new features before creating
additional tests. However, since I don't intend to make any changes at the
moment you may remove it.
On Feb 26, 2017 7:54 PM, "Adam Bolding-Jones"<EMAIL_ADDRESS>wrote:

@vahdat-ab https://github.com/vahdat-ab @opeyemiAdesina
https://github.com/opeyemiAdesina We just need to decide whether to
keep the ExampleFile() test or not. I don't think we should, since it's
identical to the BankingSystem test below it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/umple/umple/pull/993#issuecomment-282603946, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AG0omN32zLYEARNcyL2g_VshVZ0A-O-mks5rgh6sgaJpZM4L3yJs
.

@AdamBJ please resolve the conflict shown in your PR and then I'll merge it,
thanks @opeyemiAdesina

@vahdat-ab I made a mistake when I re based 984. Working on a fix so that the commit history isn't so messy

I can't figure out a way to clean up the commit history without creating a new branch. I'm going to close this PR and open a new one from the new branch with clean commit history.

@AdamBJ you can do a reset --hard COMMITISH then rebase ORIGINAL-COMMITISH.

@Nava2 How can I push those changes to the remote repo? I was able to get my local repo reverted doing something like you suggest, but when I tried to push to the remote it said I couldn't since my local branch was behind the remote branch.

I've never used COMMITISH before, I'm having some trouble though:
$ git reset --hard COMMITISH
fatal: ambiguous argument 'COMMITISH': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

@Nava2 How can I push those changes to the remote repo? I was able to get my local repo reverted doing something like you suggest, but when I tried to push to the remote it said I couldn't since my local branch was behind the remote branch. At this point I'm afraid I've made such a mess of things that I just want to amputate the mess and start again.

In this case, teh issue is that you would have to "force" push. You've rewritten history, thus you'd have to force the remote repository accept it.

I've never used COMMITISH before, I'm having some trouble though:

A "commitish" is just either: 1) commit, 2) branch, 3) remote branch, 4) tag, etc.. Anything you can use to reference a commit tree.


⚠ Mobitopup has degraded performance

In 265303c, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 22633 ms

Resolved: Mobitopup performance has improved in 07cc8d8.


RS-126: Optimize landing page

The landing page structure was change:

banner with tagline, subtitle and white paper button
benefit section
FAQ section
call to action section for white paper

The white paper was change as follows:

new slug "whitepaper" instead of "reductai"
new date (2024 instead of 2023) on the white paper image and pdf
Download button larger with text "we'll never share your data.."

I agree, I do like the FAQ section to try to answer the last questions people might have, but we can keep the SDKs, web console and CLI out of it.
The white paper buttons at the beginning and the end seem good enough even with longer landing page. Good point for the benefit icon sizes, it looks better now.


(conda) activate doesn't work

Windows cmd (works):
C:\>conda env list
iCalendar                C:\Anaconda3\envs\iCalendar
python2                  C:\Anaconda3\envs\python2
root                  *  C:\Anaconda3

C:\>activate iCalendar
(iCalendar) C:\>conda env list
iCalendar             *  C:\Anaconda3\envs\iCalendar
python2                  C:\Anaconda3\envs\python2
root                     C:\Anaconda3

platformio-atom-ide-terminal (doesn't works):
PS C:\> conda env list
iCalendar                C:\Anaconda3\envs\iCalendar
python2                  C:\Anaconda3\envs\python2
root                  *  C:\Anaconda3

PS C:\> activate iCalendar
PS C:\> conda env list
iCalendar                C:\Anaconda3\envs\iCalendar
python2                  C:\Anaconda3\envs\python2
root                  *  C:\Anaconda3

platformio-ide-terminal 2.7.0
atom 1.23.0
Windows 10
P.S. What is PS at the beginning of each line?

I think PS indicates that you are using powershell rather than cmd.exe. Go to the platformio-ide-terminal settings and replace the default terminal with c:\windows\system32\cmd.exe and your problem should be fixed.

Change directory inside Anaconda3:
mypthon\Scripts\activate 'environment'
It should work!!


Add option to remove two way data binding in 2.x

Version of x-select:
2.x
Expected Behavior
To change the selected option in x-select and not mutate the underlying value without an action.
Actual Behavior
It mutates the value of x-select without an action.
Description
For emberx-select v2.2.0 we would like to provide an option to remove the two way data binding we do by default. This will set us up for v3.0.0 that will permantly remove two way data binding.
Approach
I think we can wrap a simple conditional around this line.
Testing
Since the updating of the value is already abstracted out into its own method we can stub it in tests and make sure it's being called when two way data binding is enabled. And we can also assert that it doesn't get called when it's disabled.
cc: @dgaus

@dgaus 2.2.0 has been released!

I am testing the new version but it doesn't seem to work as intended. It seems that if _this.updateValue() is not called, the action is called with the old value instead of the new selection.

 I'm going to try and fix this by tonight!

No worries. I did a sort of fix on https://github.com/dgaus/emberx-select/commit/50b7c334ca6e6b8027caed4c1ebacfcb3c659466 , I'm not too happy about it, but perhaps it's useful to you.
The workflow I'm trying to achieve is:

User changes selection
A prompt is displayed, "are you sure?"
If user clicks yes -> update the model and save (this is achievable)
If user clicks no -> ignore the change (ok) and set back the selection to the original one (I don't know how to do this, since now the value is not associated with the current choice)

As a workaround I'm using model.rollbackAttributes, but I would rather do it using one-way binding.

Should actually be fixed #132!


Routing Alerts to AlertManager from Thanos Ruler - How to set custom PromQL address?

Is your proposal related to a problem?
When we have the thanos-ruler pods pointing to a thanos-query-frontend endpoint, our alerts get a nice friendly Alert Source: https://…./query/… label that helps our developers get right to the source of the alert.
However, when we run the thanos-ruler pods against either Amazon Managed Prometheus or Grafana Cloud, we get a shortened URL that just gives us a query-path .. the problem is neither Grafana Cloud nor Amazon Managed Prometheus provide a /graph endpoint.
Describe the solution you'd like
It would be ideal if there were a few options here..

Allow us to templatize the URL to anything we want (with the alert query as an argument).
Have some native understanding of the Grafana /explore endpoint URL structure and allow us to route to that.

Additional context
https://cloud-native.slack.com/archives/CK5RSSC10/p1681574164937839

Great issue!
The acceptance criteria

Thanos Rule has configuration flag that allows customizing (template?) Alert Source field.

PR has been merged ✅, thank you @zhuoyuan-liu 🙇

@diranged

Have some native understanding of the Grafana /explore endpoint URL structure and allow us to route to that.

Do you have such an template to share?


Integration Test - Release - 2022/01/14 08:10:01

Auto create for integration test. IssueCommandFlow

#pri1


OverflowError: value too large to convert to int

Could I ask if you might have any tips on how to overcome this error?
I'm running your 1M cell code, but I tried it on my own set of 2.8M cells.
Here's my matrix:
sparse_gpu_array.shape
# (2886934, 33567)

sparse_gpu_array.nnz
#<PHONE_NUMBER>

Let's try to run this:
sparse_gpu_array, genes = rapids_scanpy_funcs.filter_genes(sparse_gpu_array, genes, min_cells=1000)

---------------------------------------------------------------------------
OverflowError                             Traceback (most recent call last)
<timed exec> in <module>

~/work/github.com/slowkow/rapids-single-cell-examples/notebooks/rapids_scanpy_funcs.py in filter_genes(sparse_gpu_array, genes_idx, min_cells)
    269         Genes containing a number of cells below this value will be filtered
    270     """
--> 271     thr = np.asarray(sparse_gpu_array.sum(axis=0) >= min_cells).ravel()
    272     filtered_genes = cp.sparse.csr_matrix(sparse_gpu_array[:, thr])
    273     genes_idx = genes_idx[np.where(thr)[0]]

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/base.py in sum(self, axis, dtype, out)
    388
    389         if axis == 0:
--> 390             ret = self.T.dot(cupy.ones(m, dtype=self.dtype)).reshape(1, n)
    391         else:  # axis == 1
    392             ret = self.dot(cupy.ones(n, dtype=self.dtype)).reshape(m, 1)

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/base.py in dot(self, other)
    307     def dot(self, other):
    308         """Ordinary dot product"""
--> 309         return self * other
    310
    311     def getH(self):

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/csc.py in __mul__(self, other)
    111                 return self._with_data(self.data * other)
    112             elif other.ndim == 1:
--> 113                 self.sum_duplicates()
    114                 if cusparse.check_availability('csrmv'):
    115                     csrmv = cusparse.csrmv

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/compressed.py in sum_duplicates(self)
    333             self._has_canonical_format = True
    334             return
--> 335         coo = self.tocoo()
    336         coo.sum_duplicates()
    337         self.__init__(coo.asformat(self.format))

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/csc.py in tocoo(self, copy)
    214
    215         """
--> 216         return self.T.tocoo(copy).T
    217
    218     def tocsc(self, copy=None):

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupyx/scipy/sparse/csr.py in tocoo(self, copy)
    268             indices = self.indices
    269
--> 270         return cusparse.csr2coo(self, data, indices)
    271
    272     def tocsc(self, copy=False):

~/.conda/envs/rapidgenomics/lib/python3.7/site-packages/cupy/cusparse.py in csr2coo(x, data, indices)
    900     cusparse.xcsr2coo(
    901         handle, x.indptr.data.ptr, nnz, m, row.data.ptr,
--> 902         cusparse.CUSPARSE_INDEX_BASE_ZERO)
    903     # data and indices did not need to be copied already
    904     return cupyx.scipy.sparse.coo_matrix(

cupy/cuda/cusparse.pyx in cupy.cuda.cusparse.xcsr2coo()

OverflowError: value too large to convert to int

Hi @slowkow,
It looks like this issue may have been addressed already in cupy/cupy#4223. We are running into similar problems as we work through upcoming changes to use Cupy 8.0 and put more of the filtering logic on the GPU device.
An option for us to get around the size limitation in the gene filtering step might be to allocate an empty 1-d output array of size n_cells and then perform the sum over a few batches. Take the following as an example to populate the summed array with the sums across the genes for the first 100 cells:
summed_gpu_array = cp.empty(sparse_gpu_array.shape[0], dtype=cp.float32)
summed_gpu_array[0:100] = sparse_gpu_array[0:100].sum(axis=0)

Corey, thanks for the reply! If I eventually get back to this error, I might try to modify your function filter_genes() to perform a sum over multiple batches and see if the code runs from that point onward.
Could I please ask if you have successfully run the RAPIDS analysis on a real dataset that is larger than the 1M cell dataset?


print a warning when model cannot be opened, print nothing when succeeding

When evaluating stuff in parallel or doing something multiple times, my terminal gets spammed with 100s of copies of the following line:
Loading model file side_gates/geo_/model.json.

This PR removes that print statement and only prints a warning when the file cannot be opened.

Looks good, thanks Bas!


Taiga is missing in the list

Could be nice to get added: http://usablica.github.io/front-end-frameworks/compare.html

Any progress?

Oh sorry! No, how can I add Taiga?

@AljanScholtens I think create a PR for https://github.com/usablica/front-end-frameworks

@reinaris @AljanScholtens I did a PR in June 2015 but the repo hasn't been updated for two years.
https://github.com/usablica/front-end-frameworks/pull/121


Remove unused provider: hashicorp/template

what
Removed an unused terraform provider: hashicorp/template
why
This provider was not used anywhere in the module. It is also deprecated and there is no darwin_arm64 version available, so I was unable to use this module with an M1 mac

/test all

Thanks @joshfriend !


cli: Add basic rad tui implementation

Description
Introduces rad tui which runs a tui application that, as a first step, shows the project payload.
Screenshot

Great.
I'm in the middle of overhauling our CLI infra (See #353) and moving us to termion as the backend, so perhaps you could already activate the termion backend of tuirealm, instead of crossterm.
I'm also thinking the tui should be its own crate (radicle-tui), which can depend on radicle-cli if necessary. This is cleaner than the feature flag imo, and allows the TUI to be installed later without rebuilding the CLI.


Throttle drops to 0 sometimes for a second during position hold (MC)

I put the drone in position hold about 10m above ground. Without me doing anything it suddenly dropped quiet fast, lucky it recovered before it hit the ground (in most cases). At first I was thinking some ESC problem but I had the same issue with a different MC. Also does "actuator_controls_0_0.control[3]" and "vehicle_attitude_setpoint_0.thrust_body[2]" show that the command was for throttle was set to 0 for a very short period.
That is with firmware version 1.9.2 and on pixhawk as well as on pixhawk4 hardware the same.

instead of landed check for ground contact.
although you should probably upload the log

You are right it is a false ground contact indication in mid air. It seems it is related to #11683 .

@ArminStrobel is this still present with 1.10-beta or base after this fix #11172?

I only can confirm that for the latest stable release:
Firmware Version:	1069058 (1.9.2 release)
I damaged one of my vehicles badly due to this. I am a bit hesitant to test beta versions.
I assume not everyone has that problem, could it be related that I might don't have default values for the LNDMC parameters?
Regarding #11172 I am not sure if I understand the intend here proper, but what I want to point out and it might be considered that in position hold you want to have vertical and horizontal speed to be zero. Using that alone for ground contact detection will not work since a good tuned position hold controller will have vertical and horizontal speed to zero (within noise). So there is no way you can reliably detect and difference between hovering and having ground contact.
Also I would consider to give the option to choose if the motor gets switched off on ground contact, since any unintentional contact will switch it off. My suggestion to make that an option and have it by default deactivated.
Again, I am not understanding the discussion in #11172 completely, so please take my comments with a grain of salt.
I think the only way to detect reliable (except with a ground contact sensor) is to monitor the thrust when sinking is commanded and see if it falls below a certain limit and the vertical velocity is close to zero as well as the acceleration needs to have a mean of 1G.

Actually I was reading my own comment. I never commanded a landing (not by stick, nor by telemetry). Shouldn't be shutting down the motor just be allowed on ground contact when a landing is commanded? #11172

Sorry about damaging the vehicle, and I understand your hesitation.

Using that alone for ground contact detection will not work since a good tuned position hold controller will have vertical and horizontal speed to zero (within noise). So there is no way you can reliably detect and difference between hovering and having ground contact.

Right, that makes sense. @MaEtUgR or @bresch do you have thoughts on this

well there is also an "in descend" condition where the vertical velocity setpoint has to be such that the vehicle has the landing intention (aimed donwards with at least 0.9 of landing speed).  So hovering doesn't fall under this case. The problematic part could be the switch from hovering to fast descending, but the hysteresis logic deals with this.
As a suggestion, the "in_descend" check might be made more reliable in missions such that instead of z velocity we check for the SETPOINT_TYPE_LAND

@dusan19
There should be no way that the motors can be set to 0 during any kind of maneuver, without the intend of the operator to land. So any decision to switch off the motor has to include the intend of the operator / mission. Only if mode is set to landing the motors will be allowed to be switched off.
You need to check for following all together:

Thrust below a certain level (output of the position controller)
Stick all the way down or SETPOINT_TYPE_LAND == true
z velocity zero
z acceleration close to 1G (to cover the case where you in mid air and you about to to decent fast but not yet have built up speed to indicated that)

@julianoes Thank you for understanding. Is there a way I can deactivate this function with a parameter? Because i don't have any use of that function and only poses a risk. I do not want that the vehicle has the authority on its own to shutdown the motor anytime.

Thats what im trying to say, landing intention logic is already a condition for ground contact, so if you were just hovering this should have never happened since you would normaly not have low thrust or vertical velocity setpoint close to the landing one.
It would be best if you could share the log file.
I agree that in general the switch to descending could be more robust to false positives

@dusan19 I think you we should clarify how landing intention is defined. With landing intentions I mean it is in landing mode either by a switch from the user or part of a mission to land. I don't think that you understand what I am trying to say. let me try it again.
Landing intention is not to have low thrust. Low thrust is a state not an intention.
Sorry I am getting frustrated with this. I would like to know how I can deactivate this function.
Like many other ones I am relying that this software is not killing my vehicle.

It would be great if we could look at all the data available in the log to come up with an accurate diagnosis. Would you be able to share it?

Sorry, I prefer not to share it because it contains a lot of information I prefer not to share.
But I can put any kind of plot up you want, if you can work with that?

I am agree with @ArminStrobel intention is a flight mode, not conditions that might lead to low trust and/or velocity and/or acceleration.
I am not sure why but also in my craft thous condition met even when I just hovered, that might be related to vibrations, or the fact that I set minimal thr to ~25%.
On my custom firmware I did changed the logic so ground contact can only be on landing command.
I didn't merge it to master because I still waited to responses about #11683, that the trust to 0 should be only be on the LANDED state, (there are FLYING->GROUND_CONTACT->MAYBE_LANDED->LANDED states)

It happened again. This morning I made a short flight test and again a vehicle badly damaged. I did set LNDMC_LOW_T_THR to 0. It was really nice hovering before the crash.
@BazookaJoe1900 thank you understanding what I try to say. The motors should be only deactivated in the LANDED state and nowhere else(especially not before Maybe landed). If I look at the log data the LANDED state is absolutely accurate. So why not using this state to deactivate the motors as it was probably intended by the people who created that state.
I am quiet disappointed and lost trust into the PX4 software stack, since that is supposed to be a stable release.
@julianoes can you tell me which release does not have this "function / issue"? I assume this issue and #11683 are the same and both are related to #11172. Can somebody look at #11172, for me it looks like very bad idea?
I can share the log file from this morning.
https://review.px4.io/plot_app?log=6e0ede8b-882b-4146-9fd7-fbc162bb5724

here are some log analysis:
For false ground contact detection at t=~97s:

the drone is hovering in mission mode, and having a steady state error in z velocity controler (around 0.3m/s, might be the tuning), so the vz setpoint is around 0.4 and slightly increasing.
Landing speed is set through a parameter to 0.5m/s, even though i see that in the parameter definition file the min value is noted to be 0.6.
Note: In position and altitude controled modes the intention to land has to be determined from the z velocity setpoint (up-down stick input) and is set to true when the user controls the drone to go down with velocity close to the landing one. Unfortunately the same logic is used for auto modes, which can be improved as suggested in one of my first comments here.
In this case the threshold for landing intention is 0.45m/s due to the land speed parameter setting. Velocity setpoint increases and when it reached this threshold, landing intention was set to true.
due to the steady state error, the z velocity was pretty low (hovering), so the "no vertical movement" was fulfilled as well
there was no horizontal movement

landing intention + no vertical and horizontal movement = ground contact
For the false ground contact detection at t=~102:

The operator was flying in altitude mode. The throttle stick was all the way down so vz setpoint was 0.5m/s which was interpreted as landing intention.
The drone was still trying to recover from the first false ground contact and even though the thrust was at max it was still losing altitude. When it started gaining altitude it switched to altitude mode with the throttle stick all the way down. It continued gaining altitude due to a slow vz response and overshot the 0.5m/s setpoint all the way to 0 when it detected no movement and ground contact.

Suggestions (if possible with this drone):

tune the land speed parameter, higher value would increase the landing intention threshold but also the vertical movement one, so carefully.
tune the z position-velocity controller to get a decently quick response and reduce the steady state error.
Note: the drone has hover thrust at ~75% which probably makes it difficult to get fast control of vertical position and velocity.

Hope it helps a bit, although I assume you are hesitant to test more if it keeps destroying your drones :(

@dusan19 Can you explain exactly what values and parameters are used for the so called "landing intention detection"? Wouldn't be simply checking if the stick is all the way down much more reliable?
Btw at t=102 drone already crashed and was on its side and I pulled throttle all the way down, but had to switch to manual mode to disarm the motor.

@ArminStrobel The reason you're experiencing this corner case is the combination that you've set the land speed parameter below the absolute allowed minimum (it is set to 0.5 for your vehicle, the lowest hard limit is 0.6, the default 0.7) QGC will have warned you that this is potentially unsafe in the UI - please let us know if you think it didn't and your Z-controller lacks enough integral gain. It needed the combination of both for it to happen.
And if you hadn't have a high hover throttle (overweight airframe) it wouldn't have dropped that fast. So it really needed all three factors to lead to a crash.
That is why it is working for most other users. However, we want the system to be easy to configure and more flexible, so we're currently discussing with the dev team how we can re-architect this.
The goals for this are:

Option to hard-disable any auto-throttle handling behavior (for setups like yours)
Forcing safe parameter values also on the PX4 side, not just in QGC (so if you set the landing speed too low it will either increase the landing speed or disable auto-disarm)
Auto-estimating hover throttle, which should allow this to work better and without you needing to configure anything.

FYI; We just saw this same behaviour on a large 2m tip-to-tip octorotor, in a high wind condition. With large props and loads of intertia on the prop/motor combo, this is extremely problematic behaviour. If someone contacts me i can send you the logs on PM.

In our experience this is caused by MPC_HOVER_THR being set incorrectly. https://dev.px4.io/v1.9.0/en/advanced/parameter_reference.html#MPC_THR_HOVER
The land detector thresholds are driven by that parameter, and if the aircraft is hovering at a significantly different throttle than the the parameter value, we see those hops caused by the land detector switching in and out of GROUND_CONTACT state. In our case, we often have hover throttle set for a payload weight and then fly it light. The behavior is after slowing down from a climb typically will trip it in the deceleration. Setting hover throttle correctly makes it go away in all our cases.

Today we also had issues with the land detector as you can see in this log : https://logs.px4.io/plot_app?log=4eea26ba-02eb-4b37-9de2-3e576693227b (5:58-6:09) (don't bother with all the other weird stuff going on :P)
The ground contact detection really isn't robust enough. Having a drone with large inertia (in this case a VTOL where wings can generate extra lift) on Z velocity and a fast change in the Z velocity setpoint when previously hovering is enough to trigger a ground contact. The thrust was even above MPC_THR_HOVER ! (which I set too low on purpose) If it is that easy to get around the low thrust criterion, why even put it there in the first place? I'd prefer to have a low thrust criterion as an individual AND criterion.
In high winds we've consistently had the same problems with our larger VTOL drone (which already in calm conditions is rather slow to react with the large wing surface). I would appreciate if we could set the hysteresis time for ground contact as a parameter to take into account the dynamics of the drone. A larger hysteresis time on ground contact could have spared us a few ugly moments.  I don't see any danger, only an inconvenience, in late ground contact detection, but a big danger on triggering it too early, as this issue proves well enough.
(If someone has inputs on how to improve the z velocity controller, I gladly take them :) )

@julianoes julianoes

@ArminStrobel is this still present with 1.10-beta or base after this fix #11172?

Hello, I am using v1.10.1 stable release and I had a very similar problem where the drone would detect landing while flying (about 8 meters above ground) and then decrease thrust to zero. We had a total loss of the vehicle. In answer to your question, the problem still exists.
@LorenzMeier
Our landing speed is 0.6 m/s and we still encountered the problem. I do not think that the proposed solution solves the problem.

@julianoes I updated to v1.10.1 and adjusted my vertical control parameters appropriately (I had I-part originally at 0). Since then I never had an issue anymore. I wold say those are about 50 flights.
If you look at your data does vehicle_local_position_0.z fit well with vehicle_local_position_setpoint_0.z in general?
I am not sure what the current state of the logic is behind the ground contact detector (specifically the landing intention determination), but in the original implementation (if I understood it correctly) it was in my opinion the wrong approach. Maybe @BazookaJoe1900 can help.

Yes, the vehicle local position Z follows the setpoint well, though Z-velocity could use some improvement.
Correct me if I'm wrong, but if there are high wind or turbulent conditions that could cause a divergence in Z or Z-velocity, then this landing detector could get triggered again as well.
We had about 7 hours of flight on v1.10.1 across approximately 20 flights before this crash occurred. We've been on PX4 since 2016 and haven't seen anything like it. There is a marked difference between this behavior and the landing behavior of v1.8.2, the last version of the firmware we were using.

@julianoes julianoes

@ArminStrobel is this still present with 1.10-beta or base after this fix #11172?

Hello, I am using v1.10.1 stable release and I had a very similar problem where the drone would detect landing while flying (about 8 meters above ground) and then decrease thrust to zero. We were in RTL mode set to land after 60 seconds of loitering when this happened. There were no winds. We had a total loss of the vehicle--our vehicle is large and expensive and it was quite heartbreaking to see this happen. In answer to your question, the problem still exists.
@LorenzMeier
Our landing speed is 0.6 m/s and we still encountered the problem. And our MPC_HOVER_THR parameter was set such that center stick induced a hover. I do not think that the proposed solution of setting the correct landing speed solves the problem.

Can you share the log?

And our MPC_HOVER_THR parameter was set such that center stick induced a hover

From your log, it seems that this isn't exact; your hover thrust is ~37% while MPC_THR_HOVER is set to 50%. We're now running an estimator to automatically adjust this value, but you apparently don't have it in your version of the code.

MC land detector ground_contact detection fixes have been merged in https://github.com/PX4/Firmware/pull/15083.


Remove excess whitespace from end of line to comply with cargo fmt.

My trivial first commit... I noticed that we are almost cargo fmt compliant. There's just two lines with extra whitespace at the end. This PR removes that whitespace.

Oh, good catch. Thank you!
My editor runs cargo fmt automatically on save, so these were probably introduced by some contributors.
I think it's probably a good idea to check this in CI, at least as a warning for future contributions. Let me see if I can set it up quickly.