Beginners: please read this post and this post before posting to the forum.
0 Members and 1 Guest are viewing this topic.
dunk, your idea wont work well for really large maps . . . the forget delay would need to be a function of map size, but i can see cases where:A) the delay time is guessed/tweaked by the programmerB) control oscillations from new paths suddenly appearing because of forgetting obstaclesC) moving objects near the robot (highest probability of error) would be the freshest in memoryD) very large maps would need a very long forget delay - or the robot would forget the first half of the map while it explores the second half
Question 1:Can you use some external flash or EEPROM memmory on these MCUs? Maybe buy the now cheap 1Gb thumb drives, rig it to work with the MCU, and bingo! Near limitless (relatively ) memmory for your bot... would something like that work?
You can use flash etc.. with an mcu with some time and effort but you must beware of their limitations....I had a call 6 months ago by an accountant friend of mine saying that he had a usb flash stick that was 128mb (small but still..) but he had only used 7mb of space on the device and it wouldnt let him save anymore. After about 1hr of playing about, i realised the problem was that although his files were small, the device could only hold 256files regardless of its size i.e. they have a smallish allocation table that wouldnt really be suitable for storing arrays. Most memory devices operate in this way by allowing you to program a certain amount of information within predetermined spots ie 256 data areas allowing 1mb of data = 256mb - but you cant have 512 data areas of half a mb. Some algorythms need to be created to store more than one array segment to any area in external ram.
Can it scan more than just 1 grid spot away if it had a longer distance rangefinder? So instead of scanning 1 grid locale away, it can scan 2 grid locations?
for point C), that is precisely why sensor readings are cumulative.presumably an object moving through the field of view will create more "empty" readings than "occupied" ones so the average will be "empty".
but im also playing with a moveable grid system. Where you break an area down into the grid, if the robot moves 2pixels left then the grid does also. So the map is not set into statically defined boundaries which means that youre robot isnt either(obviously waypoints have to be reconfigured also)....
bool CheckOffset() { if (pixelsAwayFromGrid > threshold ) { //lets assume the grid is 5x5 //and because I'm lazy, I only have the algorithm to move the map to the right (compass sensor could fix it) for (int x = 4; x >= 0; x--) { for (int y = 0; y < 5; y++) { int otherX; if (x + 1 > 4) { otherX = 4; } else { otherX = x + 1; WavefrontArray[otherX][y] = WavefrontArray[x][y]; } } return true; pixelsAwayFromGrid = 0; } else { return false; }}void main() { //something happens so you need to call the function if (CheckOffset() == true) { do some scanning } else { // or not }}
as for the other ideas about using a thumbdrive and harddrive . . . interfacing them requires a PC, negating the need for a microcontroller being the primary processor . . .
hmmmm thinking a bit more . . . when you shift the grid, new empty squares come in possibly giving a false clear path. will probably still need to use a large map to negate that possibility. and the other problem, way points. perhaps just count the travel distance, and then use other sensors to find the goal visually?