Extra Commands

[BNNorman]

Whilst fiddling with the simulator I have added some extra commands/variables. Just thoughts

@name yields the name of the robot so that, in a console window, print statements can be prefixed by the name of the robot that is 'printing'. That makes it easier to tell who is talking. I don't know if your bots communicate back but hey, it helps.

POS - positions the robot at (I haven't added drag/drop yet). I suppose it could also be HOME then HOME on it's own could cause the robot to run home to mamma. There's an idea

DIR sets the direction the bot is facing - I use it with POS to put the simulated robot in a known place etc.

Wadaya think?

[CrazyRobMiles]

This is great stuff. Perhaps the best way to make @name work is to allow robots to assign to the variable and then have it stored in EEPROM so that when you read @name you get the robot name back. I was thinking of adding non-volatile storage by using a variable prefix such as # to identify a variable to be retained in the robot.

For the position I was going to add @x and @y as built in system variables which can be used to read the robot position in the playfield. These would be sent to the robot from a vision system tracking the robot, or perhaps less usefully, by using dead reckoning. We could also assign to them to put the robot in a known place. If we use POS we have to have some way ot dealing with compound variables, which we don't have at the moment.

I was also going to have an @angle variable that gives the angle of the robot from north.

On 13 March 2018 at 11:51, Brian notifications@github.com wrote:

Whilst fiddling with the simulator I have added some extra commands/variables. Just thoughts

@name https://github.com/name yields the name of the robot so that, in a console window, print statements can be prefixed by the name of the robot that is 'printing'. That makes it easier to tell who is talking. I don't know if your bots communicate back but hey, it helps.

POS - positions the robot at (I haven't added drag/drop yet). I suppose it could also be HOME then HOME on it's own could cause the robot to run home to mamma. There's an idea

DIR sets the direction the bot is facing - I use it with POS to put the simulated robot in a known place etc.

Wadaya think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HullPixelbot/HullOS/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/ADO8se5KXmzFP6XI0pZ60fKmvY-FpVppks5td7LQgaJpZM4Soi4O .

[BNNorman]

Let me know about @angle because the simulator uses standard EAST as zero and the PyGame display works clockwise not anti-clockwise. Within the simulator I can add any extra variables easily, as required. POS was just a command not a variable. Perfectly possible to use this to move the robot:-

SET X=200 SET Y=100 POS X Y

Then @X and @Y yield the current position.

Room for a chat on that.

[BNNorman]

Just a thought about direction. How about @COMPASS being plus or minus where positive values are clockwise from North and negeative are anti-clockwise from North in the range 0-180? @Angle could then be the normal value 0-360 anti-clockwise from East?

[BNNorman]

Hold on - just looked up compass headings - so should be zero North and 360 degrees clockwise to be standard.

[CrazyRobMiles]

I really like the idea of compass. Angle doesn't really tell me anything about what the angle is relative to. Whereas compass immediately starts me thinking about an angular displacement from north (which can be positive, negative or even greater than 360). It also makes me think of the robot as a little ship with a particular heading. Lets go with that. We can use div to bring the angle into a range 0-360. We need to decide whether setting a value in compass sets the current direction to be that compass value, or is a request to make the robot turn so that it is pointing in that direction. I quite fancy the latter, with a separate compass calibration command.

On 28 March 2018 at 14:45, Brian notifications@github.com wrote:

Hold on - just looked up compass headings - so should be zero North and 360 degrees clockwise to be standard.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HullPixelbot/HullOS/issues/4#issuecomment-376892038, or mute the thread https://github.com/notifications/unsubscribe-auth/ADO8scDUlXDgdDvrS_j6PYNi7YV5qOW5ks5ti5PmgaJpZM4Soi4O .

[BNNorman]

Commands like: COMPASS 180 (or HEADING 123 ?) and ANGLE 45 are easy enough as they would be handled similar to MOVE etc. Maybe COMPASS and HEADING could just be aliases for each other so the language could include both.