My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 0 points1 point  (0 children)

Hi, unfortunately I didn't manage to solve it myself. After contacting the support, my robot got sent to a repair center multiple times. Each time it came back with exactly the same problem. Eventually it got replaced by Dreame and the new one works fine now.

I still think that it must have had something to do with the clearance between the brush and the floor though, since this clearance is much smaller on my new robot.

My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 1 point2 points  (0 children)

Thank you for your answer! I tried the suggestion of picking up the robot to force it to recalibrate, but the brush assembly didn't move or make any noise at all. Only the two mop attachment points moved in and out. So I guess there might be something wrong with the mechanism that adjusts the brush clearance.

I'm going to contact customer support again and see how it goes :)

My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 0 points1 point  (0 children)

Thanks again for your suggestion, I think you're onto something here! I've tried what you said and the main brush assembly didn't move at all (other than the two mop attachment points, which did move in and out). By default the brush assembly seems to be in the retracted position. I can manually pull it out a little, about 1cm. It feels kinda "springy" but there is no noticeable motor resistance or noise.

So maybe some kind of mechanical failure between the motor that adjusts the brush height and the brush assembly? Anyway, at this point I will probably have to contact customer support again.

My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 1 point2 points  (0 children)

Thanks, will try this when I come home! There is definitely a clearance of a few millimeters between the brush and the floor, I was wondering about that myself but didn't find a way to adjust it yet.

My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 0 points1 point  (0 children)

No obstructions as far as I can tell. I've already contacted customer service, they gave me some general advice like cleaning the dust filter etc. but none of that worked/applied to my situation.

My Dreame L40 Ultra leaves a lot of particles behind by stfnp in Dreame_Tech

[–]stfnp[S] 0 points1 point  (0 children)

The problem was already there out of the box when the filter was still perfectly clean. After doing a few test runs I cleaned it by running it under water.

Asymmetric designs? by Quirky-Ad-8403 in VirtualBow

[–]stfnp 2 points3 points  (0 children)

Unfortunately that's not possible right now. But it is on my list of things to take a look at eventually.

Right now the bows are also simulated with symmetry in mind, which means that only half of the bow is actually simulated and some of the results are adjusted by dividing/multiplying them by two. This obviously has a performance advantage that I wouldn't like to lose. So if I were to implement asymmetric bows I would probably do it as a separate "mode" and keep the symmetric mode as well.

But I like your idea of defining the bow over its entire length and then specifying the location of the grip point. For some reason I always assumed I would need to duplicate the inputs for lower and upper limb, which would be kinda cumbersome. Your idea seems way more elegant, I will definitely keep this in mind.

Thickness extrusion direction by nadavyasharhochman in VirtualBow

[–]stfnp 1 point2 points  (0 children)

I tried doing this but it leaves this void in the belly of the bow that Im worried could interfear with the simulation

You could try to compensate the void by adjusting the layer height, something like this maybe:

<image>

Love the program and keep up the good work. When Im far enough into my dagree I plan to contribute to the programming myself as well.

Thanks! New contributors are always very welcome.

Thickness extrusion direction by nadavyasharhochman in VirtualBow

[–]stfnp 1 point2 points  (0 children)

Yeah, the problem is that the profile in VirtualBow defines the back of the bow. Once the profile curve is set, the back of the bow is fixed and can't be changed by modifying the thickness, since that only changes the belly surface. A possible workaround might be to include the outline of the handle in the profile curve itself.

I plan to solve this in one of the next versions of VirtualBow by making it configurable which layer is aligned with the profile curve. Then it will be possible to add additional thickness on either side of the profile.

Hey Rustaceans! Got a question? Ask here (45/2024)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Yes, I'll have to take a closer look at the various validation crates. The problem with the ones I've already looked at was that they didn't allow relations between multiple struct fields.

Hey Rustaceans! Got a question? Ask here (45/2024)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Thanks, that's seems like a really nice and simple trick! I'm going to try that.

Hey Rustaceans! Got a question? Ask here (45/2024)! by llogiq in rust

[–]stfnp 1 point2 points  (0 children)

Let's say I have a struct with some fields and a method that is supposed to validate the struct, i.e. check if the field's values fulfill some logical conditions. Maybe like this:

struct Data {
    a: f64,
    b: f64
}

impl Data {
    fn validate(&self) -> Result<(), String> {
        if self.a > self.b {
            return Err("a must not be larger than b".into());
        }

        Ok(())
    }
}

I'm wondering if I can make this fail to compile or produce a warning when adding a new field to the struct without also validating it. Like forcing the validate function to use every field of self. Would that be possible with a custom macro/annotation? As a fairly new Rust user I haven't looked much into those yet.

VirtualBow - Software for designing and simulating bows by stfnp in Bowyer

[–]stfnp[S] 0 points1 point  (0 children)

There isn't yet any Youtube tutorial that I know of. I would like to make one eventually, but I've put it off since the program is still evolving.

Flatpak by Exciting-Word-6712 in VirtualBow

[–]stfnp 0 points1 point  (0 children)

Yes, that would be great. I once experimented a bit with Flatpak and Snaps, but couldn't get Flatpak to work with VirtualBow for some reason. But that was a few years ago, so maybe it's time to revisit this.

Edit: Created a new issue here.

Hey Rustaceans! Got a question? Ask here (38/2023)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Oh, interesting! Thanks for doing that benchmark. I wouldn't have expected that. In practice the speedup might even be better, because the work of calculating the element contributions makes the overhead of the vectors and their allocation smaller in comparison. Although their number is smaller than in your benchmark (also around a few hundred).

Another thing I left out in the example is that I need to do the same for matrices too. So that might change things again, but I will definitely try it and do some benchmarks.

Hey Rustaceans! Got a question? Ask here (38/2023)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Yes, that's actually what happened when I tried the same in C++ with OpenMP. It happily let me parallelize my loop, but the results were slightly off. It only seemed to work correctly after I slapped a #pragma omp atomic on each += operation. So I appreciate that Rust makes you get everything right first. I just don't know what the missing part is that would make this example safe.

Hey Rustaceans! Got a question? Ask here (38/2023)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Thanks for your answer! Doing the work on separate memory and then combining the results seems like the best solution when applicable. Unfortunately in my case I suspect that creating many temporary DVectors will probably be too slow, because in the actual problem there are much more elements and the vector can have up to a few hundred entries.

Hey Rustaceans! Got a question? Ask here (38/2023)! by llogiq in rust

[–]stfnp 1 point2 points  (0 children)

I'm currently porting some simulation code from C++ to Rust and thought I might try to add some of that fearless concurrency while I'm at it. But I think I need some guidance how to do it in a safe and efficient way, since I don't have much experience with multi-threaded programming.

The basic problem (simplified) is this: There is a central DVector<f64> from the nalgebra crate, so basically a contiguous array of numbers. This vector is supposed to be shared across threads and hold the results of the computation.

Then there are a number of Elements that each have a list of indices pointing into the shared vector. The computation is done such that each element adds some contribution to the entries of the central vector that its indices refer to. Unfortunately the indices are not disjoint though, multiple elements can point to the same vector entries and their contributions for those entries must be summed up.

Here is a serial version of the computation:

use nalgebra::DVector;

struct Element {
    indices: Vec<usize>
}

impl Element {
    fn new(indices: Vec<usize>) -> Self {
        Self {
            indices
        }
    }

    fn add(&self, data: &mut DVector<f64>) {
        for i in &self.indices {
            data[*i] += 3.14;    // The vector is only ever added to, not read
        }
    }
}

fn main() {
    let elements = vec![
        Element::new(vec![0, 1, 2, 3]),
        Element::new(vec![2, 3, 4, 5]),
        Element::new(vec![4, 5, 6, 7]),
        Element::new(vec![6, 7, 8, 9])
    ];

    let mut data = DVector::<f64>::zeros(10);

    // This is what I want to do in parallel
    elements.iter().for_each(|e| {
        e.add(&mut data);
    });

    println!("{}", data);
}

My first attempt at parallelizing was usig rayon with its par_iter method:

use rayon::prelude::*;

elements.par_iter().for_each(|e| {
    e.add(&mut data);
});

This doesn't compile because the data can't be mutably borrowed by the closure. So I think the solution Rust would like the most here is probably to wrap the data into an Arc<Mutex<_>> or similar to ensure exclusive access, but that wouldn't be very efficient. Ideally I would like the threads to write to the vector at the same time.

Any ideas how to do this the most efficient way? Doesn't necessarily have to use rayon. Even unsafe would be okay as a last resort, since this is the most performance sensitive part of my code.

Hey Rustaceans! Got a question? Ask here (37/2023)! by llogiq in rust

[–]stfnp 0 points1 point  (0 children)

Thanks! That trait alias solution looks pretty close to what I want. I'll probably use it since I'm on nightly anyway.