Great discussion started here To answer some of the questions and to give more background:
- The grid resolution is 1x1cm. The problem starts when the distance of the readings gets high. Then a 1° resolution doesn’t cover all cells anymore. And cells get counted double on short distance – which needs to be compensated. So for larger distances I need to get down to about 0.1 degree in reality to not miss cells. - So far I ran the logic for the robot on a PC. No problem here with the performance using trigonometry (in java). But I am on my way porting everything to a raspberry pi which will be on the robot itself. Due to the limited calculation power I want to avoid too heavy calculation for regular jobs. The scans come in about every 40ms. So the calculation needs to be as fast as possible. - I surely will benchmark the new approach vs. the trigonometry solution which I will port from my current java solution. Maybe I will be surprised – but I think the trig approach will be slower. The lookup table is also a great idea! I can produce it for any resolution needed and on runtime it is simply combining lists for the slices needed…..not bad. So far I have the circle points as well as the lines – using the Brenham’s circle and line functions. Code: http://pastebin.com/GzUzuAnb I just need to get the filling done….. Robert -- https://mail.python.org/mailman/listinfo/python-list
