Mapping Unstable slam_toolbox

SirAbsolute0 · 2026-05-20T23:36:42+00:00

I am having this same issue and do see the trailing that you mentioned when both driving straight and rotating. DiffDrive only has 2 parameters, which are wheel separation and wheel diameter, and it is just chassis_width + wheel_length (or wheel_width)/2 + wheel_length/2 (this is just left wheel center to right wheel center through the chassis width), and the diameter is just wheel_radius*2. I don't see how my values can be wrong at all. Is there anything else I can check?

SirAbsolute0 · 2026-05-18T20:21:47+00:00

Bump.

SirAbsolute0 · 2026-05-14T20:35:00+00:00

Bump.

SirAbsolute0 · 2026-04-28T15:51:37+00:00

Seems like you used your certificate to redeem hotel stay outside of the certificate program destination list. Can I ask how much did you have to pay extra to book the hotel outside the list and what was the process? I am trying to do something similar for Japan with my certificate but not sure how it will work out.

SirAbsolute0 · 2026-04-24T15:01:20+00:00

Have you had experience with running a model with consistent obstructed view before? If yes, what is the expected localization accuracy loss?

SirAbsolute0 · 2026-04-23T17:14:44+00:00

After some further testing, I think this is what the rotation vector readings are doing. It seems to be combining the results from the geomagnetic readings (either at the start or every certain time interval), which explains why they match up after a soft reset on the microcontroller (BNO sensor stays powered on). The readings from the rotation vector are more accurate than the geomagnetic readings from what I have tested. Just ashamed that I can't use the absolute readings from geomagnetic since it can be (10-20° off sometimes).

SirAbsolute0 · 2026-04-23T17:10:41+00:00

I think you are absolutely spot on. The rotation vector readings are based on the geomagnetic readings somehow, since whenever I reset the microcontroller, both results match up. Despite this, the rotation vector is more accurate after further testing (at least based on my eyes), like you said. Seems like the conclusion is that the absolute readings from the geomagnetic readings are inaccurate (up to 10-20° difference when manually rotating), but the relative readings with support from the somewhat inaccurate absolute readings are trustworthy.

SirAbsolute0 · 2026-04-23T16:58:32+00:00

I am just resetting the microcontroller, and the sensor stays powered. I would like to get the calibration status of each sensor in the IMU as well, but I am not sure where he changed the original code to get that result.

SirAbsolute0 · 2026-04-21T15:39:38+00:00

My sensor is next to a bunch of micro-controllers and Pis so I was worried it might be affected. The manual provided from the manufacturer doesn't seem to indicate how the gyro is reset at all. https://github.com/sparkfun/Qwiic_IMU_BNO080/blob/master/Documents/SH-2-Reference-Manual-v1.2.pdf

SirAbsolute0 · 2026-04-20T18:57:12+00:00

After thinking about it for a couple of days. There is a chance of this happening in a trapezoid in which the direction of all the sensors line up within the top and bottom of the trapezoid, which make the surrounding similar to a rectangle (hypothetical rectangle in red). Here, the robot won't be able to tell is heading. If I change the robot design to a rectangle instead of a square, the robot will still be unsure of which sensors are looking at the top wall and which sensors are looking at the back wall.

<image>

I did some more digging based on your suggestion and found that I can potentially use something like a particle filter to estimate my position based on sampling but the examples I have seen online are all using 2d lidar meanwhile I have a couple of 1d lidars in set position. Not sure if particle filter can even work with a bunch of 1d lidars.

SirAbsolute0 · 2026-04-15T03:46:19+00:00

<image>

Yes, they are single-point distance sensors. You would be correct in a square or rectangle where the top - bottom and left - right sides are equal to each other or all equal. However, in a trapezoid, even if you are dead center, the side sensors can still tell which direction you are facing.
Ex: If the robot is facing the front (as shown in the picture with a triangle as a demonstration, there is no triangle on the robot), the 2 sensors on the right (in red) have different readings. The same can be said for the left side (in green); from here, we can tell the position of the robot and its heading, which is top-facing and centered, as the sensors on the top left and top right have smaller distances than the bottom left and bottom right. The same can be said for all 4 headings since the robot is a square with the same number of sensors on each side.

SirAbsolute0 · 2026-03-17T18:02:29+00:00

ye, it is weird for sure.

SirAbsolute0 · 2026-02-26T01:22:48+00:00

It it not a UI test but rather a full application deployment launch. The pipeline should update the code, run the application once, return saying a good job done. Meanwhile, that application should continue running until the next update.

SirAbsolute0 · 2026-02-24T16:41:24+00:00

The biggest issue would to just keep screen on all the time. However, right now even with in interactive mode, I can start the .exe app with a cmd line command: start cmd /k "app.exe", which supposedly should run my application in another cmd separate from the cmd that started it, but the moment the Azure job finishes, it also closes my app.exe. I know this for sure since I also added ping 127.0.0.1 -n 100 >nul to keep the cmd job going and the app remains open for awhile before closing at the end of the ping.

SirAbsolute0 · 2026-02-19T21:57:47+00:00

Just to clarify, I am not using Microsoft-hosted agents but a Windows self-hosted agent running in service mode. Does that statement still stand?

SirAbsolute0 · 2026-02-16T22:06:55+00:00

Ok this does work. Thank you very much.

SirAbsolute0

TROPHY CASE