The type map_cell_t in AMCL is way bigger than it needs to be. This specially troublesome for embedded platforms with limited amount of RAM.
The structure contains basically two elements, _occstate and _occdistance:
// Description for a single map cell.
typedef struct
{
// Occupancy state (-1 = free, 0 = unknown, +1 = occ)
int occ_state;
// Distance to the nearest occupied cell
double occ_dist;
// Wifi levels
//int wifi_levels[MAP_WIFI_MAX_LEVELS];
} map_cell_t;
Assuming 32 bit ints and 64 bit doubles, this type weights 12 bytes. Doesn't sound like much, but this type is then allocated size_x * size_y times, typically 4000x4000 times. Resulting in roughly 180Mb of memory consumed.
Using an int (32 bits by default) to store a state with only 3 possible values is an overkill. Also using double precision floats to store the distance to the nearest occupied cell.
I would propose the following change:
// Description for a single map cell.
typedef struct
{
// Occupancy state (-1 = free, 0 = unknown, +1 = occ)
int8_t occ_state;
// Distance to the nearest occupied cell
float occ_dist;
// Wifi levels
//int wifi_levels[MAP_WIFI_MAX_LEVELS];
} map_cell_t;
Doing this, now the type weights 5 bytes, resulting in only about 76Mb of memory consumed. Which makes a huge difference for embedded platforms.
Given that the default map has 4000x4000 cells @ 0.05m/cell resolution the loss of precision between using a float or a double to store distances within the grid is negligible.
I applied this change a year ago to the fleet of robots I manage and they are being used daily without any noticeable loss of performance on localization. On the contrary, now the amcl node runs faster because it doesn't need to index as much memory as before.
If there is interest I will submit a pull request.
The type map_cell_t in AMCL is way bigger than it needs to be. This specially troublesome for embedded platforms with limited amount of RAM.
The structure contains basically two elements, _occstate and _occdistance:
Assuming 32 bit ints and 64 bit doubles, this type weights 12 bytes. Doesn't sound like much, but this type is then allocated size_x * size_y times, typically 4000x4000 times. Resulting in roughly 180Mb of memory consumed.
Using an int (32 bits by default) to store a state with only 3 possible values is an overkill. Also using double precision floats to store the distance to the nearest occupied cell.
I would propose the following change:
Doing this, now the type weights 5 bytes, resulting in only about 76Mb of memory consumed. Which makes a huge difference for embedded platforms.
Given that the default map has 4000x4000 cells @ 0.05m/cell resolution the loss of precision between using a float or a double to store distances within the grid is negligible.
I applied this change a year ago to the fleet of robots I manage and they are being used daily without any noticeable loss of performance on localization. On the contrary, now the amcl node runs faster because it doesn't need to index as much memory as before.
If there is interest I will submit a pull request.