What’s up readers, mid-term presentations are over, so let’s get right into the news this week.

Jonathan ​

PRESENTATION IS DONE, WE MAY NOW FOCUS ON DOING THE ​ WORK ​

I’m still working on a localization feature of the micromouse, and there are quite a few problems to overcome:

• Acquire a gyroscope to sense rotation rates for sensor fusion:
  Considering something like this sensor should interface with our micro:bit v2 through I2C. That sensor does include an accelerometer and magnetometer as well which we already have built-in on the micro:bit, but I can’t seem to find a standalone gyro so it will have to do. Maybe Steven has one I can use? Otherwise will just order one. There is also some soldering involved in using this will have to ask help from somebody who knows how to do that.
• Proper mathematical formulas for accelerometer, gyroscope and magnetometer sensor fusion.
  The formulas I’ve used until now only work for ideal settings where bias and noise factors are not present. Need formulas that factor this in so I can filter accordingly.
• Need to consider other “creative” ways to filter noise/drift like:
  Only accepting new accelerometer input when I’ve also signalled the wheels to move. This could remove drift when the car is not in motion.
  Setting accelerometer values to zero when detecting no changes in ultrasonic distance sensors.
  Maybe use distance sensors as a budget gyro? Having two distance sensors facing the same direction (in the front) could maybe give me rotation rates while the car is somewhat perpendicular to the wall?
  BTW: Need to figure out how to make the ultrasonic sensors facing the same direction not to cause interference with each other. Should be solveable with some delays.
• Visualizing sensor data stream for debugging:
  Can use a serial oscilloscope for this. Considering to use one like this: serial oscilloscope​. Using this will help me detect the bias and noise of the sensors so I can filter them out.

Mats ​

Adding shared logging utilities for micro:bit and simulator ​

Until now I have just been using the fmt text formatting library with the print and println functions within the simulator.

However Jonathan has started working on positioning with the micro:bit, turns out it makes more sense to log instead of breaking in a debugger for this. The built in printf function in CODAL does not support types like floats.

I had tried to add fmt to our Firmware target in CMake before but it made the program flash usage reach 110% which was big a stopper, but I decided to look into fmt again and see if there is anything I can do to trim some fat out of the code size.

Looking through the headers I found the FMT_STATIC_THOUSANDS_SEPARATOR define which disabled the usage of including <locale> and suddenly the code size went down to a fraction of what it was!

I’ve implemented some basic functions to print and added macros that can be used from any namespace to call the main Logger implementation which will use stdout in the simulator and serial in the firmware:

Implementing BLE communication ​

Last week I wrote “More Debugging? ​“ within the Next week section, but I had no idea it would turn into as much debugging I underwent with getting BLE working.

CODAL has it’s own class you can extend that will register BLE services. In short BLE services can contain “characteristics” which can be read or written to (with multiple methods) that you define.

All of that is easy, CODAL already has most of the UUID defined, only a small 16-bit part is set. And defining the service is not much harder than this:

The problems came in when pairing stopped getting persisted over resets and other weird behavior, it actually worked once!. After a significant amount of time debugging I lost track of I finally found the issue. After having tried different combinations of the CODAL BLE compile-time definitions and simplifying things and eventually found out that I had to allocate it on the heap instead of just let the compiler put it on the stack.

My guess is something got moved when the separate fiber for BLE got fired off and weird undefined behavior ensued. ​

The important part is that communication works, would have been nice if it was documented in the BLEService class though. ​

Since all my structures have a static size, and both modern sane microprocessors and the nRF52833 (Cortex M4) in the micro:bit v2 are little-endian. I can get away with just doing a simple size check and casting ​. Or as I call it: zero-cost serialization (Zero-cost because there is actually no serialization ​).

After having thrown together a Bluetooth connection manager in the Simulator using SimpleBLE, I was ready to write to the motor.

For now you can manually enable a remote motor control which has support for both keyboard and gamepad input through SDL which the simulator uses for window & input management and rendering.

And now, featuring no wired communication! ​

Sadly, the speed which a motor has to run at to even be able to turn the gear is so high that I was unable to make it drive slowly, ruining the fun of analog input. ​

From here utilizing the BLE communication for telemetry and stopping and running algorithms definitely makes sense to implement soon-ish.

Iver ​

Implementing IR sensors

This week has been a frustrating one. I have tried to set up the IR sensor on the breadboard multiple times, but I constantly get the value of 1, which does not help me much. My theory is that I set up the transistor wrong. The troubleshooting will go on. And if I cant do it before the group meet again. The boys might know whats wrong.

Next week on Keeping Up With the MicroBros ​

• More moving, tracking and facepalms ​
• Maybe the MicroMouse will become artificially intelligent and demand rights ​
• Deadly amounts of debugging (worst-case) ​