AppNotes.txt Application notes ================= 1.Ultrasonic scanning servo won't work 2.Battery goes flat when Hextor is switched off 3.Unplugging and replugging the LCD Pendant 4.Notes re direct use of the Bug Commander BOS 5.Robot seems to stumble 6.An Ultrasonic-Behaviour stops 7.Circuit debuging 8.MultiProgram notes 9.Display problems when using LCDkeys 10.How to talk to the BOS from a terminal or external computer 11.Program hangs on startup 1.Ultrasonic scanning servo won't work -------------------------------------- When using 'Hextor_8US.bsx' to test the Ultrasonics J6,7 must be set to ON for the scanning servo to work. The servos' supply is controlled by the BOS and the program does not use the BOS. 2.Battery goes flat when Hextor is switched off ----------------------------------------------- If the Gripper/Lift servos and the Ultrasonics-servo are jumpered to use unswitched power then they are always on, but they each only take 30 microamps when not being pulsed and so will have negligible affect on the battery. Move the jumper so they use switched power. Nicads will loose their charge naturally even when unplugged. Regular use of Hextor until the servos stop working and then charging the battery will keep it in top condition. 3.Unplugging and replugging the LCD Pendant ------------------------------------------- If you unplug the Pendant while Hextor is powered wait at least 10 seconds before plugging it back otherwise the display gets confused. Pressing the left hand 'Back' button several times will get you back from routines to OPTIONS which when displayed first clears the screen and writes OPTIONS and the buttons legend. If you still have a messy screen, unplug it wait 10 seconds and try again. 4.Notes re direct use of the Bug Commander BOS ---------------------------------------------- So that the Bug Commander BOS can be accessed directly the D9 connector is jumperable to either BS2sx portA pins 0 & 1 or direct to BOStx & BOSrx. Power to the electronics should be jumpered to always on and the BS2sx should be held in reset to avoid conflicts (use the ATN jumper and put it on the RESET header pins by the RESET switch). 5.Robot seems to stumble ------------------------ Although the servos are in themselves closed loop devices responding to pulse information sent to them by the servo co-processors the co- processors have no way of knowing whether or not a servo has actually reached the position encoded in the pulse stream, Consequently when the servos are operating under heavy loads, such as when the legs are at shallow angles or the servos are told to move fast, the position of a servo shaft may lag behind the desired position encoded in the pulse stream. In such cases the servo co-processor will report that the servo has reached its final position and the Behavioural Controller will start the next move before the servo has actually reached its desired position. The result is that the robot appears to stumble, if this is the case then putting a PAUSE between commands will give the servo time to catch up. 6.An Ultrasonic-Behaviour stops ------------------------------- The Ultrasonic-Behaviour routines can be interupted either by a Pendant button press or by an IR signal, sometimes the IR reception module gives out spurious signals which are interpreted as a valid user interuption and the program returns to command mode. If this is a problem set IRwatch to OFF(default). 7.Circuit debuging ------------------ If BS2 program hangs then it will be because the BOS876 is not ready, all other coms have time outs. Check the BOS876 is working by reseting and sending "V" to make a beep, if that doesn't work the chip is malfunctioning, beep only uses the serial coms pins and the beeper pin. If "V" works then send "w",, ie "w0",cr to "w15",cr (cr is RETURN). IF a servo CP is faulty then everything will hang at the particular servo group handled by the faulty chip, or chip connection tracks and resistors. There is no time out for coms to the SCPs the BOS program just keeps on asking until it gets a reply. 8.MultiProgram notes -------------------- The Ultrasonic-Behaviour program can be interupted by reception of an InfraRed command, since the program has no facility for processing IR commands it jumps to the program named in CommonRam0. The tellBOS subroutines have a line:- pause x 'give the BOS time to go into receive mode if you really want to speed things up (and I can't think why a few ms should matter) then reduce the pause time until the commands stop being received properly by the BOS, then increase it a little. In the tellBOSccc subroutines the pace time depends on the module used, for the E and SX a pace time of 1ms is sufficient but the faster P needs a pace time of at least 2ms otherwise sometimes the BOS can't keep up with the P. 9.Display problems when using LCDkeys ------------------------------------- If the battery is getting low then when a high current command such as 'U' up, is given the display can go blank and then show the startup screen. Just press the left hand key 'back' to return to the main menu then press 'DO' to go back to LCD keys. 10.How to talk to the BOS from a terminal or external computer -------------------------------------------------------------- It is possible to talk directly to the BOS chip using the D9 connector which is otherwise used for programming the Basic Stamp. Remove the jumper from J5 the Attn. line to the Stamp and put it on J12, which holds the Stamp in Reset. While the Stamp is in Reset all its pins are set to input so there can be no clash of data. By the D9 connector J1-4 connect the BOSchip to either the D9 or Stamp. Move both jumpers from Sx to the Term end of the headers. Communication is 9600baud 8 bits, no parity, 1 stop bit. Now when Hextor is turned on it will transmit "Bug Commander BOS 4.1, Milford Instruments" or similar and await user input, see the BOScmnds page. 11.Program hangs on startup --------------------------- If one of the Servo CoProcessors (SCP) is missing, not seated properly, or just not working, then the BOS will wait foreverfor a reply. The BOS waits for the SCP-Flow pin to be high. If an SCP is missing then the relevant pin on the BOS-PIC16F876 may float high allowing the program to continue until next time a response from the SCP is required.