betzdrive / bldc-controller Goto Github PK

Hi!

While playing with the RS485 interface I noticed that the boards take a long time to recover from a failed transaction and narrowed down the issue to the idle timeout of the comms module.
Specifically, the way I test is that I continuously send a register read instruction (read accelerometer), at "some point" (approximately once every 10k messages) there will be no reply from the board, maybe because of misinterpreted data.
At this point, if I don't wait at least 10 ms idle the board will stop replying any following request.

Since the baud rate is 1Mbps and it takes less than 10us to send a character, I would suggest shortening the timeout to make latency critical tasks (i.e. control loops) less sensitive to failed transactions.
I guess 1 ms (equivalent to ~100 characters) would still work OK, but I'm sure you have more experience in the area.

In alternative, maybe it would be possible to debug which state the board gets stuck in, and make it go back to idle but I don't have the tools to know exactly which state it gets stuck at and to get more information that would help in debugging.

Ideas?

Cheers!
/Luca

To get started with unit testing sections of the code-base, I thought we should first pick a reasonable framework. Looking at the list on wikipedia, I found https://github.com/Snaipe/Criterion to check the most boxes and it looks pretty nice from a first glance! Thoughts? @brentyi @wuphilipp @luca-della-vedova

Hi guys,

Might be worth it to discuss and choose the License for this project, especially for people who are interested in customizing the controller for their own application?

Cheers!
/Luca

This should follow #37 to minimize code movement but it is not necessary. The intent is to make a CLI with sub-commands (like git). This should be possible with argparse as shown here: https://chase-seibert.github.io/blog/2014/03/21/python-multilevel-argparse.html

The goal is to remove all of the current scripts and instead make them sub-commands of bd-tools (or a different name if someone can think of something better).

I'm thinking the commands will essentially retain their current format so these should be familiar:

bd-tools upload_firmware <serial_device> <board_id(s)> <path_to_bin_file>
bd-tools read_sensor <serial_device> <board_id(s)> <sensor_name>
bd-tools control_motor <serial_device<board_id(s)> <control_type> <actuation_values>

These are obviously just a few examples and I think the recorder directory may be a bit tricky to consolidate (it would make sense to do something similar to #37 but for the recorders).

bd-tools recorder <type> <actuation> <log_file_path>
bd-tools recorder plot <log_file_path>

I'd recommend taking this bit by bit instead of all at once. Maybe one or two scripts per PR.

There are currently a lot of different scripts in tools/ that interact with the same base board functions (the ones found in boards.py). The goal of this PR is to take the special behavior found in each one of these scripts and instead of being disparate, making them a part of a BoardManager class which will be a convenient front-end for python scripts to init boards, read sensors, update bootloader/firmware, drive the motors, etc. The only thing that will be left afterwards is a bunch of scripts which feed the outputs of argparse into the boards class (and maybe do some looping).

I've been running into the issue that setting up compiled C++ tests with the current makefile scheme is rather painful. As such, I think it's reasonable to switch to a more flexible and powerful build system such as cmake or bazel. I'm going to lean towards bazel as it has a dependency tree that allows building targets on x86/arm pretty easily. My main concern about bazel is the lack of native support for map files. I do see what looks like a way to hack around this at the bottom of this thread: https://groups.google.com/g/bazel-discuss/c/A00d7Ui1f8s

I'll open up a bazel branch to begin fiddling with this.

@brentyi suggested using a tool called black here: #39 (comment)

Currently, the calibration data structure is stored in the struct's byte form. This works fine as long as the data structure does not change. This is a problem as there will be more variables as the controller's functionality increases. To remedy this, protobufs may be a used as they can be grown and maintain backwards compatibility as long as field numbers are not re-used.

Steps to complete:

• Add protobuf build support
• Write https://github.com/BetzDrive/bldc-controller/blob/master/firmware/include/state.h into protobufs
• Adapt storing/loading of calibration in https://github.com/BetzDrive/bldc-controller/blob/master/firmware/src/state.cpp
• Adjust all calibration/state/parameter accesses (shouldn't really change as these are already dot accesses).

Testing/Verification:

• Unit test to verify loading of parameters (mock loading/storing from EEPROM).

https://github.com/brentyi/bldc-controller/blob/master/firmware/Makefile#L71

can we move the chibios source files into this repo (like the vesc one)? is that bad practice?

Continuing off of BetzDrive/bldc-controller-hardware#9

Not sure exactly what is causing it but communication error rates are significantly higher after commit 6323cb5.

I'll be investigating this but would also appreciate any input you have @luca-della-vedova. I'll likely revert changes on a branch for now so there's a non-bugged set of code.

IMO something has been off with the fact that communication performance decays significantly with less frequent scheduling and/or random changes to the firmware. To my knowledge, there's a UART peripheral on-board that should be buffering data to be processed. When a byte or bytes are ready, we process that data. It seems as if we start missing data when our chip is busier which makes me think somehow we're polling for data instead of being something in the background? I'll need to investigate as this is prior work and I'm not super familiar with the details of how ChibiOS implements UART for the STM32.