Flow Battery Research Collective

Yes, I would like to use either Codeberg/Woodpecker CI or Forgejo Actions - I did not try the second one, so I am not sure yet

Thanks for the examples, I will look at these!

Okay, I have not fully understood this idea yet

So as of now it seems that NEMAs' are overkill due to higher costs, as we do not need precise steering (I thought that it would be nice).

In this case if we agree with the lower power of BLDC imho it seems to be a good way to go - they are pretty cheap, there are few already integrated in valid pumps, and we remain on low voltage DC, which is safer.

We need something robust and capable of continuous duty,

Steppers should be okay with that, they might lose some steps, but in our case it should not be a problem at all. Of course for prototyping, in general you are right BLDC will be way better (mostly due to costs), and in final, big version 3 phase, inverter driven engines will be probably the best. Nevertheless I think the medium prototype should use safe voltage, so everybody can transport and work on it without risk

Also in case of knowing exact RPMs - closed loop based on objective function [AC DC power to pumps - abs(DC power in/out of battery)] with BLDC can be used as well? Moreover RPM knowledge gives a opportunity to detect for example stall of the pump, or other pump-related issues faster? Idk what will happen to the battery if one of pumps fails.

Okay so for CAD, I created a simple tutorial, mostly for myself, as I wanna go to sleep soon, and might forget what to do This might be not optimal, or obsolete, I did not find another FreeCAD's docker image

EDIT: I have found a newer FreeCAD image, though it cointain GUI as well, thus works really weird without X server

1. Pull FreeCAD's docker image (maybe we would need to create an new FreeCAD's image, as this one seems to be pretty old FreeCAD wiki

2. run it in CAD folder:

docker run --rm -it -v ${PWD}:/home/CAD  amrit3701/freecad-cli:latest python3.8

3. Now we are in docker's image Python interpreter

Let's assume that we do have this tree as I mentioned in previous post:

We are choosing first one from 3D_printed folder (ofc in the future we would iterate over files in given directory)

>>> doc = FreeCAD.open(os.path.join("3D_printed", os.listdir("3D_printed")[0]))

We find body object which (I hope) will be on 1st place:

>>> doc.findObjects()[0].Shape.exportStep(f'{doc.Name}.step')

Voila! We do have our STEP file

Okay, so we would have 3 main things to do in our CI:

1. Generate STEP files from FreeCAD
2. Generate PDF files from KiCad
3. Unittest (in the future) and generate binary/hex file

As from my point of view all of three sections should be separated in different repos and combined using git submodules, though there are few problems I see, mostly in CAD:

1. CI/CD must know from which input files generate output files - as for now they are kind of mixed in main CAD folder, so my proposition is to create separate folder for:
   1.1 3D_printed parts, as these need to be converted from *.FCStd into *.step
   1.2. 2D drawings parts, like Current Collector Drawing or Gasket Drawings which needs to be translated from *.FCStd into *.pdf
   1.3. Renders which would require rendering whole assemblies - those could be placed in Assembly folder

We would end up with structure of:

.
├── 2D_drawings
├── 3D_print
└── Assembly

2. Electronics is pretty simple, as there will be only KiCAD project, maybe the some kind of electronical/electrical calculations, though I think we are far from it now

3. Similar with Firmware, there would be simply two folders: src and tests, but that is also a next step

I would love to hear other opinions, my idea is to create CI/CD as simple as possible, due to fact that I understand that many ppl who would like to contribute with CAD files might be not familiar with any CI/CD, and for that I came up with that folder idea

@kirk from my point of view controlling the speed of this particular motor would be rather hard. I am not big expert on motors, so I would need to consult it.

Nevertheless I would ask a question: how much power and what RPM we really need in that project - Using 3phase AC motors is of course an option, but it is probably an overkill, maybe we can easily use even steppers like NEMA23, which are quite cheap, and we can really precisely control the speed

The NEMA was used for example in Recyclebot:
https://www.appropedia.org/Recyclebot
And there is an Arduino code:
https://codeberg.org/309631/recyclebotV6.2

With NEMA we do not need much power, as well as we do not need AC, which is still quite dangerous, tho I am not sure about the scale of future version, as well as we would need pump body for it, though in this case maybe in automotive we can find something? AFAIR for example BMW used pump from Polyphenyl Sulfphide, thus maybe we could go this way?

So from my point of view it would be nice to tinker unittests based set-up and later on base on these tests to write more "hardened" firmware. I am kind of afraid of building the flow battery myself, I find this idea very nice, though with the most common thing with chemistry and myself is I drank alcohol 3 years ago lmao

But according to #16 I will first of all take a look on submodules and later on CI/CD, as it seems to be most important job here

btw

I know a lot of projects use Discord, but I really don't like it personally and ofc would prefer something nonproprietary. I'm up to try Matrix.

I love that one

Idk if it is the best place to post, tho I did not want to do this in Codeberg, as to avoid unecessary text in development process

So I would love to contribute into FBRC, I can help you with electronics, as well as firmware development, especially if you would like to develop more standalone device, in C/C++ or Rust (preferable, it just safer :P). I can also help to define/write unittests for the firmware

Also my proposition is to create a [matrix] room to create a instant messaging possibility