You are browsing as a guest. Sign up (or log in) to start making projects!

3h 0m 47s logged

Devlog #2

Welcome to my another devlog!!

Today was all about the scheduler.

Yesterday I finished a greedy scheduler, but I wasn’t convinced it was the best option. So today I implemented an exact 0/1 Knapsack scheduler expecting it to perform much better.

After running benchmarks, it honestly wasn’t what I expected.

Most of the time both schedulers produced almost the same schedule.

For a while I thought I had implemented something incorrectly, so I kept checking the code and rerunning the benchmarks.

Turns out the implementation wasn’t the problem.

The greedy scheduler was already finding the optimal solution in most of the scenarios I generated.

The only noticeable differences appeared when resources became really limited.

That’s where I found something that bothered me.

During a simulated sensor failure, the Knapsack scheduler decided to stop localization because it increased the optimization score.

From a mathematical point of view, that decision was correct.

From a robotics point of view, it was terrible.

A robot shouldn’t sacrifice safety just because it saves a little more battery.

That’s when I stopped thinking about improving the algorithm itself and started thinking about what I was actually asking it to optimize.

Instead of using one objective function, I switched to a lexicographic approach.

Now scheduling decisions happen in this order:

  1. Safety
  2. Mission progress
  3. Energy
  4. Execution time

This means lower priorities can never override higher ones.

While changing the scheduler, I also realised I had been treating every module exactly the same.

That didn’t make much sense.

A battery monitor shouldn’t be treated the same way as an exploration module.

So I divided modules into three groups.

  • Mandatory
  • Safety Critical
  • Mission

Those groups are now used directly by the scheduler.

I also added a module dependency graph so relationships between modules can be represented instead of assuming every module is independent.

After finishing the scheduler changes, I spent quite a bit of time expanding the benchmarks.

I added more scenarios, an ablation framework, and graphs so I could compare different scheduling policies instead of relying on a few manual examples.

The result I cared about the most was the original failure case.

The previous scheduler reduced safety coverage during a sensor failure.

The new scheduler kept safety at 100%.

That was enough to convince me this direction makes more sense.

Progress today

  • Compared Greedy and Knapsack scheduling
  • Built benchmark scenarios
  • Implemented Lexicographic Scheduler
  • Added module categories
  • Added module dependency graph
  • Created ablation framework
  • Added benchmark visualizations
  • Wrote research experiment documentation

83 tests passing.

Today was a good day, I completed and learned so many things from different algorithms and how each behave differently from other in eveyr situation. And it was fun. Not anything cool yet but it felt like i achieved something here.

0
4

Comments 0

No comments yet. Be the first!