ISSUE-25: Implement thruster "Test Fire" from OBC

[kodsurf]

Implement code for performing "test fire" for thruster simulator hardware.

Sequence : 1) Version request for a thruster module during initialization, to verify that thruster subsystem is connected and ready

2) Set thrust and specific impulse to an value (example: 350microN, 3500s)

3) Set thruster mode to start firing sequence ( which initialize heating of reservoire)

4) Firing will occure when reservoire would be heated to sufficient temperature. Monitor the temperature while its heated up. Parse temperature and thruster status values out of register map.

5) With sufficient temperature thruster should change status to firing.

6) After fire for defined time - idle.

Plan is to implement it in layer_7_app. With start/stop/set/read value requests sent manually from command interface.

Note : 1)thruster replies "instantly" after request is sent** 2) Length of the reply message is constant and depend on type of the request. 3) There are no unique bytes which would indicate the beggining of reply message, however reply length is know. Reply is only sent upon request. Reply is sent "instantly" after request.**

Keeping "Notes" in mind - design RX buffer handling. For every specific request there should be corresponding function that proccesses the received buffer.

Example : Read version request is transmitted ---> expected RX buffer length is N bytes. ----> check validity of reply message with checksum ---> parse version number ----> compare with expected version to verify that correct hardware is connected.

Example 2: Set Thruster Mode request is transmitted ---> expected RX buffer length is N bytes. ----> check validity of reply message with checksum ---> Thruster should reply that mode is succesfully changed. Parse this information ----> return ok status

[RobertK66]

I think it’s a good idea to implement all this test commands in 'layer_7_app' for a beginning. What comes to my mind here is, that it maybe would be a good idea to separate all 'sequence timings' (if there are some) into a new 'Lx_thruster' module (where x is something between 3 and 7 😄 ) with this separation of concern:

• layer_7_app: all test commands with specific values and defaults, all responses to these commands translated to debug_interface 'events'
• l4_thrctrl: timings and status changes which have to be done automatically (e.g. wait for heating and go to 'fire' mode, ...)
• thr (existing file): low level Rx TX buffers and immediate reactions to RS485 answers from thruster.

@kodsurf: pls. indicate if you start with 'real work' on this issue by assigning yourself to this issue in github (available somewhere on the right side of the github web-interface) to all: My 'git culture' is: Nobody ever assign somebody else to a task. Everybody has to 'self assign'. This gives some basic commitment, that somebody already is 'in charge' on advancing the resolution of the issue. If you have reasons to stop your involvement then pls. ‘de-assign’ (and make a short comment about status and reasons)

[kodsurf]

Yes - I will work on that.

So I should make 'Lx_thruster' as a copy paste base from app_l7 and use it specifically for new thruster commands and logics in init and main loop to operate thruster ? And thr.c just handles RX TX communication. Ok this sounds cleaner way.

I have to define a variable that will store expected length of reply. And reset this variable with every next request I send. Have to think of something reliable way to assemble reply bytes in the correct order.

Timings - I remember we did some experiment with milisecond counter for HW test in FHWN Aerolab. Could we have a module that start "ticking" from initialization of the OBC ? (it would have been very useful to have time related functions !) Or is it too much computationally expensive to have interupt counter every millisecond ? If it is ok to have it - please remind me on how exactly did we do this counter ? Which code I should look through ?

[RobertK66]

we have this already see https://github.com/RobertK66/obc_1769_core/blob/develop/doc/m03_systime.md

[RobertK66]

for commands you can still use app_l7, no prob. I meant to introduce another #level# for your thruster specific timing and states (e.g. wait for temp and so on...) then you would have your code on 3 different layers: APP_L7: code for (test/debug) commanding only L4 (new): code for coarse timing and mode control L2/3 (existing thr.c?): Rs485 timings and timeouts if there is no answer from RS485....

but this is only a suggestion. Try whatever fits your own 'this looks clean and tidy now' feelings.....

[RobertK66]

and you are not 'assigned' yet. You should appear on the upper right screen as 'assignee' for this issue. Pls. click on 'assign yourself'

[kodsurf]

I made a skeleton function for Thruster Firing Sequence that seems working ok

Firing sequence is triggered by debug command "8 5000" where 5000 is ms duration of fire.

Begin and Stop timestamps correspond to what was expected.

[kodsurf]

Sometimes it gets into infinite loop situation where whole OBC stucks and needs reset.

Something wrong

[kodsurf]

I don't like previous approach that I attempted.

I think better way to do it is to create array of function pointers.

Let's call it "thruster_execution_sequence_stack"

Then we create set of basic function with arguments argc,argc. Asside to already existing functions for thruster request.

We assemble execution stack based on small functions.

Also we can make static array of all "public" functions. And create function sequence array that is assembled by user ! We can make push/pop/clear methods as debug UART command. !!

So that user can do from debug UART something like :

push {index in static function array} push {index in static function array}

Then in similar way push all argv to an array

And run execute_sequence() which is triggered also as command from debug

---

In the main loop of l4_thruster ,where all higher layer logics should be implemented - we execute function at array with index THR_EXE_INDEX which is a global variable

Every previous function in sequence should increase THR_EXE_INDEX once it is completed.

[kodsurf]

Since communication with ground is only around 3 times a week.

It is imposible to control space craft continuously .

During communication window - instructions to assemble the execution stack + conditions/ timings could be transmitted.

In this way it would be possible for example to transmit execution sequence to Space Craft which would be either executed on specific time step or when right conditions occured ( gps, attitude, battery power, etc)

"Conditions" are global variables that are monitored and updated

[kodsurf]

At the latest commit of current branch

I completed a prototype skeleton for stack sequence execution

[kodsurf]

I definetly need an advice here !

if waiting time between stages (stack actions) is to small. OBC can go into hard_failure() mode !!!!

This has to do with timings of multiple modules.

But in general my approach worked - stack sequence (including thruster requests) was executed as expected

[kodsurf]

@RobertK66 I definetly need your code review at this stage. (do verify that what I did is not completely stupid)

There is no need in thruster hw connected to test out sequence execution module. Therefore code should be runnable from your side

To trigger sequence execution use command 8 (which is 0,1,2 as only 3 test sequences programmed)

Sequeces are programmed in init of module

0-th argv of functions in sequence should be hardcoded to

I achieved that multiple seqeunces can run in paralel.

But problem is that sometimes 0-th sequence leads to hard failure infinite loop. I am strugling to understand why ! Pls review

[RobertK66]

ok, give me 2 days pls....

[kodsurf]

I violated my own rule of "not developing several different features into the same branch"

But either way I would need memory read and write to save thruster register data into the log files (later on).

Therefore I would leave those memory read write skeleton functions here. Tested, understood how they work .

https://github.com/RobertK66/obc_1769_core/commit/718d533c68cd97c78cf1cf5897284037d4052dfa

[RobertK66]

fixed with #59