An engineering assistant starts somewhere
The long-term idea for JARVIS is an engineering assistant with a brain, a voice and eventually a physical body. There is plenty to figure out before getting there. This first build log sets out where I want to begin: the calculations underneath it all.
As an electrical engineer, I want this project to connect with problems I recognise. Reliability tools feel like a useful starting point. They give me a reason to learn Python while thinking carefully about what a result actually means.
Keeping the first step small
The initial focus is on reliability calculations such as mean time between failures (MTBF), mean time to repair (MTTR) and availability. OEE is also on the wider project roadmap, but I want to work through one clearly defined calculation at a time.
For each tool, I want to be able to explain the inputs, the assumptions and the answer. A number on its own is not much help if I cannot tell which time period it covers or which units went into it.
- Define the question the calculation is meant to answer.
- Give every input a clear name and unit.
- Show the assumptions alongside the result.
- Keep a simple worked example that I can check by hand.
Workbench note: what belongs in a worked example?
I want each example to record the question, the time period, the input values and their units, followed by the expected result and the assumptions used. That gives me something concrete to compare with the Python output later.
How I want to check the work
Before building a polished interface, I want a small collection of examples with expected answers. Those examples should cover an ordinary case as well as awkward inputs: missing values, negative durations and situations where there is not enough information to calculate a meaningful result.
The goal is to make the behaviour understandable. If an input does not make sense, the tool should explain what needs attention. If an answer depends on an assumption, that assumption should be visible.
Workbench note: the awkward cases I want to try
My starting checklist includes a missing input, a negative duration, mixed time units and a case where the calculation would divide by zero. These are planned checks, not completed test results. I want to decide what a useful explanation looks like for each case before expanding the tool.
Where things stand
This entry records the starting scope and the approach I want to take. It is not a release announcement or a set of test results. I will add concrete examples, screenshots and lessons as the work develops.
Voice interaction and a robotic body remain later ambitions. For this part of the journey, the interesting challenge is much smaller: turning an engineering question into a tool whose answer I can explain.
Next on the workbench
The next step is to choose the first calculation, write down exactly what its inputs mean and prepare a worked example. From there, I can build a small Python version and compare its output with the expected answer.
- Choose and define the first calculation.
- Prepare an example with explicit units and assumptions.
- Build the smallest useful Python implementation.
- Record what worked, what failed and what needs another look.
One calculation at a time. Back to the workbench.