What are we working on? (Waterfall 🌊 Thread)

tid · Septembre 16, 2020, 11:31

Et voilà la bonne raison pour rester open source:

antoine.selosse · Septembre 16, 2020, 6:55

C’est bien dommage ces changements, notamment la perte de la simulation

martino.ferrari · Novembre 3, 2020, 9:32

Hi everyone,

My name is Martino and I just joined the project.
I am a computer engineer from Italy, currently living in Toulouse (FR), I am specialized in signal and image processing as well as control systems, I have worked at CERN for 4 year managing software for the control of the particle accelerators and now I am working at a sub-contractor company for ESA developing an image processing toolbox.
In my free time I am passionate of FOSS, electronics, robotics and of course space exploration!
I hope to share my knowledge and ideas for the project

Cheers!

tid · Novembre 3, 2020, 8:20

Hello Martino,

it’s a great pleasure to have you here, and we are very happy that our project is of your interest. We would really make a great use of your profile in the eve project . Whenever you’re ready, you can join our Telegram group such that we can arrange an informal meeting with the other members and get you easily on board!

luca.litterio · Novembre 8, 2020, 5:37

Welcome Martino! Nice to meet you

bruce · Janvier 21, 2021, 12:13

Hi everyone,

I’m (very) new in the Federation and found the EVE project quite interesting , not to say challenging.

I’m a young IVV engineer wich has (unfortunately) left the Space world. So, i think that’s a great opportunity for me to get back into the Passion.

Eager to make my first participation and motivated to read down all the doc and work done before my arrival.

Let’s bring EVE to the Moon,

Bruce

tid · Janvier 21, 2021, 4:47

Hi Bruce, and welcome. Feel free to join the project and the Telegram group if you want to keep in touch with all the team!

laghter · Mai 2, 2021, 5:42

Hello everyone, I am very happy to announce that this summer I will be an intern at the Open Space Makers, working on Project EVE from May 1st to August 14, 2021. As part of the McGill Global Challenges Award and under the mentorship of Mr. Luca Litterio and Mr. Ruben Di Battista, my goal will be to design a suitable control system for Eve rocket engine. I am very excited to take part to this open source endeavor and I hope that I will contribute to its very first leap!

artemisplayer · Septembre 8, 2021, 6:31

Hello there, we are a group of six student from the École Polytechnique near Paris. We join the project during (at least) a year for a kind of school project because of various reasons (but mainly because we all love space). Our skills are not specific to space engineering (yet) but we hope that our skills in STEM fields will help the project skyrocketing.
Nathan Gasc for the EVE’s PSC.

laghter · Septembre 26, 2021, 6:05

Hello everyone.

The summer has ended, and so did my internship.

During this journey, I designed and assembled a control system for Eve.

At the end of my internship, the control system can control simultaneously 1 temperature sensor, 1 pressure sensor, 1 load sensor, 1 igniter, 2 ball valves and 3 solenoid valves. It can also send data wirelessly to a remote computer for safe data acquisition. That is enough to control our first prototypes of Eve.

I want to express my gratitude to the Open Space Makers for helping make this internship possible. I would also like to thank all of Team Eve for their continuous support throughout the summer. Special thanks to Mr. Ruben and Mr. Luca for their fruitful mentorship, and to Mr. Francesco and Mr. Ricardo for sharing with me their valuable experience.

There is still a lot of room for improvement, and I hope to continue working on the control system so that it can evolve along with Eve.

As I am now back to a regular member of Eve, I pass the beacon to Nathan, Francois, and their teammates, and I look forward to seeing their realizations!

tid · Octobre 3, 2021, 6:27

And here a blog post resuming the incredible work @laghter did!

luca.litterio · Décembre 14, 2019, 1:42

This discussion will focus on the Control System development for the Eve engine tests.

luca.litterio · Décembre 14, 2019, 2:05

In the following text you can find my proposal for the first Eve Control System microcontroller. The main driving points are:

easy and fast development of the system;
easy and affordable replacement of the components in case of failure.

Eve Control System

Two main systems:

Eve Control System
Eve Safety Control System

Summary

A microcontroller will command the test and record the data.
The Eve Control System activates the igniter and operates two motor valves (one per reactant feed line).
The Eve Control System records the following data: engine thrust, combustion chamber pressure, combustion chamber external wall temperature.
The Eve Control System aborts the test if the recorded values from the combustion chamber pressure and the combustion chamber wall temperature exceed a defined threshold.
The Eve Safety Control System controls two motor valves (one per reactant feed line) with an independent power supply and an abort command manually activated by the operator.

Requirements

Microcontroller

HiFive

It is suitable for a more advanced data acquisition system.

PROS

RISC-V open-source hardware instruction set architecture, a perfect match for the Eve open source engine.
Very good microcontroller;
Wifi.

CONS

New board: lack of extensive test, use and support. At the present time it is under crowdfunding. Expected delivery: December 2019.
Compatibility with external modules (libraries) is not guaranteed.
Limited number of Input/Output pins.

Arduino Due

It should be good for a simple data acquisition system.

PROS

Good microcontroller;
Large number of Input/Output pins;
Arduino IDE;
Large support community, libraries.

CONS

No Wi-Fi (external module needed).

Teensy 4.0

PROS

Very good microcontroller;
Arduino IDE with Teensy patch;
Large number of Input/Output pins;
Good support community.

CONS

New board: lack of extensive use and support.
At the present time there is not a breakout board reliable and ready to use. Internal pins are difficult to access.

Conclusion:

From my point of view (and my limited knowledge of the hardware/software):

Arduino Uno: it will be used to test all the “functions” of the Eve Control System. It is easy to use thanks to the Arduino IDE, with a large support community and relevant open source projects and tutorials.
Arduino Due: it will be the first control system board. All the functions will be assembled and tested together. It presents: a large number of Input/Output pins easily accessible; a strong support community and the Arduino IDE. The board utilises an ARM microcontroller, hence it will be easier in the future to utilise a more advanced board which is based on an ARM’s family microcontroller (e. g. utilising the Teensy 4.0).
“Teensy 4.0” or “HiFive1 rev b”: As a future development of the control system, one of these two boards will be probably taken into account. The Teensy 4.0 is a really powerful board and it will be easier to utilise on this ARM’s board the code running on the Arduino Due. The HiFive1 rev b can be a valid and innovative alternative to the ARM’s boards thanks to its RISC-V instruction set architecture, a perfect match for the Eve open source project.

Note:

There is also a Teensy 3.6 board available, with a 180MHz microcontroller. However, it presents the same issues with the internal pin connections, thus I prefer to concentrate my attention to the more powerful Teensy 4.0 when it will be more accessible in terms of Input/Output pins.
Future development: the Eve Safety Control System reads the visual output of the Control System computation activities, automatically shutting off the test (e.g. reading a blinking LED).
Future development: the engine test is controlled by 3 microcontrollers for redundancy.

luca.litterio · Décembre 14, 2019, 2:07

Feel free to comment and propose your point of view. We are open to suggestions

tid · Décembre 14, 2019, 4:02

To stay simple I guess we might go with the Arduino 2. It’s not incredibly powerful, but we won’t need fancy toolchains or deep knowlwedge of the working principles. I’m very fascinated by the HiFive because of its open ISA, but I guess that as a starting point the Arduino Due is a good choice:

We can probably find it in the fablabs
Lot’s of documentation
Community

the only thing that bothers me is to be sure that with that “slow” CPU, we’re able to cope with the transients we might encounter in our tests. You can maybe look for example of it being used as acquisition system?

PS: Try to limit acronyms, CC = Combustion Chamber. Many people could not be fond of them of they might not know them.

PPS: You can enter tables directly in Markdown:

A	B	C	D
1	2	3	4


| A | B | C | D |
|---|----|----|----|
| 1 | 2 | 3 | 4

or you can use this.

luca.litterio · Décembre 14, 2019, 5:10

Thank you, I am going to update the document in order to add a short legend for some acronyms and later I will avoid using them.

Here I found an interesting article were the Arduino Mega (similar results can be obtained with the Arduino Uno) has been tested as a data acquisition system.
https://sites.google.com/site/measuringstuff/the-arduino
The author has been able to capture one channel at 8000 samples per second.

As a matter of fact, considering the low sampling rate requirement (it has to be intended as a minimum threshold value), we should be able to integrate the complete control system in the Arduino Uno.
Nevertheless, I suggest to use the Arduino Due because:

the Input/Output pins run at 3.3v like for boards with better performance (HiFive1 rev b, Teensy 4.0);
it presents a large number of Input/Outputs;
it is faster than the Uno and it will help in the data writing to an SD card.

tid · Décembre 14, 2019, 5:29

I prefer insted, if possible, that you change the acronyms with their extended meaning. A level less of indirection is a minute more saved for improving the design

Ok for the Arduino Due!

luca.litterio · Décembre 14, 2019, 5:56

It is done for CC, ADC and TBD
(not for all the technical acronyms like UART, SPI etc…)
Thank you for pointing it out, you are right that without acronyms it should be easier to understand the text at the first sight.

tid · Décembre 14, 2019, 6:01

Technical acknowledged terms can stay as they are. Thanks for the effort ;).

gist.github.com

https://gist.github.com/klaaspieter/12cd68f54bb71a3940eae5cdd4ea1764

ASS.md

From time to time, Musk will send out an e-mail to the entire company to enforce a new policy or let them know about something that's bothering him. One of the more famous e-mails arrived in May 2010 with the subject line: Acronyms Seriously Suck:

> There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.
>
> That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary. If there is an existing acronym that cannot reasonably be justified, it should be eliminated, as I have requested in the past.
>
> For example, there should be not "HTS" [horizontal test stand] or "VTS" [vertical test stand] designations for test stands. Those are particularly dumb, as they contain unnecessary words. A "stand" at our test site is obviously a *test* stand. VTS-3 is four syllables compared with "Tripod", which is two, so the bloody acronym version actually takes longer to say than the name!
>
> The key test for an acronym is to ask whether it helps or hurts communication. An acronym that most engineers outside of SpaceX already know, such as GUI, is fine to use. It is also ok to make up a few acronyms/contractions every now and again, assuming I have approved them, e.g. MVac and M9 instead of Merlin 1C-Vacuum or Merlin 1C-Sea Level, but those need to be kept to a minimum.

luca.litterio · Décembre 15, 2019, 12:13

Life is characterized by symbols and actions.
We are really happy to announce that, as the first act and symbol of the Eve Control System, we pre-ordered the SiFive HiFive1 rev b board.
This board features the FE310-G002, the upgraded version of the first open source, commercially available RISC-V System-on-Chip.
The RISC-V is an open-source hardware instruction set architecture based on the Reduced Instruction Set Computer (RISC) principles.
A perfect match for the Eve open source engine.

We are eager to familiarize with this board, hoping to be able to implement it in the Eve Control System in the near future.