https://sourceforge.net/p/rainbot/blog/2012-04-15T13:38:15.261000ZRecent posts to blog2012-04-15T13:38:15.261000Z2012-04-15T13:38:15.261000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.net760b6594a434ff5e696bd2075a5c3904fdc22de7

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 . Waiting for some help from RobotC Support team, I postpone a bit this project release with the hope to share a stable project version soon ;-) . If some of you are interested in debugging, contact me, I'll share the project as is. Miki.

2012-04-01T19:32:46.612000Z2012-04-01T19:32:46.612000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.net5a69b1a157f65cebf970c2c2b11685e7712e58bd

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. See you. Miki.

2012-03-26T18:22:55.017000Z2012-03-26T18:22:55.017000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.netb4fff6a9778197d9d572623c71c4d6946348c867

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). Regards. Miki.

2012-03-21T17:19:39.540000Z2012-03-21T17:19:39.540000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.netaa093fd3b201f4d062215ef5c999905e0d0b1ab2

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 structure. 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). Stay tuned ;-)

2012-03-18T13:44:30.621000Z2012-03-18T13:44:30.621000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.neta5ef6f6e0b1ed0c584bbd0bbb26bac8ca03df306

the v0.09 features a better simulation thanks to fixed motor emulation.

2012-03-18T13:44:02.128000Z2012-03-18T13:44:02.128000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.neta73b9f299a5fa913560f6422974e9b53e60fec2b

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.

2012-02-28T14:58:17.797000Z2012-02-28T14:58:17.797000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.nete47f67b59435ac6e4c12e00960a51bcc6f3c2f26

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 enable to work in a similar way with physical robot or emulator.

2012-02-22T11:31:21.217000Z2012-02-22T11:31:21.217000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.net4c1b5ed25df2f9c8e57c0c5d9a6764bf0f912666

The main next step for RainBot development will be to test the creation of a task (maybe named '**spin**') handling: - all sensors - all motors - some interactions : motors stop if bump, etc - some odometry '**spin**' task will communicate with the main task through a data interface (not yet defined)

2012-02-22T11:25:48.278000Z2012-02-22T11:25:48.278000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.net980b043a6ffcb0e51f84d94b55eb88634c47c407

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**. :-)

2012-02-22T11:20:43.467000Z2012-02-22T11:20:43.467000Zmichaelhttps://sourceforge.net/u/lightcore/https://sourceforge.net510d17b96f5ca7b3d77a08c47dfca4d26c077abc

Next step for RainBot development: To test the creation of a task (maybe named 'spin') handling: * all sensors * all motors * some interactions : motors stop if bump, etc * some odometry 'spin' will communicate with the main task through a data interface (not yet defined)