[Dprglist] November Competition 2017

[John Swindle]

Carl,


Thanks. So the moves you described for each snapshot were from the current virtual nose (the yellow vertical mark at the bottom) to the last red X, neither of which have to be aligned to a tile. OK. If that is calculated as a single move, a heading and a distance, it could look like an undershoot, so it seems there need to be several moves per snapshot, maybe about as many moves as there are red X's in the simulation.


I like that you treat the tile outlines as noise, which is real-world, but for the contest, those outlines provide an opportunity to use a look-up table to match the image with the very limited number of valid tiles. Kinda like the camera looking at the Rubik's Cube. The LF tiles have more rotation freedom but a smaller set of possible images.

Doug,


If I use Bruiser, a standard RC car which is more than a foot long, it would have to leave the line and turn around to do the acute angle, which looks like an overshoot. After it had turned around, it would not be entering from the previous tile, nor the next tile, so I wonder what the "adjacent" element is in "If a robot overshoots or loses the line and recovers, its recovery course must take it through the adjacent element." Maybe the lesson is that line-following requires small platforms with differential steering. To me, differential steering seems unique to robotics, handicap transporters, and tanks, so it doesn't seem real-world to me.


Later,
John Swindle



-----Original Message-----
From: Carl Ott <carl.ott.jr at gmail.com>
To: John Swindle <swindle at compuserve.com>
Cc: doug paradis <paradug at gmail.com>; dprglist <dprglist at lists.dprg.org>
Sent: Tue, Nov 14, 2017 8:20 pm
Subject: Re: [Dprglist] November Competition 2017



Some feedback...


regarding:

Carl explained that his simulation defines a single move from the entry-point of the square, to the exit-point of the square, or more correctly, either the exit point of the current square to the exit point of the next square, or the entry point of the current square to the entry point of the next square.


sorry if I gave the wrong impression. Actually my approach treats the outlines of the squares as noise - it tries to filter them out or ignore them and follow "the real line"...


about:

the robot (a real physical one) does not actually have to follow curvature of the line: It just has to move from entry points to exit points.



I've understood the rules interpretation to be that it counts if you enter and exit the square with the line - although, it's not clear to me what that means e.g. if you have a very large robot that is following the line, but doesn't have an obvious part where 'this part of the robot has to stay w/in xyz distance of the line'...






For that reason, and others :) - I'm thinking that once I get physical - a cool extension would be a gimbal with a laser pointer that can light up the aim point...



about this



The first sentence says the robot follows a black line. I think the line color change tile was added after that first sentence was written. In any event, it's not always a black line.



giving the rules a little tech writing slack, it does mention this:




Which is interesting...  This suggests that the course could be reformed with any of those condition changes applied to any element. 
At least I've been targeting an algorithm that would handle such variation - 
of course, somebody will have to conquer the course first before somebody changes it...


- Carl




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20171115/989fda8c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 52307 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20171115/989fda8c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 70825 bytes
Desc: not available
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20171115/989fda8c/attachment-0003.png>