Micromouse project question.

[cdavis]

hey everyone,

I am currently working on a micromouse, and I am trying to account for all of the things that might take place in memory so as to decide how to allocate it properly. For a little background information, the micromouse is a small robot that navigates a maze composed of 256 18cm x18cm squares. The robot stores information about the walls of the maze in a 256 byte array, each byte representing one square. The mouse also uses a flood algorithm that determins the distance the mouse is from the center based upon the information the mouse has gathered about the maze. I imagine that will also take another 256 byte array, perhaps less, but I am not entirely certain. So my mouse will have to multitask various different functions, including monitoring speed, calculating distance, performing turns, using the sensors to store information and provide feedback for the motors, and of course solving the maze. I suppose my question is: will 1024 bytes of ram be enough for all of that? if not, can i use the EEPROM to store the maze information? can I interface with an external ram device? I am not very good at memory management because unfortunately I am a desktop and web programmer but I am trying to delve into the world of microcontrollers, and more direct control of computing power.

Thanks for the help,

[dkinzer]

Whether or not you can implement this using the current ZX-24 depends a lot on how you encode the information that you need to store. You should be aware that you cannot use all of the available User RAM for defined variables because task stacks use some of it as well.

You can use Persistent Memory and/or Program Memory to store data but both of these stores have a finite write limit and are thus not suitable for data that gets updated often. The minimum guaranteed by the manufacturer is 100,000 write cycles.

We are testing a new version of the VM that uses a different strategy for partitioning the available RAM. The current version provides 1K for User RAM and uses the remaining 1K of RAM for string store and system RAM. The new version combines the User RAM and string store in 1.5K with the remaining 0.5K for system RAM. For applications that use no strings at all the net result is an increase of 0.5K of User RAM. On the other hand, some string-intensive applications that exhausted the string store with the current VM will be able to run under the new VM. We'll soon be posting a special firmware update for anyone that wants to experiment with the new VM. It may be that the additional RAM will be helpful in your application.

[victorf]

I would like to comment on the variable storage situation. I needed to store several kilobytes of strings that would ultimately be prompts on the system 4 X 20 LCD screen, I fortunately found that there was a hardware solution to my problem, an LCD screen system with the capability of storing up to more than 90 80 byte strings (7200+ bytes). This solved my immediate problem. I had also added a Ramtron FM24C256 FRAM EEPROM to the system to store some system parameters and to store some intermediate computed variables. The FRAM, for all practical purposes in my application, removes the write cycle limitations imposed by some EEPROMs. Before I was able to get the LCD solution working, I seriously considered using the FRAM for the string storage space as well. This usage would be write once, read many.

I suggest that if you are faced with storing many string variables you consider building the FRAM into your application and using it to relieve the memory restrictions for variable storage. If you were to use my FRAM routines (posted on the Files forum) as a basis, it should be an easy matter to extend them to read any desired string at any time, using the FRAM as a random access device. Heck, you could store and retrieve any variable type you wished.

HTH

Vic

[JC]

Interesting project. Is the maze a 16x16 square? The wall data can be saved as 1 bit per box, instead of 1 byte per box, storing the entire wall database in 32 bytes, unless you are storing either N/S/E/W vector data, or nearest neighbor data along with each box.
From a practical matter; design the mouse, run the maze, move on to the next project; I'm not sure ram R/W limitations are a problem worth focusing on at this stage. 100K gives you LOTS of runs for program development and demonstrations, unlike some applications that R/W data continuously. If the lifetime of the ZX is an issue, then an external eeprom or fram is a good option. Spending a buck or two on a (replaceable) eeprom is trivial, and leaves the $60 ZX intact for future projects. Your algorithms, and the mechanics would seem to be higher priority tasks.
Good Luck, JC

[mikep]

I suggest that if you are faced with storing many string variables you consider building the FRAM into your application and using it to relieve the memory restrictions for variable storage.

I would suggest that many ZBasic programs (especially with the very compact code generated by the compiler) do not go anywhere near the 32Kbyte limit and that the ZBasic EEPROM is the best and cheapest place to store this type of read-only string.

[mikep]

Interesting project. Is the maze a 16x16 square? The wall data can be saved as 1 bit per box, instead of 1 byte per box, storing the entire wall database in 32 bytes, unless you are storing either N/S/E/W vector data, or nearest neighbor data along with each box.

I can think of at least 5 bits of information that are needed for each of the maze squares (rooms). They are as follows:

• "North" wall or door
• "East" wall or door
• "South" wall or door
• "West" wall or door
• visited or unvisited.

[JC]

Agreed. I was considering the memory space needed, saving the info as a (partially filled) byte array, or as a (100 % filled) multi-dimentional bit array. Both methods requires a good algorithm for looking up the location of the data for the nearest neighbors. With byte storage, you then use bit logic for the specific info. With bit storage, you use the same index into an array for Wall/path, N, E, S, W Wall/door, and the history bit. I hadn't considered the history bit, and was thinking that without compression, bit arrays would use only 5/8ths the room of the byte arrays. A reasonable savings if space turns out to be an issue.
Depending on how one approaches the task of traversing the maze, and marking the current path, failed paths, and paths not yet investigated, more storage will be required, too. At the global level it would not appear to be a simple binary tree. Looks like Cdavis may also test the limits of recursion on the ZX!
One could certainly model their algorithm for navigation, (maze solution), on the PC prior to porting it to the ZX, if that proved easier.
Interestng project.
JC

[cdavis]

One could certainly model their algorithm for navigation, (maze solution), on the PC prior to porting it to the ZX, if that proved easier.
Interestng project.
JC

This is true, and I have done this to a degree. I wrote an Microsoft excel addin oddly enough. I drew a maze in an excel spread sheet by coloring certain cells to represent walls and developed my own numbering system for the maze cells. It has 256 cells just like a real maze, and "memory" is represented by other spread sheets that have a grid that represents a two dimensional array. What is nice about the simulation is that it solves a given maze exactly how the real mouse would do it in a maze with the same wall set up. and you can see how the program manipulated the wall data on the wall memory page. you can see the bit values in the grid and see the cells the mouse has visited. This simulation is a great learning tool, and it was a fun project to work on. If any one is interested in having a look-see just let me know. I will also have more information about it on my micromouse project web page.
http://www.csupomona.edu/~cwdavis/micromouse1/rvc2.html