In the next release (v0.11) in progress, I organized all files into .c and .h, to get ride of circular references and I coded a path finding using either A* or Dijkstra's algorithm (according a conditional compilation).
While it runs correctly on Emulator target, a strange exception 'Array out of range' occurs while it runs into the Robot target. More details on what seems a firmware bug are available here: http://www.robotc.net/forums/viewtopic.php?f=1&t=4442 . ... read more
I'm currently rearranging all files of the project.
This is because a circular reference appeared in it:
1 myMap.c included "myRobot.c" to enable void Map_Robot_Draw(ROBOT& R) compilation.
2 myRobot.c included "mySimulation.c" because it calls Simu_Step() function.
3 mySimulation.c included "myMap.c" because it needs Map_Cell...() family functions.
So I'm splitting all files into a header (.h) with only structures declarations and functions signatures and a source (.c) with data instances and codes.... read more
The project Rainbot v0.10 returns to basics.
Test functions focus again on their job: to prove that code is valid.
I was able to simplify wall collision simulation, to fix 2 bugs in motor emulation, and to align all maths functions on trigonometric rules (CCW 0=East 90=North 180=West 270=South).
I'm currently debugging mySimulation.c. While all of you know how this process can be long, I want here to talk about one current human error:
The goal of mySimulation.c functions and data is to simulate the motor and sensor behavior (when project is compiled for a target=PC-Physical). In this file, like in all file of the project, the task main() is dedicated to debug and validation of mySimulation.c functions and structures.
However, I was eager to see the first result of Robot Simulation, and I progressively turned the task main() of mySimulation.c into a small robot program in itself. So I added complexity where I needed simplest debug functionalities.
I understood my error when I realized that the bugs I tracked had too many origins instead of coming only from the simulation functions. In a development process, this is generally a bad sign when you begin to fix and patch your project everywhere.
I took sometimes to get a clear picture of all related project files, and to focus only on simulation functions. I should draw a (sort of) UML class diagram and add it to the documentation.
I reshaped and renamed some functions, and I currently learn some basics about collision detection (where I found main bugs).... read more
the v0.09 features a better simulation thanks to fixed motor emulation.
the v0.08 features a small emulation of motors and sensors, in order to run programs in emulation mode (_TARGET="Emulator")
download it and run mySimulation.c to check it.
RobotC has an interesting feature: Your code can run into an emulator.
However, this emulation does not handle peripheral like motors and sensors.
I added in the v0.06 a simple (and expandable) motor emulation.
Replacing all RobotC native motor access, by my 'Motor_...' family functions enables to work in a similar way with physical robot or emulator. :-)
The main next step for RainBot development will be to test the creation of a task (maybe named 'spin') handling:
some interactions : motors stop if bump, etc
'spin' task will communicate with the main task through a data interface (not yet defined)
RainBot beta v0.05 is available.
work was done around pathfinder optimization:
it uses now ring buffer and avoid to copy memory
it uses some intermediate variables (as cache).
its standard test speeds up it from 1.69s to 1.00s. :-)
First post on this blog, mainly to see how its look ;-)