View unanswered posts | View active topics It is currently Sat Nov 29, 2014 1:34 am






Reply to topic  [ 11 posts ] 
3.08 2D Array issue in NXT brick with fw 9.12 
Author Message
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post 3.08 2D Array issue in NXT brick with fw 9.12
Hello,

I explain here my current issue about arrays (with a bit more information).

Explanations
This issue is with code RobotC v3.08 and its firmware NXT_0912.rfw
The code (attached below) displays first a legend, then a map of cells where
  • walls are 5x5 black dots
  • target is a cross
  • origin is a square with a white dot
  • path cells are 3x3 black dots
  • examined cells (also called OpenSet in A* documentation) are single black dots.
The program loops endlessly, finding path from origin to target (changing on each loop)

tests done
When I run the program in emulator mode, it works perfectly (see picture below)
When I run the program in NXT brick, it throw an exception Array out of range during very first initialization.
When I run the program in NXT brick, with Run time array bounds check option OFF, the program runs but displays false map (see picture below).
This suggests to me that the error is not in the run time array bounds check module but in a firmware array management itself.

I hope this new information will helps RobotC Support Team to help me :-)
Miki.


Attachments:
File comment: Legend of the map
Presse-papiers-2.png
Presse-papiers-2.png [ 20.4 KiB | Viewed 5074 times ]
File comment: In EMULATION, the program displays correct arrays
Presse-papiers-1.png
Presse-papiers-1.png [ 20.23 KiB | Viewed 5074 times ]
File comment: In NXT brick, the program displays wrong arrays
Presse-papiers-3.png
Presse-papiers-3.png [ 20.62 KiB | Viewed 5074 times ]
File comment: project files. COMPILE "myMap.c"
RainBot beta v0-11 Array out of range.zip [39.7 KiB]
Downloaded 221 times

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Last edited by miki on Mon May 07, 2012 11:20 am, edited 2 times in total.

add details in topic title

Mon Apr 30, 2012 6:53 am
Profile
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Hello,

I had sometimes this morning to try a new approach, and I finally worked around the strange bug concerning 2D array management in firmware 9.12.
I changed the declaration of all my 2D arrays ...
Code:
typedef struct
{
  COORD Dim;                               //!< Point.X and Point.Y used as dimensions of the map
  ubyte Cell_Info[MAP_SIZ_X][MAP_SIZ_Y];   //!< predefined informations on cell (WALL, DOOR, etc)
  ubyte Cell_Scan[MAP_SIZ_X][MAP_SIZ_Y];   //!< scanned    informations on cell
  int   Cell_Mark[MAP_SIZ_X][MAP_SIZ_Y];   //!< Mark used by Path Finding function
} MAP;
... into 1D arrays if firmware version equals 9.12
Code:
typedef struct
{
  COORD Dim;                               //!< Point.X and Point.Y used as dimensions of the map
#if(firmwareVersion==912) // bug with 2D arrays in this firmware
  ubyte Cell_Info[MAP_SIZ_X * MAP_SIZ_Y];   //!< predefined informations on cell (WALL, DOOR, etc)
  ubyte Cell_Scan[MAP_SIZ_X * MAP_SIZ_Y];   //!< scanned    informations on cell
  int   Cell_Mark[MAP_SIZ_X * MAP_SIZ_Y];   //!< Mark used by Path Finding function
#else
  ubyte Cell_Info[MAP_SIZ_X][MAP_SIZ_Y];   //!< predefined informations on cell (WALL, DOOR, etc)
  ubyte Cell_Scan[MAP_SIZ_X][MAP_SIZ_Y];   //!< scanned    informations on cell
  int   Cell_Mark[MAP_SIZ_X][MAP_SIZ_Y];   //!< Mark used by Path Finding function
#endif
} MAP;

I had also to modify all access to former 2D arrays into 1D array access, but this was easy because I already had few accessors functions that centralized all accesses to 2D arrays.
I just created macros (like __CellInfo(x,y) in the code below) that compute the index of a cell in 1D array, from 2 given indexes X and Y. Note that the macro names are prefixed by 2 underscores. It's my convention to signal some unusual workaround or trick. ;-)
Code:
 #if(firmwareVersion==912) // bug with 2D arrays in this firmware :-(
 #define __CellInfo(x,y)  Cell_Info[x+(MAP_SIZ_X*y)]
 #define __CellScan(x,y)  Cell_Scan[x+(MAP_SIZ_X*y)]
 #define __CellMark(x,y)  Cell_Mark[x+(MAP_SIZ_X*y)]
#else
 #define __CellInfo(x,y)  Cell_Info[x][y]
 #define __CellScan(x,y)  Cell_Scan[x][y]
 #define __CellMark(x,y)  Cell_Mark[x][y]
#endif


The accessors functions were modified like this:
Code:
//-----------------------------------------------------------------------------------------------------------------------------
//! @brief        set info of a cell
//! @param[in]    Coord cell 2D cartesian coordinate
//! @param[in]    Info  cell info
//! @return       bool  true if coordinate is inside home else false
//-----------------------------------------------------------------------------------------------------------------------------
bool Map_Cell_SetInfo(COORD& Coord, ubyte Info)
{
  if(Map_Cell_IsExist(Coord)) { Home.__CellInfo(Coord.X,Coord.Y) = Info;  return true;  }
  else                        {                                           return false; }
}


And guess what? no more bug or exception occurs !! The program runs perfectly either on emulator or on NXT brick. I'll be able to go on my project :-).
However I hope this good news will not discard the priority of this firmware 9.12 bug about 2D arrays in the tickets stack of RobotC dev team. :mrgreen:

Have fun, ;-)
Miki.

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Wed May 02, 2012 2:45 pm
Profile
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
This bug workaround-ed, I'm proud to deliver the version 0.11 of RainBot on source forge.
It works with robotC 3.08 and the firmware 9.12 and it includes an A* path finder.

Have fun ;-)
Miki.

EDIT: It also include a multiple files organization. The same source files can be compiled alone or included in other projects.

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Mon May 07, 2012 10:01 am
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Hi Miki. I just wanted to drop you a note and say I looked in depth at rainbot tonight. I know I often post something I think would be interesting, and hear nothing but silence, so its good to know someone did actually look at it.

I was able to get your code to run in the simulator, and looked through the various modules you have. I will say our coding style is way different :) I tend to cram everything into one file with as little code as possible. You seem to take the other extreme. That's just personal preference :) I try to use meaningful variable/function names and write code that is readable, as opposed to commenting. Key word, 'try' :) (and I was a development manager for many years, so I got to set the rules :) )

I'm in the middle of a similar project, a line maze solver that can handle loops, and run as fast as possible. Because of some health issues, I just can not chase around an NXT on the floor and try to read its LCD for debugging, so I have spent a great amount of time getting 2-way comms between it and a PC working. That is starting to fall into place at the moment.

Any 'lessons learned' you could share? I'm doing remote PID tuning, and odometry ATM. I did not see where you where using PID, but synced motors instead, and depending on Sonar I guess? Which makes sense given a different environment from me. How accurate has the odometry been in real life?

_________________
Mike aka Spiked3
http://www.spiked3.com


Tue Jun 26, 2012 3:40 am
Profile
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Spiked3 wrote:
Hi Miki. I just wanted to drop you a note and say I looked in depth at rainbot tonight. I know I often post something I think would be interesting, and hear nothing but silence, so its good to know someone did actually look at it.
You're very welcome :-)
Since the first version of rainbot in mid February on source forge, 90 download were done.
In fact the sourceforge downloads occur when I post or reply to some topic on this RobotC forums ;-)
When I'm silent on RobotC Forum, the download rate drops close to zero.

One of my project goal was to share it and to learn about SourceForge. SourceForge is a nice way to share but in my personal case, it was not a great feedback provider.
I consider this RobotC forum far more interactive and more 'visible' by the community.
By the way, you may know that hundred of my posts were accidentally erased during the migration to my admin status. After this event, my project visibility on RobotC forum felt and so the Sourceforge download rate.

Spiked3 wrote:
I was able to get your code to run in the simulator, and looked through the various modules you have. I will say our coding style is way different :) I tend to cram everything into one file with as little code as possible. You seem to take the other extreme. That's just personal preference :)

I'm proud to surprise you with a different coding style :wink:
I have two main reasons to program in this way.
First I'm not at all interested in 'small' program where a robot rolls until it bumps something, reverses and turns 45° then loops.
It is not a judgment of course and I respect anyone learning to do this and enjoying this.
And you are completely right when you optimize a small program into a single file, easy and interesting to understand for anyone.

In fact in my case, as senior software architect, I have played a lot on embedded project development, in multiple and various system, mostly proprietary.
RCX before then NXT are hobby for me, among others, and I chose RobotC for its great debug feature and for the possibility to interact with its developers.

The rainbot project goal is so rather ambitious: To build an autonomous robot ruled by behaviors.
To reach this goal, I (started to) design a software with horizontal layers with 'smartest' ones on the top
With a simple program, the robot wants to go from A to B, it turns, then move forward then stop. The motor commands are not very far in the code from the ordre GO_from_A_to_B.
With RainBoat, it is not so simple!
1. Randomly or from an interaction, RainBot changes behavior. ie: HIDE_IN_DARKEST_AREA or RETURN_WHERE_BT_SIGNAL_IS_STRONGER, etc...
2. Rainbot searches in his local map where is such darkest area
3. It runs PathFinding and starts to iterate on the path.
3.1. on each cell of the map, it updates informations in local map form its sensors. if any change, computes again PF. if PF fails, finds another behavior.
3.2. odometry and navigation sub systems drive motors and manage any collision

Like you see the goal is ambitious. It needs a good hierarchical organization code. Here we come to the second reason.
I'm very comfortable with Object Oriented development, even on embedded target, using C or Assembly code.
It's why I organized the project into small pieces of codes (that are objects in fact).
The advantages are:
  • I can separately do unit tests on each of them. This eases a lot the debug process.
  • When a bug appears, I fix it once at the best level (in the right object) and I add to it some specific unit tests to avoid future regression.
  • like C Data structures optimize a lot code efficiency, Object Orientation helps to keep huge programs under control, at least if you are familiar with this development type
The disadvantages are
  • C is not Object language, and RobotC is not C, so keeping Object Orientation leads to a bit of complexity before code reaches a level where it simplify the project. (Am'I clear enough?)
  • The compilation+link in 1 pass of RobotC, needs again to add some code complexity, to keep objects in separate files.

Spiked3 wrote:
I try to use meaningful variable/function names and write code that is readable, as opposed to commenting. Key word, 'try' :) ...

Me too! I hope you remarked it :-) Well smart embedded comments are needed and, at a certain level, documentation becomes mandatory.

Spiked3 wrote:
(and I was a development manager for many years, so I got to set the rules :) )
I'm in the middle of a similar project, a line maze solver that can handle loops, and run as fast as possible. Because of some health issues, I just can not chase around an NXT on the floor and try to read its LCD for debugging, so I have spent a great amount of time getting 2-way comms between it and a PC working. That is starting to fall into place at the moment.

It sounds very interesting. Did you try to use ROBOTC NXT screen window to read NXT screen content from your PC in realtime?

What about my project current status?
After the discovery of this 2D array bug, I spent sometimes to hint it and finally found a cheap workaround.
The embedded simulation, that I added in the project, runs correctly but I wanted to try the RobotC virtual World, in order to go further in heart of Rainbot project and less in the simulation and validation processes.
Unfortunately and if I correctly read some RobotC forum topics, It seams RVW does not emulate motor encoders! In this case I have to go back to my homemade simulation (which simulate them).
I posted the v0.11 and then I got a lot of work so I let apart the project.
Currently I spend most of my free time writing a book (between Science Fiction and Fantasy), so my Robot is wisely on my desk waiting for the next robotic tide ;-)

Spiked3 wrote:
Any 'lessons learned' you could share? I'm doing remote PID tuning, and odometry ATM. I did not see where you where using PID, but synced motors instead, and depending on Sonar I guess? Which makes sense given a different environment from me. How accurate has the odometry been in real life?

Lesson? I had fun to understand A* algorithm, and more fun to share from time to time my work on this forum.

If I mentioned some PID code in my project, please tell me where, because its not the case.

About sensors (sonar, compass, light and bump), the project architecture would enable contextual interpretation of them.
ie: magnetic compass is sensible to metallic object. So a change of its value can mean a robot turn or a metallic mass detection (useful information on the map, like a beacon!)
ie: reading motor torque can indicate a collision or a slope and so on.

I just tested odometry in my simulation and I have to test it in real life...

So Spiked3, It was pleasant to discuss a bit with you.
Best regards,
Miki.

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Tue Jun 26, 2012 3:39 pm
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Behaviors, there is a topic I am interested in exploring. I read Robot Programming by Jones, which emphasizes behaviors, but I found his 'ideas' hard to achieve. I got a little more excited with LeJos and their subsumption functions, but again, actually doing something that way (in a pure sense) was not really practical. I'm still to the point where it seems, yes, it is a cool idea, but in reality when 90% of your behaviors become 'ballistic', it is not a practical theory. Can you discuss your concept of behavior patterns, and if they fit the formal definition, as opposed to more of just generalized patterns we all already use (and actually incorrectly call behaviors)? (then again, i can and will just look some more into your code). (http://en.wikipedia.org/wiki/Subsumption_architecture)

As a manager, my feelings toward documenting code was reversed from a lot of people. I start (my team), as part of the design process, to comment first, write code second, not the other way around. The comments are far more useful if they describe why something is being done, and not how. The code already shows how it is being done. I agree, documentation is needed (at a certain level), and the better it is, the more useful. How may times have we read a comment that said // this section adds A to B ? :) Not real helpful to me, what I want to know is why, and if the function name is AccumlatePosePosition, I do not need additional comments. Again, that is just my style.

As far as OOPs, I was known for writing OOP code before C++ came out :) Test Driven Development (aka TDD) has always been my choice. I understand completely your choices there.

I did not see any PID in your code, but I have seen it in about every other line maze or wall maze sample I have seen, which is why I expected to see it in your code (and did not, as you pointed out).

I'm under the impression, if you couple a magnetic compass AND an IMU, you can get pretty accurate odometry (in junction with encoders obviously). I was wondering if you had tried - or anyone else for that matter. Do you plan to? I was just curious to hear "it worked great" or "don't bother" before I invest the time in/on it.

It seems like the last RobotC release might have emphasized the arduino, which I am excited for them, even though it does nothing for me. But I do hope the next release is not too distant, and gets a lot of the loose ends cleaned up. A 2D array bug is something just plain should not have slipped through (but I do not know the entire story), and I am surprised it hasn't been more of an issue.

Mike

_________________
Mike aka Spiked3
http://www.spiked3.com


Tue Jun 26, 2012 6:21 pm
Profile
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Spiked3 wrote:
Behaviors, there is a topic I am interested in exploring. I read Robot Programming by Jones, which emphasizes behaviors, but I found his 'ideas' hard to achieve. I got a little more excited with LeJos and their subsumption functions, but again, actually doing something that way (in a pure sense) was not really practical. I'm still to the point where it seems, yes, it is a cool idea, but in reality when 90% of your behaviors become 'ballistic', it is not a practical theory. Can you discuss your concept of behavior patterns, and if they fit the formal definition, as opposed to more of just generalized patterns we all already use (and actually incorrectly call behaviors)? (then again, i can and will just look some more into your code). (http://en.wikipedia.org/wiki/Subsumption_architecture)

I hadn't read a lot on behaviors topic. The learning process is part of the game. Like you said earlier "Try first"
I like the idea to be 'surprised' by my robot and to have to guess (or spy) what it is going to do (desperately certainly) !
At this point, I have no doubt about the possibility to realize such program.
The main issues are
  • my own availability. (it's why I comment and document enough to restart project easily (in winter for instance) after long period without coding.
  • technical issues. It is probable that I'll have to face memory size issues. Reducing size of local map or sum of gathered information in ram should postpone real issue.
At functional level, I cant see any issue in the behavior approach.
What do you mean exactly by behaviors become 'ballistic'. English is not my first language and I'm not sure catch what you mean.



Spiked3 wrote:
As a manager, my feelings toward documenting code was reversed from a lot of people. I start (my team), as part of the design process, to comment first, write code second, not the other way around. The comments are far more useful if they describe why something is being done, and not how. The code already shows how it is being done. I agree, documentation is needed (at a certain level), and the better it is, the more useful. How may times have we read a comment that said // this section adds A to B ? :) Not real helpful to me, what I want to know is why, and if the function name is AccumlatePosePosition, I do not need additional comments. Again, that is just my style.

we are 100% in line ;-) I just would add that I ask first for unit test writing, then comment then code etc... Issues appear more quickly when you think early about testing your code.

Spiked3 wrote:
As far as OOPs, I was known for writing OOP code before C++ came out :) Test Driven Development (aka TDD) has always been my choice. I understand completely your choices there.

ok we are 110% in line :-)

Spiked3 wrote:
I did not see any PID in your code, but I have seen it in about every other line maze or wall maze sample I have seen, which is why I expected to see it in your code (and did not, as you pointed out).

I'm under the impression, if you couple a magnetic compass AND an IMU, you can get pretty accurate odometry (in junction with encoders obviously). I was wondering if you had tried - or anyone else for that matter. Do you plan to? I was just curious to hear "it worked great" or "don't bother" before I invest the time in/on it.

:? well it's summer here and I let my project in standby for autumn rainy days. Current status shows odometry works well in simulation but obviously the real word will be more cruel. I fear the robot will not drive straight and will lose a bit of orientation with each turn. my next experimentation will concern probably the accurate control of robot rotation with compass value. because the robot turn on itself, the compass should be equally disturbed by potential mettalic mass. However, the compass it self is not centered at the rotation point of the robot so metallic perturbation force may vary during robot rotation, causing an (among other) reading error. Nice problems to play with a rainy day ;-)

Spiked3 wrote:
It seems like the last RobotC release might have emphasized the arduino, which I am excited for them, even though it does nothing for me. But I do hope the next release is not too distant, and gets a lot of the loose ends cleaned up. A 2D array bug is something just plain should not have slipped through (but I do not know the entire story), and I am surprised it hasn't been more of an issue.

Thanks the workaround for current 2D array bug (turning it into 1D array) is not costly.

Best regards.
Miki.

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Wed Jun 27, 2012 1:09 pm
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
The formal definition of robotic behaviors is a system where separate processes are running (often using tasks), and an arbiter decides, who gets priority. For example GoForward runs at the same time as AvoidObstacle. At some point AvoidObstacle becomes the more important task and modifies some variable. When it takes over, it may simply just adjust the steering, but GoForward continues, with the new heading. That is fine, but a task such as AvoidCliff, may need to stop the robot, back up, make and make turn. It has several processes that must complete, and it completely stops GoForward, it is then called a Ballistic behavior.

I think we (and others) often describe what we are doing as behaviors, when they are simply just processes within a loop, and not a pure robotic sense of behaviors. Again, to me, it is one of those things where I understand the theory, but have yet to achieve it myself (but I still try occasionally), and have not really seen many examples using it. It does seem somewhat more suited to robotic message passing systems such as ROS and MRDS (Microsoft's Robotics) and probably is much harder to implement in something like RobotC.

Odometry seems to be a system of 'corrections'. The wheel encoders can give you some idea of what direction you are headed, but a magnetic compass gives you a more accurate heading (filtered over time). But magnetic compasses are subject to noise as you mentioned. So you can use an IMU. But IMU are subject to drift. If you can combine encoders with an accurate heading, you can get very accurate odometry. So you end up using a kalman filter to combine the magnetic compass and an IMU, and hopefully you know exactly where you are (http://nxttime.wordpress.com/2010/10/06 ... an-filter/). That is the theory anyway.

You can couple that with even more 'corrections' by using something like SLAM (http://en.wikipedia.org/wiki/Simultaneo ... nd_mapping). I have a little bit of that done (a RANSAC part), and it is a longer term goal, like your project is to you. At some point I may need to move processing off the NXT and on to the PC for memory or speed reasons, but that is OK, I still learn no matter where it runs.

_________________
Mike aka Spiked3
http://www.spiked3.com


Wed Jun 27, 2012 1:59 pm
Profile
Moderator
Moderator
User avatar

Joined: Wed Mar 05, 2008 8:14 am
Posts: 3295
Location: Rotterdam, The Netherlands
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
I used subsumption to make a mildly retarded robot that looked for things: http://botbench.com/blog/2010/05/17/bobbot-mk2/

It was quite fun to make but like most of my projects, I never quite finished it.

- Xander

_________________
| Professional Conduit of Reasonableness
| (Title bestowed upon on the 8th day of November, 2013)
| My Blog: I'd Rather Be Building Robots
| ROBOTC 3rd Party Driver Suite: [Project Page]


Wed Jun 27, 2012 2:24 pm
Profile WWW
Moderator
Moderator
User avatar

Joined: Thu Dec 22, 2011 7:42 am
Posts: 43
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
Thanks guys for all this interesting links :-)

_________________
Visit my project RainBot v0.11 on source forge, a 6 wheels robot featuring A* & Dijkstra's path finding, motors & sensors emulation, small font, fifo & sorted list libraries, using Xander's drivers for HT Compass, and documented with doxygen.


Wed Jun 27, 2012 3:17 pm
Profile
Expert

Joined: Tue Feb 28, 2012 3:10 pm
Posts: 195
Post Re: 3.08 2D Array issue in NXT brick with fw 9.12
mightor wrote:
I used subsumption to make a mildly retarded robot that looked for things: http://botbench.com/blog/2010/05/17/bobbot-mk2/

It was quite fun to make but like most of my projects, I never quite finished it.

- Xander


"I also prefer beer out of bottles, but would be willing to settle for cans of beer for which I don’t have to get up."

priceless :)

_________________
Mike aka Spiked3
http://www.spiked3.com


Wed Jun 27, 2012 9:57 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.