A new week is upon us… ​

Deeper into the code void we go…​ ​

Jonathan ​

This week I’m finally hopeful that we will successfully complete the micromouse challenge. As of tuesday, our mouse can:

• Travel in a straight line without crashing in the sides.
• Detect and upload wall placements, and fill an empty simulated maze with tiles.
• Turn around and thus change its heading direction
• Run an actual algorithm like “Flood Fill” and “Wall Follower” based on detected tiles.

Here’s a video showcasing the first two points:

These are nice progressions in our project, but some things still remain:

• Connect a battery pack to the mouse that fits well and delivers enough power.
• Implement remote debugging.
• Etc ​

Mats ​

This week I’ve been both working at home fixing issues found during integration and brogrammed pair programmed with Jonathan using a cool feature in VSCode called Live Share letting us share access to editing code local to a device.

Thus we are able to iterate more quickly and fix issues together without having to share a keyboard or constantly sync changes to git. However here are some of the highlights.

Working on the Robot code with Jonathan

We’ve been fixing a lot of things this week, like making the robot able to ignore a wall on the side missing and continue driving straight forward, also I suggested an improvement on how we handle rotation, instead of doing a different PID that would fight with the right motor one, we’ll just set rotation to 75% of what movement to the right to keep us in the middle. Turns out this makes the robot drive straight very quickly even when we bump it while running it will return to the movement driving straight within a couple seconds!

Failing at getting the Micro:bit compass in an usable state ​

This week we tried using the built-in compass in the Micro:bit to find out when to end turns, however even when calibrated while in the breakout board to get the right centre of gravity. The results fluctuate too much during movement meaning it only is even close to accurate when the robot stands still and no level for filtering like lowpass or averaging multiple samples seemed to improve it. So for now we just hard code the turning based on time and hope battery voltage and other scary environmental factors won’t break it ​.

Debugging random crashes and rewriting the IR driver ​

During this week we have been plagued with 030 error codes from the Micro:bit, checking the error code list it is heap corruption. I decided to dig into figuring why it had suddenly started being such a problem, it would usually occur within a minute. Turns out commenting out the line that runs the IR code that pulls the buffer from the ADC sampling for IR diode input fixed it. So there must be an issue there!

Out of curiosity I decided to search for 030 in the GitHub organization of Lancaster University which has created the CODAL library for the Micro:bit.

Auch, we set the analog period before the analog value ​ (This really should be documented outside of samples). However that still did not fix it. ​

Not like it should have been the cause as it was code that pulled the buffer from the ADC that caused the issue in the first place, it still ran fine with the initialization code beforehand.

That is when I realised there must be a scary race condition with pulling the buffers which also makes sense at it’s not always the buffer is full and I instead sample the value from the middle of the buffer instead of the end. ​

Turns out codal has something call pullRequest which is called by the interrupt when the ADC has filled the buffer on connected DataSink’s. I just implemented a custom DataSink to do the pull when called pullRequest on, also eliminating the need to manually tell the IR driver to pull, so far this seems to have fixed the scary race condition, but I have not been able to fully test it from home. ​

Fixing remote debugging ​

So remote debugging had two major testing when we tried it, rotation seemed wrong and walls did not update.

For rotation it was just a silly mistake, as floats did not seem to be ABI compatible between the Micro:bit and PC I ended up just multiplying it by 1000 and sending it as a 16-bit signed it, as the maze is 16×16 and 16*1000 is still way under the max value of the 16-bit int it was fine. However 0-360 degrees in float did not like that and overflowed, I ended up just changing it in the struct to 32-bit signed int and it worked as expected. ​

For the walls not updating I got errors in the console of the simulator saying it got 20 bytes instead of the expected size, turns out the notify function for BLE in CODAL (or even BLE spec?) only supports 20 bytes of data to notify with. I ended up just sending a dummy byte and then read the maze in the Simulator instead, and it started working too.

Hopefully the remote debugging feature will be more useful next week…

Iver ​

In this weeks segment of “Iver doing things he knows nothing about”: I try to figure out our battery situation. You see, we need 5V in a small form factor to drive the motors.
I have used the LM323K voltage regulator that Steven gave me so far.

This is the schematic given in the product page. The issue is that I do not have the right capacitors to make this happen. Therefore I tried something else. Before trying this again on monday, as the breadboard is ready to go when I get the new parts. The goal was to use 4X AA batteries, and convert 6V to 5V. Sadly, the voltage regulators Steven had demanded a minimum of 7,5V to function. I therefore tried with 9V batteries.

After a lot of trying and thinking of what I could do without a chance to get the parts I needed I found the AM51117 in my personal kit. This worked in terms of voltage, but I am not certain that the ampere will be sufficient for our project.

I am currently soldiering the AA battery pack in a way that I am able to use it with both circuits. Time will tell tomorrow which solution works.

I have also started making an outline of the final presentation, so that is will be easy to set this up when the time comes.