Cannot build rust crate for `no_std`
Brought to you by:
mistevens
Hello!
Firstly, thanks for providing this library! I intend to use it on an embedded platform and am trying to build your crate in a no_std
environment, which should work, but doesn't.
The nalgebra
dependency pulls in std
, because it is not included with default-features = false
, so the build fails.
Best regards
This builds fine in a
no_std
environment.I also noticed a build warning
It would need to be gated behind the
std
feature as wellLast edit: Adrian Figueroa 2025-03-26
I've tried this out. Problem is that the tests require std from nalgebra
To make that work I need:
Seems rather clumsy! As the version has to be specified again. Any ideas how to do this better?
Unfortunately not. I think there is no official way to solve this problem: https://github.com/rust-lang/cargo/issues/2911
By extension, I wanted to use the
unscented_duplex
module, so I made it rely onalloc
instead ofstd
. Here is the full diff. Sorry for the formatting noise, this is fromcargo fmt
.Thanks for the feedback. I think unscented_duplex should not really use Vec. Better would be to use a nalgebra Matrix which doesn't need alloc if a fixed size is used.
Last edit: Michael Stevens 2025-04-02
Please note my unscented_duplex is based on the original paper by Julier and Uhlmann. There are more recent variant which chose the sigma points differently which may be better.
I see. We had previously used Van der Merwe's method. I will try to contribute such a sigma point generation, as it seems like it would be easily doable.
Yes, but I don't think there is a better choice at the moment. As far as I know, rust doesn't yet support calculations with
const
generics, such as[2 * N + 1]
for array sizes, whereN
is aconst
genericusize
. If a user knew how to calculate the required generic size, then that length could be passed directly, but I don't find that very user friendly.Otherwise, this problem could be fixed using a
heapless::Vec
with some upper limit in length. For now,alloc::Vec
is probably the safest choice.Hi Adrian,
I had a look last week into using a nalgebra::Matrix for the Sigma point. I now know why I originally chose to use a std::Vec of nalgebra::Matrix to do this! I think in principle it is possible using the DimSum (with DimAdd) as type constraint. But the whole type signature becomes totally unwieldy. I will scrub that idea and use alloc::Vec so it is buildable with 'no_std'.
Hi Adrain,
The implementation you used follows that in the paper
https://groups.seas.harvard.edu/courses/cs281/papers/unscented.pdf ?
It would be good if we could get that or similar into the library.
Michael
I've pushed version 0.18.1. Since I was only using Vec from std I have changed the library to be completely 'no_std'. There is no 'std' feature anymore making things much simpler.
I have removed the old 'unscented_duplex' and replaced it with 'unscented'. This has a more modern parameterisation of the 'sigma' point weights.
I've implemented 'unscented_root'. I have marked it as experimental.
Great, thanks for your efforts!
I wonder, what method is now used for sigma point generation? Is it still the same? The module docstring appears to be out of data, since it still mentions
kappa
, although it doesn't exist as a parameter anymore.Looks like you moved to Van der Merwe's method already, correct? So
kappa
is always zero if I read your equations correctly.Last edit: Adrian Figueroa 2025-04-30
Opps, the module docstring was not updated. Sigma point parametrisation are identical to the SRUF in Van der Merwe paper. Effectively kappa is replaced by alpha and beta.
I have pushed a corrected docstring in "main", thanks.
There are various preprint and papers from Simon Julier titled "The scaled unscented transform" that introduce and analyse the alpha and beta parametrisation for choosing sigma points.
Thanks! We now get vastly different/incorrect output in the
observe
step of theunscented
estimator usingalpha = 0.1
andbeta = 2.0
as opposed to the old implementation. Is there something else to be aware of?Last edit: Adrian Figueroa 2025-05-02
Annoying. The new implementation should follow that in the Merwe and Wan paper. I test with alpha =1 which is at the opposite extreme from alpha = 0.1. In the paper there mention alpha = 0.001 Looks like I need to do more testing. The only other implementation I found is in Python again changes the parametersation and reintroduces a kappa. I can find no publication mention or any mathematical justification so I have avoided that.
Maybe just copy the old unscented_duplex from older releases back into the source code. Should work fine if you 'use alloc::vec::Vec;'. If you need a crates release with it back in I can do that.
Michael
Yes, I can use a fork that I modified already, no problem.
Can I somehow help with testing the unscented approach? By the way, the output of the predict step didn't change much with the new implementation, only observe.
Last edit: Adrian Figueroa 2025-05-05
I've retested. 'simple_unscented' with alpha 1e-3 give identical results as alpha 1, which is to be expected as the 'simple' test is linear. 'rtheta_unscented' with alpha 1e-3 changes a little but looks reasonable.
Since you are only having a problem in observe I wonder if the problem is related to the size of the observation vector. The test I have it only a two dimensional observation. What are the dimensions of your models. Is the observation function discontinues?
Interestingly the earlier Wan & Merwe paper 'The Unscented KalmanFilter for Nonlinear Estimation' has a 'kappa' in the formulation of weights. It has a completely different definition to that in the original Julier & Uhlman paper. They simply state 'kappa is a secondary scaling parameter which is usually set to 0'!