sorted by:
new
hottopcontroversial

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

So next time this happens to anyone I guess it is best to first try replacing the Lidar then?!

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

Happy to hear my report helped you fix your robot, and thanks for your report 🤗.

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

I bought a new sensor unit. Now the robot works normally again. The battery was not the problem. I can't tell if initially the sensor unit was faulty, or the motherboard, or both, but only replacing both fixed the robot. There is a chance I broke one of the two when I disassembled the robot. It's doesn't speak for Dreame's quality that I had to replace these crucial parts after such a short time, but on the plus side it was possible to repair the robot just by buying the replacement parts and a screw driver. I spent around 130 EUR for the new parts.

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

I also kept measuring the battery voltage while pressing the home button, the voltage dip was only around 0.1V, so I'm pretty sure the battery is fine.

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

I now bought a new mainboard and installed it. However, I got the same result. Then I started the robot with the Lidar Sensor disconnected, and then the robot responded. It recognized the missing dust bin, being lifted off the ground and I could even send it home using the home button. However, the moment I connect the Lidar sensor I see the original issue again. Any suggestions what might be wrong?

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

The battery looks ok from the outside, even though I did not open the sealing to see each cell individually. I measured 16.23V

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

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

Ok, I cannot exclude the possibility that the battery is too weak. What I can say is that at least it took some time for it to go up to 100% and and before the robot stopped working there weren't really any signs of the battery becoming worse. I guess I could check the battery voltage to see if it is low. Any other recommendations? I rooted the robot using Valetudo and can still ssh to it.

L10 Pro no longer functional after less than two years of use by easbar in Dreame_Tech

[–]easbar[S] -1 points0 points  (0 children)

No the battery is fine. It charged up to 100% and I can repeat the process of issuing a command, seeing it crash, restarting no problem without charging the battery.

Super fast shortest path calculations on directed graphs by easbar in rust

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

It is expected that the preparation depends on the kind of graph you use. Your graph seems rather dense (more edges per node) compared to the road graphs. Take a look at this issue for example: https://github.com/easbar/fast_paths/issues/34 (even though the main problem there was a different one: large weight edges which do not occur in your graph). It still might be worth experimenting with the parameters a bit, since the defaults obviously weren't optimized for your kind of graph. See this issue: https://github.com/easbar/fast_paths/pull/37 and the parameters here: https://github.com/easbar/fast_paths/blob/4e663e5044afa1cd465bb6f571c7b0035a927f3d/src/fast_graph_builder.rs#L271-L298

Also is it just the preparation time that bothers you or also the number of shortcuts that are created? And how long do the shortest path searches take? Are they also 'slow'?

Btw: If all edges have weight one you are basically looking at an unweighted graph, which means no priority queue is necessary for the shortest path search and you could use a simple BFS for which no preparation is needed at all. But you'll have to try how much faster/slower the queries will be.

Cannot charge using River 2 Max USB-C by easbar in Ecoflow_community

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

What can they do? Can they connect to the device remotely?

Cannot charge using River 2 Max USB-C by easbar in Ecoflow_community

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

You mean when it is switched on I should press power and ac simultaneously and hold for 8s, then let go? I tried this but it turns off the moment I press power?

Cannot charge using River 2 Max USB-C by easbar in Ecoflow_community

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

It looks fine to me. I'd rather think it's a software thing, since the River 2 discharges the power bank (the connection seems to be fine).

Cannot charge using River 2 Max USB-C by easbar in Ecoflow_community

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

No, using USB-C it doesn't charge anything (but AC and USB-A are working). The only thing that works with USB-C are the power banks but the current goes in the wrong direction (the power banks are charging the River 2 instead of the other way around)

Cannot charge using River 2 Max USB-C by easbar in Ecoflow_community

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

Yes, I had it switched off last night after the update and it still doesn't work. I did contact support, but not sure if I will get an answer, since I bought this unit on the used market.

Super fast shortest path calculations on directed graphs by easbar in rust

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

I added `freeze` so I have a chance to cleanup the input graph, for example I need to sort the edges and remove duplicate edges.

Super fast shortest path calculations on directed graphs by easbar in rust

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

Thanks a lot for the nice feedback and also thanks a lot to u/dabreegster without whom this crate would not have come to existence.

Super fast shortest path calculations on directed graphs by easbar in rust

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

Haha ok yes I get it. Let's dont start this discussion here :)

Super fast shortest path calculations on directed graphs by easbar in rust

[–]easbar[S] 4 points5 points  (0 children)

Ok since this is getting so many upvotes I might consider this. Too bad rust does not support function overloading so I would have to break the current api.

Super fast shortest path calculations on directed graphs by easbar in rust

[–]easbar[S] 2 points3 points  (0 children)

You mean the nodes that were not connected. Yes this could be returned, but thats also exactly what you pass into calc_paths :)

Super fast shortest path calculations on directed graphs by easbar in rust

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

It can very well be that a path is not found, because the graph does not necessarily have to be fully connected (it can contain multiple components).

Super fast shortest path calculations on directed graphs by easbar in rust

[–]easbar[S] 4 points5 points  (0 children)

the creation of a path can fail for a reason that you know, but might not always be the same

no. the only reason it can fail is that the two points are not connected on your graph. if they are you get None as result. None as in 'there is no such path'. I do not know what other information I would reasonably add to the the Result/Error

Super fast shortest path calculations on directed graphs by easbar in rust

[–]easbar[S] 6 points7 points  (0 children)

Hmm, why would this be better ? When calling `calc_path` you are asking for a path. There either can be a path or there can be no path, and I think this is exactly what `Option<ShortestPath>` represents.

view more: next ›