{"id":8063,"date":"2023-10-15T21:58:23","date_gmt":"2023-10-15T20:58:23","guid":{"rendered":"https:\/\/dronesonen.usn.no\/?p=8063"},"modified":"2023-10-15T21:58:23","modified_gmt":"2023-10-15T20:58:23","slug":"keeping-up-with-the-microbros-week-8","status":"publish","type":"post","link":"https:\/\/dronesonen.usn.no\/?p=8063","title":{"rendered":"Keeping Up With the MicroBros – Week 8"},"content":{"rendered":"\n

Hey there, beautiful human beings! \ud83d\udc96\u2728Another week has passed and it has now been an entire month since we lost a member, so we must be doing something right! \ud83c\udf89<\/p>\n\n\n\n

While we still need to downsize the robot so it can actually fit the maze there are still plenty of other progress in preparation for this.<\/p>\n\n\n\n

Jonathan \ud83e\uddd9\u200d\u2642\ufe0f<\/h2>\n\n\n\n

This week I\u2019m exploring alternatives to the localization feature I\u2019ve previously had a look at. I suspect there are simpler ways to track the position of the mouse, that involve fewer sensors and are more intuitive. My problems to solve are the following:<\/p>\n\n\n\n

Determine the coordinates of the mouse inside the maze.<\/strong>
Let f<\/em>, l<\/em>, and r<\/em> be the distances measured from the mouse to the nearest walls in the front, left-hand and right-hand directions respectively. These will be measured with ultrasonic sensors. Incremental changes in these variables will be denoted df<\/em>, dl<\/em> and dr<\/em>.<\/p>\n\n\n\n

\"\"
System visualized with variables f, r <\/em>and l.<\/em><\/figcaption><\/figure>\n\n\n\n

Before we can trust these distance values, we must know either know the angle the system is heading and include this in our calculations, or just use regulation techniques to make sure the system is perpendicular to the front wall, and parallel to the side walls.
There are two ways I want to consider in regards to regulating the system towards being perpendicular to the front wall. The first way is to have two distance sensors facing the same direction and rotate the system until the difference between the two readings are 0.<\/p>\n\n\n\n

\n
\"\"
Using two distance sensors in the front. Not perpendicular if not equal.<\/figcaption><\/figure>\n\n\n\n
\"\"
Finding a distance minima indicates perpendicular orientation. Uses only one distance sensor in front.<\/figcaption><\/figure>\n<\/div>\n\n\n\n

We can also attempt to find a perpendicular orientation the front wall by using our left and right distance sensors by assuming that these distances should not change when performing a forwards or backwards movement of the system. Any changes in the values will indicate a non-perpendicular orientation and can thus be regulated towards 0. Combining these methods with the front-facing sensors can provide extra redundancy or replace the front method altogether. \ud83c\udfaf<\/p>\n\n\n\n

\"\"
Changes in side-distances over time indicates non-perpendicular orientation.<\/figcaption><\/figure>\n\n\n\n

The approach we can take to make sure the system is always in the middle of a \u201ctile\u201d is simply by regulating the left and right distances until their difference is 0. However, when an unbalanced amount of tiles appear on either side, we must utilize modulo division to stay centered in our tile and not regulate towards an unwanted center. \ud83c\udff9 <\/p>\n\n\n\n

\"\"
Regulating towards center alignment using side sensors and modulo division.<\/figcaption><\/figure>\n\n\n\n

Now, when we are safe to assume the orientation and centralization of the system, we can attempt to determine its position. \ud83d\udc4a<\/p>\n\n\n\n

Remember df<\/em>, dl, <\/em>and dr?<\/em> Let\u2019s combine them with the orientation of the system \u03b8 to track the system\u2019s changes in position in the following way.<\/p>\n\n\n\n

\"\"
Formula for change in position based on distance sensors f<\/em> and l<\/em>.<\/figcaption><\/figure>\n\n\n\n

Determine placement of walls in the maze.<\/strong><\/p>\n\n\n\n

If we assume the position of the system and its orientation, any obstructions detected by our ultrasonic sensors can be interpreted as walls and thus placed into our virtual maze.
This method is performed in two steps: 1) Determine the tile in which the wall exists, and 2) determine the direction of the wall inside its tile (top, right, left, down).
The below image shows how we can calculate the tile numbers based on distance readings and floor division.<\/p>\n\n\n\n

\"\"
Determining tile in the y-direction based on distance and floor division.<\/figcaption><\/figure>\n\n\n\n

Mats \ud83e\uddd1\u200d\ud83d\udcbb<\/h2>\n\n\n\n

Monday this week went to watching Jan Dyre\u2019s presentation about signal processing. In addition these are things I have done throughout the week:<\/p>\n\n\n\n

Implement callback-based timers \u23f2\ufe0f<\/h3>\n\n\n\n

CODAL already has ways to interact with the system timer, but it is event based and needs to be provided an integer that will be sent with to a common event handler and not the more normal high-level callback per timer one, many of us are used to.<\/p>\n\n\n\n

However implementing this on top was easy and something I did when implementing output smoothing for the motor driver, here is the code!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

It is not perfect, and you can easily run out of id\u2019s for timers when creating one-shot ones rapidly, at the moment this is not an issue, but it is something to watch out and rectify if they ever become used somewhere in the code.<\/p>\n\n\n\n

Implementing output smoothing for the DFR0548 driver \ud83d\udede<\/h3>\n\n\n\n

So in short, switching the direction of a motor while running has a high chance of triggering over-current protection. So I wrote some code that will smooth this transition if the values are for opposite directions and this seems to have helped.<\/p>\n\n\n\n

Writing a C++ driver for the HC-SR04 \ud83d\udccf<\/h3>\n\n\n\n

On Monday Jonathan asked me if I could make a C++ driver for the ultrasonic sensor this week, something I did. I decided to write it in a way to support multiple sensors with a shared echo pin.<\/p>\n\n\n\n

Using the CODAL event system that uses interrupts internally I was able to move on from blocking on the waiting for the falling edge on CPU to just using the CODAL pulse event, meaning the driver only sleeps the 10us needed for the trigger signal!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Implementing flood fill \ud83c\udf0a\ud83d\udeb0<\/h3>\n\n\n\n

Building on the research done by Iver previously I decided to implement flood fill in our Core library meaning it can be used in the Firmware and tested in the Simulator.<\/p>\n\n\n\n

I implementing it by adding another vector with values for every tile, I default initialize the ones with a goal to 0 and add them to a stack, and then all the others one to the max value.<\/p>\n\n\n\n

After that I iterate the stack until empty and add 1 to the value and check if any of the adjacent tiles have a higher value and are not blocked by a wall, if so update the value and add to stack.<\/p>\n\n\n\n