generated from leka/template-repository
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sensors - LSM6DSOX - MLC & Mbed Integration #16
Merged
ladislas
merged 24 commits into
master
from
samuel-Sensors-LSM6DSOX-MLC_Mbed_Integration
Nov 23, 2020
Merged
Sensors - LSM6DSOX - MLC & Mbed Integration #16
ladislas
merged 24 commits into
master
from
samuel-Sensors-LSM6DSOX-MLC_Mbed_Integration
Nov 23, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
….h file (examples from ST). Based only on lsm6dsox_reg.h(st driver for LSM6DSOX) and example from yann-Sensors-LSM6DSOX-SOLID_Application (no BSP as far as we know)
…respect SOLID principles. So far, MachineLearningCoreBase.h, LSM6DSOX_MachineLearningCore.h and .cpp have been created and are in the process of being completed (we used the accelerometer example to shape our code)
… been set. However, we are considering the idea of creating a global LSM6DSOX class in order to interface the two sensors and the MLC, this would help for interrupt handling and to make sure the sensors have appropriate data rates compared to the MLC (there is a constraint, xl and gy DR have to be superior to MLC DR).
…have been found, first INT1 can't be configured as interrupt before disabling I3C, this is a problem since we are able to disable I3C only after having created the class (thus configuring _lsm6dsox_interrupt member). On another hand, despite having done the right configuration, INT2 pin does not change value (but the mlc1 source does) we still don't know if we are missing a register or if there's something else.
- INT1 is apparently working, we solved the I3C startup problem with a DigitalInOut on the A5 pin. Once the sensor has booted and I3C has been disabled, the pin can be set as input to allow interrupts - INT2 still not working, we probably missed a configuration register, will check the documentation. - Code has been cleaned up a little bit, we will do a Doxygen documentation soon because it isn't up to date - Also removed BUILD/ folder as it has no reason to be on distant repository
Found a way to make INT2 work, it was routed on INT1 due to the UCF file config. We have had some trouble finding out how the configuration registers act on reboot, sometimes they change values and sometimes they keep the same. We are also facing a problem where the interrupt will be latched on the sensor, but the board won't get the notification, thus not reading nor clearing the interrupt. We also worked on our LSM6DSOX documentation. We will try to complete the document with what we learn about the sensor and its MLC in particular. The structure isn't totally defined for now, we just tried to make it somehow readable.
… cleaning. We commented most of the MachineLearningCore class methods with doxygen friendly syntax. Started checking event queues and implementation of event handling, but no modifications to the code have been done yet. Discovered that the MLC looses its trees upon power loss. We didn't know that and will need to consider adding the setup process somewhere in the init of the MLC. We also reconfigured the MLC to use INT1 as it will eventually be the only pin available for interrupts.
A new folder has been added with the base of an app for data gathering The goal of this app is to allow us to generate data sets for specific movements in order to use them to train the MLC The idea would be to setup the app via serial from the PC, and then have a command to trigger the data collection We still aren't sure if data should be sent as it is measured or on one big log at the end. Have been struggling with serial and interrupts for the moment.
Interrupts did not work so we went for a polling method in order to make progress on the other functionnalities We added a "basic" commands system that allow to change the configuration of the data logging via the serial terminal These commands could be formalized if the app was interfaced with some computer app, but for now we are dealing with user input, so it has to be easy to use and failproof. added a todo.md file used as a to-do list.
Added the functionnality to send the collected sensor data directly in binary format which allows us to make the process quicker and to avoid printf() The information sent by the data logging app can be saved to a file by using a pipe command such as : $ mbed sterm | tee file.bin
Two new applications to manage .ucf files UCF_to_H_File_Conversion allows to take a .ucf and transform it into a working header file to insert in an mbed project in order to set up the MLC UCF_Analysis aims to help us understand how the UCF works, we are using the register maps from the documentation to automatically comment the file. The idea is to make the file much easier to read and to understand in order to pintpoint what can be understood with the given documentation and what is total mystery.
All work today was made on Mbed_Integration folder Cleaned up the code, most calls to the driver have been wrapped in a class method. Completed readme.md with basic info on the project and how everything works Added doxygen comments to all remaining methods
We have been transforming the Data Gathering application in a class that handles all of it functionnalities in an easier way to set up The idea was also to avoid using printf because it can be laggy and to allow communication over another serial port A ticker is being implemented to print the data to serial at a given rate. We are still having trouble with the callback configuration.
We have been trying to fix the calls to the DataGatherer callbacks "onSerial" and "onTick" We implemented the queueing of the callbacks on the mbed event queue and we have increased the baud rate of the application. So far everything seems to work if the data is sent in binary format. We will try to update the data from the sensors via interrupt on the data_ready signal in order to lighten the printData method.
Added options to select inpu and output files Added a help message Added an overwrite option, it overwrites the output file without warning Updated readme Documented code in a doxygen friendly manner Created a makefile in order to be able to compile and launch executable from console. the todo.md file will be deleted on the final commit at the end of the week
We have been updating an debugging the project MachineLearningCoreBase has been deleted as it had very little use and would have probably been replaced anyways Doxygen documentation has been checked and updated on most of the project files readme has been updated with a step by step of how to configure MLC mlc_info has been checked and updated too setup_linux.md is a step by step on how to configure ubuntu in order to collaborate on leka projects. It will be moved to another folder eventually. added todo.md with missing steps
include files have been updated to correspond to whats is being used on mbed_integration folder todo.md has been update with missing steps
This project will be used to test how the LSM6DSOX embedded features work It is just a bare project for now, but some things should appear before the end of the week
We started working on the documentation for the embedded features ( activity, free fall, wake up, tilt , single/double tap, etc.). We gathered all the informations we could in the todo.md file for now and will be moving them when it's completed. The informations for now are mainly about the registers and bits impacting those embedded features. On the features detection implementation we are still in the early stages and are still trying to figure out how to cleanly detect the features without interfering with others.
We have been working all day on the embedded features tests. A lot of parameters are interconnected and registers are used for multiple things, thus making the overall understanding quite difficult. So far we have been able to test - free fall - wake up - sleep - motion/stationary - 6D orientation they seem to work fine, but oftentimes one config register corresponds to multiple features So we are trying to clarify all the links in order to avoid modifying behaviour without being aware of that.
All features where tested, some still don't work as expected Readme has been written and completed with the documentation about the features The code allows to test them one by one and gives a general idea of how they need to be configured
Both readme.md have been updated and checked The data gathering app was given one last test. Moved the linux setup markdown to the main folder, we don't really know where to put it but thought it could be usefull
Updated the readme of both folders with small explanations removed unnecessary files added some documentation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
implementation of #12