Absolutely!
If I remember rightly, it defaults to AD1 if you don’t specify a port.
However, (IMHO), I think it makes the code easier to read, easier to remember what the heck is going on, and easier for third parties to understand - if I always specify the port, even if it’s the default.
No - nothing that sophisticated.
I was running a Bloxter program something like
"While" [true] #Infinite loop
"Print" => "the IMU [aircraft heading]" on => "AD2" # heading in degrees
"Print" => "the IMU [compass heading]" on => "AD2" # values like "north", "south-east", etc.
# Implied "wend" statement because of the shape of the block
and then just let it run for a while, occasionally moving the robot around to see the readings change. If you don’t use a “sleep” block, it runs about every 0.5 or 0.25 seconds due to the built-in delay.
The closest I’ve gotten to “sophisticated” with Charlie is a program that moves Charlie forward until either:
- He comes within “x” distance of an obstacle.
- His front bumper hits something.
He then backs up for a second or two, randomly turns a number of degrees to either the right or left, and then continues.
He does no mapping. There is no instrumentation. No logs are kept, he just wanders around like a drunken robot until he gets too close to something, bangs into something or I kill his program at the web console.
It starts with a tight loop that tests the value of Charlie’s front bumper, waiting for it to go from “0” to “1”. Once it goes from zero to one, it jumps out of the loop and runs the rest of the program. This lets me start the program, place the robot on the floor, position it, and then tap the bumper to start the ball rolling.
Right now there are two random functions, one for angular rotation, (20 to 360) and the other for direction of travel. I’m thinking that I can do both in one random call by taking the integer value of the angular rotation and making it turn left if even and right if odd. Or, I just thought of this: constrain the angular rotation value to -360 to +360, and feed that directly into the command that makes Charlie turn.
One other thing I do is require a minimum amount of rotation, (I think ±20° to make sure he’s moved enough to avoid the obstacle by constraining the angular rotation to no less than 20.
This would be how I would do it if the rotation were constrained between -360 and +360:
(pseudo-code)
if (abs(degrees)) < 20
if (degrees < 0) # is the rotation angle negative?
degrees = degrees - 20 # then add an additional -20 degrees
else degrees = degrees + 20 # Otherwise the rotation is positive or zero
endif
endif
This is fairly complex for Bloxter.
Despite the fact that this is such an old and well known issue - and that there have been innumerable hardware/silicon updates since then - I cannot imagine for the life of me why this hasn’t been fixed?