Keeping Up With the MicroBros – Week 9

Welcome to yet another humble blog post from the MicroBros ! This week we actually got a new 3D-printed frame from Richard . It lowers the width of the robot getting us even closer to be able to traverse the maze !

Jonathan

PERSONALLY IT’S BEEN THE WEEK OF MATH.

However, attempts have been made to apply the concepts of last week’s blog post into code

Specifically – adjusting the yaw orientation of the mouse to be perpendicular to a wall in front of it.

But it ain’t been free of hurdles!

Hurdle 1) Writing code that fits into the project’s framework:
As we all know by now, our entire framework in C++ is basically hand-made by Mats. While that being very amazing, writing basic code for the system requires extra brain work.

Hurdle 2) A problem I had, which Mats discusses in his part of the blog post, is that the HC-SR04 driver he wrote assumed we use one echo pin for all HC-SR04 sensors. While cool in theory for saving pins, this introduced some problems for us like requiring a breadboard (extra cables). It also introduced a problem with saving the different sensor values separately. A quick and elegant rework was done by Mats to fix this, and I was able to utilize the driver.

Now, let’s talk about code implementation of the yaw orientation to face perpendicular to a wall. The way we’re solving this currently is by using a PID controller combined with two distance sensors in the front. What the PID controller does in our case is attempt to regulate a value towards a target, by controlling the motors. Here’s how I’ve coded it:

Here’s an example of regulate being used:

Function that regulates towards perpendicular orientation.
Note: fl, fr = front left and front right distances

Mats

While it has been a busy week I have still been able to make progress!

Fixing the HC-SR04 driver

On Monday Jonathan told me he had issues with the HC-SR04 driver after I had helped out refactoring it to have separate echo pins. Investigating it I found I had an incorrect explicit move that screwed up the vector holding the sensor configuration, whoops!

Well, I also noticed the timer abstraction I wrote lacked immediate execution meaning timer callbacks just got scheduled which I also changed.

Refactoring the entire Simulator codebase

Well, I may have done a mass refactor of the Simulator this week.

So in short the entire Simulator codebase was not meant to do much more than just visualizing the execution of an algorithm in the maze, and all new UI just ended up inside of the same massive class and event loop meaning everything became harder to implement over time.

I’ve split application logic into services which can be accessed through application->GetService<Service>();and it uses the typeid to register and get them from an unordered map, meaning one can register services without adding it to any data structure! In a way this has a lot of overlap with dependency injection.

Also I’ve separated the UI windows into their own contained implementations that use a register pattern identical to the one I made for algorithms.

Also I’ve added an abstract base class for all the interactions the UI does with a “Mouse”. For now it is just simulated, but writing a remote mouse class and interacting with BLE should just work!

Iver

This week I have been soldering the sensors to a prototype board. As I barely have any soldering skills this took some time. But after a few hours in the basement I think i got the hang of it.

This had to be done to make the sensors small enough for the new car. The sensors I made are for the sides of the car, and therefore had to be so small that they could fit between the wheels.

Writing this I still have to make a few changes until I am fully happy with them. So after the kids have gone to bed I will get some of the components closer to the board and soldier them a little more firmly in place. I will also see what I can do about filtering, as that is what I was doing before we where given the new car.