Skip to content

Adding the example for the sensor based data collection and running on a riscv device - #250

Open
shrit wants to merge 52 commits into
mlpack:masterfrom
shrit:mpu
Open

shrit wants to merge 52 commits into
mlpack:masterfrom
shrit:mpu

Conversation

@shrit

@shrit shrit commented Jun 28, 2026

Copy link
Copy Markdown
Member

No description provided.

shrit added 8 commits June 20, 2026 15:27
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
@github-actions

Copy link
Copy Markdown

Binder 👈 Launch a binder notebook on branch shrit/examples/mpu

@rcurtin rcurtin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am really hesitant about this design. The amount of complexity in this code is huge: it contains its own I2C library specific to each of the sensors in the example, and I think if I understand right that it is basically written entirely by Claude?

(It also seems like the training and inference programs aren't here, but I assume you will push them soon.)

The question I have is: who is the target audience here? Nobody wants to read 3000 lines of hardware control code to understand it. How will someone approach the example? The other examples we have are all written so that someone can read through the entire source and know what is going on. But that's unrealistic here. Do you think we can go through and pare back the code a huge amount? It's an example, not an enterprise application, so all of the "fancy" stuff like short-option and long-option parsing are just unnecessary, in my opinion.

There is a huge amount of other error checking and support code that's also probably unnecessary (at least that is what I have seen with lots of other Claude-generated code). When there is too much code, even if it really is checking for every possible case, a reader will never make it through the whole file and learn what we want them to learn (i.e. how to use mlpack). In my eyes that makes it sort of defeat the purpose of the tutorial.

@@ -0,0 +1,725 @@
# - Find mlpack

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will we keep this file up to date? There are now copies of mlpack.cmake floating all over the place, but the upstream one in mlpack updates from time to time.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a very good question, that I do not have the answer for it, maybe using the CI ? github actions that can check every new PR ?

shrit and others added 20 commits July 13, 2026 19:55
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
… inference as well

Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@avontech.fr>
Signed-off-by: Omar Shrit <omar@shrit.me>
… quickly

Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Comment thread cpp/movement_recognition/CMakeLists.txt Resolved
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
Signed-off-by: Omar Shrit <omar@shrit.me>
@shrit

shrit commented Oct 15, 2026

Copy link
Copy Markdown
Member Author

@rcurtin I think this one is ready and it should be easier to review, I have also tested the code for the three program in addition to the IMU testing one and they all looks good, feel free to give it a review when you have a chance

…hardware

Signed-off-by: Omar Shrit <omar@shrit.me>

@rcurtin rcurtin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know I have a lot of comments, but I hope they are useful. I really had to work hard to not comment on every awful verb choice by Claude; Claude really likes to personify programs in ways that are inappropriate and obscure the technical meaning of what's actually going on. But... below driver/ I really tried to not care, since users won't really be reading there and will focus on train.cpp/infer.cpp/collect.cpp and the CMake configuration.


CXX := g++
CXXFLAGS += -std=c++17 -Wall -Wextra -O3 -DNDEBUG -fopenmp
CXXFLAGS += -std=c++17 -Wall -Wextra -DMLPACK_ENABLE_HTTPLIB -O3 -DNDEBUG -fopenmp

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After https://github.com/mlpack/mlpack/pull/4201/changes is merged, then httplib is enabled by default, so I think we can remove this from here and other Makefiles?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct

Comment thread cpp/movement_recognition/README.md Resolved
# -DOPENBLAS_PATCHES=../CMake/patches/openblas-riscv64-low-memory.patch ..
# make
#
# Build a single program with, e.g., `make collect` or `make train`.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be useful to give a URL to the tutorial here too, in case this is the first place a user looks. Up to you.

* mlpack is free software; you may redistribute it and/or modify it under the
* terms of the 3-clause BSD license. You should have received a copy of the
* 3-clause BSD license along with mlpack. If not, see
* http://www.opensource.org/licenses/BSD-3-Clause for more information.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tutorial no longer discusses this, so I think it would be okay to either remove or simplify it (or I mean if you want to keep it as-is that's fine too). Since the example doesn't actually use the magnetometer, maybe all the calibration code is unneeded. But I haven't checked in-depth.


IMU::IMU(const I2CBus& bus, uint8_t gyroAddress, uint8_t accelMagAddress) :
gyro(bus, gyroAddress),
accelMag(bus, accelMagAddress),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the calibration of the magnetometer? If the code no longer uses calibration at all, then we should remove mag_calibration.hpp and all references to it (including in imu_test.cpp).

{
next += period;
std::this_thread::sleep_until(next);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a really unhelpful utility function here. If this file gets kept this should definitely be inlined.

static constexpr uint8_t kWhoAmIValue = 0xD7;
//! Some clone GY-89 boards carry the older L3GD20 (non-H), which is
//! register-compatible but reports this WHO_AM_I instead.
static constexpr uint8_t kWhoAmIValueL3GD20 = 0xD4;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Hungarian notation kVariableName is a bit weird to me because it isn't used anywhere else. But this is a minor comment (because this code is very deep in the sensor controller code).

@rcurtin rcurtin left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know I have a lot of comments, but I hope they are useful. I really had to work hard to not comment on every awful verb choice by Claude; Claude really likes to personify programs in ways that are inappropriate and obscure the technical meaning of what's actually going on. But... below driver/ I really tried to not care, since users won't really be reading there and will focus on train.cpp/infer.cpp/collect.cpp and the CMake configuration.

shrit and others added 8 commits November 8, 2026 16:30
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Co-authored-by: Ryan Curtin <ryan@ratml.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants