@DiverBob said:
EDIT 2: Ever had a day when everything goes bad? Today was that day for me. I made what seemed to be fairly simple code changes, uploaded the changes and actually made the situation much worse!
That is a rather perfect description of my every day with my... let's call it... iterative coding style.
Couldn’t fix the random leg movements so I ended up removing the new code added to the individual leg controllers. Tested and now its back to its normal random leg movement during P2 startup.
Thinking it through, when the P2 is restarted with a new program, all the P1 controllers are already up and running. At this point they are in a loop waiting for a valid movement command from the P2 which is formatted like ‘$,xxx,xxx,xxx,x’. The leg controller software is supposed to reject any command that isn’t in this format.
The movement is happening during the P2 startup routine, where the RGB lights are started on their cog and the 8 port communications is started. It seems to be glitching right after the 8 port comm is initialized, I’m trying to figure out how to test this hypothesis next using the logic analyzer.
Another possibility is that the HB-25 motor controllers are getting some type of random pulse which would cause a motor to actuate. Unlike a servo, the HB-25’s only require a single pulse in the 1 to 2 millisecond range to activate and they stay activated until told otherwise. That scenario seems plausible as the motors tend to move to the fullest extent of travel when this happens. The motor that gets activated most often is the coxa motor, followed by the tibia and then femur. It is rare that more than one motor per leg is affected and typically 2 to 3 legs are affected. Once the P2 program completes its startup the software works as designed and I don’t see random movements.
Interesting but frustrating problem to solve so I can continue.
And just to make things a bit more interesting, 3 of the P1 controllers will allow me to upload the flash memory but I get a validation error when loading the EEPROM. I will swap out a P1 DIP chip and see if this still happens using a never previously used P1, pretty sure I have an extra P1 laying around…
Hm, could not find information about HB-25 on Parallax's site. I wonder if a pull down resistor at the servo pulse input might make sense to avoid pulses when the P1 output pin is in floating state? I would try 1k to GND.
Here I found a description of the back-emf speed measurement, that I meant in post #1076 : https://acroname.com/articles/back-emf-motion-feedback . I have used this kind of thing and I am impressed how well it works.
(((Please forgive me, that I repeat, that working with Forth would fit your experimental working style and this project so very well. You could try out things so very much faster. Also writing and immediately testing small building blocks of code from bottom up helps a great deal in my experience.)))
After trying various ideas at both the P2 master and P1 Leg Controllers, I gave up and reverted back to the previous saved revision for the P2 code. It ran fine without any of the extraneous leg movements I was seeing before.
Now I have to slowly copy over some of the critical code changes from the previous version and figure out what change actually started this mess!
I incorporated most of the code from the previous version into a new working version. Code is working fine with leg 1 moving in a straight line with little to no jerking. Still tweaking the variables to see how everything impacts each other. Right now the intermediate step distance is 10mm, intermediate step time is 30 milliseconds, on a step length of 200mm at 45 degrees.
I tested code for stopping the leg if the leg touches the ground before it reaches the commanded position. This test was successful.
Next tests include moving 2 to 3 legs at one time along a straight path based on the direction the centerline of the body is moving.
However before I carry on with the leg movements, I'm still figuring out where the random leg movements during P2 startup are coming from. The P1's are already up and running but when I upload a P2 update, during the startup of the P2 there are occasionally random movement of 1 or more legs. This is happening before the P2 code starts sending out commands. Once the P2 code is up and running there is no further random movements. The P1 controller code is supposed to reject anything not in the correct format.
The leg movement occurs during the port startup, so starting with commenting out the P2 comms setup to the P1's definitely stops any leg movement. Initializing the serial ports results in occasional movement. Since I am using the isp_octoport_serial.spin2, the first step is to define the 6 ports (.Addport). The movement comes during this process. (I commented out the serial port .start()). Review of the serial port Addport() code is mostly setting up variables and buffers for use. The last part of the Addport() is the smart pin setup for the serial ports. The smart pin setup is about the only spot that could be sending out these signals. Normally the next step after setup of the serial ports the start() method but I see movement even if the start() is disabled.
The P1 code needs to be checked out as serial inputs from the P2 that don't match the proper format should be rejected. It may be easier to just ensure that the bad input isn't being passed on to the motor controllers in the first place rather than trying to track down something related to the P2 SmartPin setup.
For my own remote motion MCUs, I adopted the protocol from the PICservo (the PDF I posted in this thread).
I have this on many factory production machines, running @230KBaud (overkill). It's rock-solid on 4-wire RS485.
I found it amusing that a young engineer, responsible for their CNC department, had only one question for me, after three years: "How come I never need to reboot your control?"
The command packets have the following structure:
Header byte (always 0xAA)
Module Address byte (0 - 255)
Command byte
Additional Data bytes (0 - 15 bytes)
Checksum byte (8-bit sum of the Module Address byte through the last additional data byte)
The Header byte is used to signal the beginning of a command packet. When waiting for a new
command, each module will ignore any incoming data until it sees a Header byte.
The Module Address byte is the address of the target module. The address can be an individual
address, or the group address for the module. (See Group Commands below.)
The Command byte is broken up into an upper nibble (4 bits) and lower nibble (4 bits). The lower
nibble contains the command value (0 - 15), and the upper nibble contains the number of additional
data bytes required for that command (0 - 15). It is up to the host to insure that the upper nibble
matches the number of additional data bytes actually sent.
The Additional Data bytes contain the specific data which may be required for a particular command.
Many commands have a “control” or “mode” byte in addition to other parameters required for the
command. Some commands require no additional data. It is up to the host to make sure that the
proper number of additional data bytes is sent for a particular command, and that the upper nibble of
the command byte is equal to this number.
Once a module receives a complete packet, and the Address byte matches its address, it will verify
the checksum and immediately (within 0.51 milliseconds) begin to process the command. If there is a
checksum error in the command packet or any other sort of communications error (framing, overrun),
If only a single PIC-SERVO controller is used, the PIC-SERVO’s communications port can be operated as an RS232
port, with TX and RX connected to an RS232 transceiver rather than to an RS485 transceiver. In this case, the
TX_ENABLE output is not used and may be left open.
the command will not be executed, but a status packet will still be returned. If there are no errors, the
command will then be executed and a status packet returned. (Note that motion commands will
initiate the motion and return a status packet immediately without waiting for the motion to finish.)
The status packets have the following structure:
Status byte
Additional Status Data bytes (programmable)
Checksum byte (8-bit sum of all the bytes above)
The Status byte contains basic information about the state of the module, including whether or not the
previous command had a checksum error.
I determined that the spurious signals are originating with the P2 smart pins when they are setup for serial use. Since there doesn’t seem to be any way to stop this from happening on the P2 side, I started working on blocking the signal coming into the P1 controllers. Since the P1’s are already up and running and looking for a signal from the P2, apparently my code was passing through the spurious signals. I confirmed that when I accidentally stopped responding to the P2 signals in the code. At that point the motors were not responding to anything the P2 was outputting. Now I know that the P2 serial input isn’t being interpreted correctly in all cases by the P1 code, I will be going over that part of the code and see what I can do.
Back to coding!
Got away for a bit so time to fix the last set of issues.
With the information I got from messing up the leg controller program, I narrowed down the spurious leg movement issue and re-wrote the leg controller serial input routine. I've run several tests and not once has any leg moved or twitched while the P2 is loading a new program. The only problem I saw was the controllers for leg #5 and #6 both failed the EEPROM verify when I tried to load the program update. There is no issue with loading RAM with the same program so not sure what is causing this.
Will be going back to my testing routine, this is a series of 12 test routines that that check every aspect of the leg controllers and P2 control system. Each leg is tested individually and as a group, each encoder is checked against expected values, the legdown sensor is verified, the ability to move a single leg in a straight line is the last test so far. This allows quicker testing of basic functions each time I make any fundamental code changes to the P2 or P1 programs. Moving a test leg in a straight line identified issues that had to be resolved and I think I am close to success now. I have been able to move the leg 200mm in a straight line, now I have to try different input angles and distances to determine if there are interference issues that I haven't thought about. One mistake I made in the mechanical leg design is that the tibia minimum angle is 0 degrees. This limits the full range of motion while walking since the leg tip can not bend underneath the leg at all. This means the total leg travel distance for some angles will be limited so walking will be slower than I originally thought. Fixing this problem involves having to machine new tibia motor mounting brackets. Unfortunately these were the most difficult to design and machine items since all sides of the bracket has to be machined.
Comments
Typically, the actuators would be disabled (no power) until the controller is fully initialized, loops closed and errors cancelled.
That is a rather perfect description of my every day with my... let's call it... iterative coding style.
Couldn’t fix the random leg movements so I ended up removing the new code added to the individual leg controllers. Tested and now its back to its normal random leg movement during P2 startup.
Thinking it through, when the P2 is restarted with a new program, all the P1 controllers are already up and running. At this point they are in a loop waiting for a valid movement command from the P2 which is formatted like ‘$,xxx,xxx,xxx,x’. The leg controller software is supposed to reject any command that isn’t in this format.
The movement is happening during the P2 startup routine, where the RGB lights are started on their cog and the 8 port communications is started. It seems to be glitching right after the 8 port comm is initialized, I’m trying to figure out how to test this hypothesis next using the logic analyzer.
Another possibility is that the HB-25 motor controllers are getting some type of random pulse which would cause a motor to actuate. Unlike a servo, the HB-25’s only require a single pulse in the 1 to 2 millisecond range to activate and they stay activated until told otherwise. That scenario seems plausible as the motors tend to move to the fullest extent of travel when this happens. The motor that gets activated most often is the coxa motor, followed by the tibia and then femur. It is rare that more than one motor per leg is affected and typically 2 to 3 legs are affected. Once the P2 program completes its startup the software works as designed and I don’t see random movements.
Interesting but frustrating problem to solve so I can continue.
And just to make things a bit more interesting, 3 of the P1 controllers will allow me to upload the flash memory but I get a validation error when loading the EEPROM. I will swap out a P1 DIP chip and see if this still happens using a never previously used P1, pretty sure I have an extra P1 laying around…
Hm, could not find information about HB-25 on Parallax's site. I wonder if a pull down resistor at the servo pulse input might make sense to avoid pulses when the P1 output pin is in floating state? I would try 1k to GND.
Here I found a description of the back-emf speed measurement, that I meant in post #1076 : https://acroname.com/articles/back-emf-motion-feedback . I have used this kind of thing and I am impressed how well it works.
(((Please forgive me, that I repeat, that working with Forth would fit your experimental working style and this project so very well. You could try out things so very much faster. Also writing and immediately testing small building blocks of code from bottom up helps a great deal in my experience.)))
After trying various ideas at both the P2 master and P1 Leg Controllers, I gave up and reverted back to the previous saved revision for the P2 code. It ran fine without any of the extraneous leg movements I was seeing before.
Now I have to slowly copy over some of the critical code changes from the previous version and figure out what change actually started this mess!
I incorporated most of the code from the previous version into a new working version. Code is working fine with leg 1 moving in a straight line with little to no jerking. Still tweaking the variables to see how everything impacts each other. Right now the intermediate step distance is 10mm, intermediate step time is 30 milliseconds, on a step length of 200mm at 45 degrees.
I tested code for stopping the leg if the leg touches the ground before it reaches the commanded position. This test was successful.
Next tests include moving 2 to 3 legs at one time along a straight path based on the direction the centerline of the body is moving.
However before I carry on with the leg movements, I'm still figuring out where the random leg movements during P2 startup are coming from. The P1's are already up and running but when I upload a P2 update, during the startup of the P2 there are occasionally random movement of 1 or more legs. This is happening before the P2 code starts sending out commands. Once the P2 code is up and running there is no further random movements. The P1 controller code is supposed to reject anything not in the correct format.
The leg movement occurs during the port startup, so starting with commenting out the P2 comms setup to the P1's definitely stops any leg movement. Initializing the serial ports results in occasional movement. Since I am using the isp_octoport_serial.spin2, the first step is to define the 6 ports (.Addport). The movement comes during this process. (I commented out the serial port .start()). Review of the serial port Addport() code is mostly setting up variables and buffers for use. The last part of the Addport() is the smart pin setup for the serial ports. The smart pin setup is about the only spot that could be sending out these signals. Normally the next step after setup of the serial ports the start() method but I see movement even if the start() is disabled.
The P1 code needs to be checked out as serial inputs from the P2 that don't match the proper format should be rejected. It may be easier to just ensure that the bad input isn't being passed on to the motor controllers in the first place rather than trying to track down something related to the P2 SmartPin setup.
For my own remote motion MCUs, I adopted the protocol from the PICservo (the PDF I posted in this thread).
I have this on many factory production machines, running @230KBaud (overkill). It's rock-solid on 4-wire RS485.
I found it amusing that a young engineer, responsible for their CNC department, had only one question for me, after three years: "How come I never need to reboot your control?"
Craig
I determined that the spurious signals are originating with the P2 smart pins when they are setup for serial use. Since there doesn’t seem to be any way to stop this from happening on the P2 side, I started working on blocking the signal coming into the P1 controllers. Since the P1’s are already up and running and looking for a signal from the P2, apparently my code was passing through the spurious signals. I confirmed that when I accidentally stopped responding to the P2 signals in the code. At that point the motors were not responding to anything the P2 was outputting. Now I know that the P2 serial input isn’t being interpreted correctly in all cases by the P1 code, I will be going over that part of the code and see what I can do.
Back to coding!
Got away for a bit so time to fix the last set of issues.
With the information I got from messing up the leg controller program, I narrowed down the spurious leg movement issue and re-wrote the leg controller serial input routine. I've run several tests and not once has any leg moved or twitched while the P2 is loading a new program. The only problem I saw was the controllers for leg #5 and #6 both failed the EEPROM verify when I tried to load the program update. There is no issue with loading RAM with the same program so not sure what is causing this.
Will be going back to my testing routine, this is a series of 12 test routines that that check every aspect of the leg controllers and P2 control system. Each leg is tested individually and as a group, each encoder is checked against expected values, the legdown sensor is verified, the ability to move a single leg in a straight line is the last test so far. This allows quicker testing of basic functions each time I make any fundamental code changes to the P2 or P1 programs. Moving a test leg in a straight line identified issues that had to be resolved and I think I am close to success now. I have been able to move the leg 200mm in a straight line, now I have to try different input angles and distances to determine if there are interference issues that I haven't thought about. One mistake I made in the mechanical leg design is that the tibia minimum angle is 0 degrees. This limits the full range of motion while walking since the leg tip can not bend underneath the leg at all. This means the total leg travel distance for some angles will be limited so walking will be slower than I originally thought. Fixing this problem involves having to machine new tibia motor mounting brackets. Unfortunately these were the most difficult to design and machine items since all sides of the bracket has to be machined.