Shop Learn
Next large robot - Page 31 — Parallax Forums

Next large robot



  • I think my coding notes are getting better, this is the fastest I’ve been able to review the code after a long break and figure out what I had been working on!
    Got the red RGB light issue figured out and resolved. This then exposed another unusual light pattern where a white light kept flashing intermittently on each leg. That one was harder to troubleshoot but increasing the buffer size on the P2 communications loop from the leg controllers solved that problem. The feedback data flow from the leg controllers was getting corrupted intermittently also so that was solved by adding code to the input routine to ignore inputs that didn’t have the proper start characters.
    I added in the Inverse Kinematics (IK) formulas I developed for the P2 along with trig routines that use integer math instead of Floating Point math in an effort to improve calculation speeds.
    Next on the agenda is testing the IK using a single leg and see if I can get it to move in a straight line!

    So far there is no danger that the robot will leave the basement on its own!

  • While testing the individual legs I was getting movements that indicated to me that the legs needed to be re-calibrated. When I would set the femur to 90 degrees the actual angle would be a bit over 100 degrees with similar results on the tibia.
    I tried my normal calibration routine and was getting no where, actually the physical angle positions were getting even further away from the expected positions. This morning I really got into the code math behind calculating the angles.
    The code first off determines the mathematical slope where the magnetic encoder output at the minimum and maximum angles are compared to the actual degrees the leg is at when at the minimum and maximum mechanical positions. This gives the slope of the line (assumed to be a linear function), or in terms of the program, how many counts of the encoder do you get for each angle change. When a move request is entered, the desired angle is supplied. This is used to calculate the target encoder value based on the slope. The motor is engaged and runs until it gets to the desired position. There is always some over- or under-shoot in this mechanical process so the next step is taking the final encoder value to calculate the actual angle the leg ends up at.
    With that information I found that I was using 2 different methods to get the target and the final position values. The difference was in whether I used the minimum or maximum physical angle value. Although mathematically it doesn’t make a difference, in code I was ending up with 2 answers that were close but not close enough.
    I fixed the code for the femur so next is fixing the tibia code to match. I’ve always seen small discrepancies but it isn’t until all legs are moving together that it became noticeable that each leg was moving to different positions.

  • I’ve been working on calibrating the legs which can be a tedious task. I wrote a calibration routine that makes it much simpler now which helps a lot.
    I started with leg 1 and worked my way around the robot, taking each leg in order. When I got to leg 3, I found the tibia motor was not responding. After some troubleshooting I removed the leg and put it on the bench for testing the motor. The motor would not turn even with voltage applied directly to the motor leads. So I removed the actuator from the robot and then disassembled the motor. The motor is a 12v brushed motor and I found the brushes were not contacting the rotor commutator. This required removal of the brushes and some filing of the nylon brush holders until the brushes were free to move again. Once the motor was reassembled, power was applied and the motor is working again. It appeared the nylon brush holders got overheated and constricted the brush movement. After this I was able to reattach leg 3 and finish the leg 3 calibration and moved on.
    I got to leg 5 and while calibrating the tibia encoder settings, I got a port 3 comm error when I tried to upload to RAM. A reboot and other tests determined the problem is on the Dell Win 10 computer side so have to figure that one out yet. I asked the question in the P1 forum side, hopefully someone has some ideas of how to proceed!
    I have seen the melted brush holder issue before and added coding to shutdown the motor controllers if it detects the motor encoder isn’t changing, don’t know if leg 3 is just showing an issue from before the code change or if it is recent. The motor wasn’t hot to the touch and the robot is suspended on the test stand so it wasn’t even supporting its own weight. I did some quick searches on-line for brushless linear actuators but didn’t see anything useful for my situation.
    I’m on hold for a bit until I get the Prop Tool to talk to the RoboPi boards again, hopefully it won’t take long to fix

  • msrobotsmsrobots Posts: 3,485

    if your motors get hot without load you have a torque/friction problem. How hard is it to move the legs w/o motors attached?

    WD40? :)

    As for the com port try to remove the entry in the device manager, windows does bs there sometimes...


  • @msrobots said:
    if your motors get hot without load you have a torque/friction problem. How hard is it to move the legs w/o motors attached?

    WD40? :)

    As for the com port try to remove the entry in the device manager, windows does bs there sometimes...


    What I meant was that I checked the motor temperature and it was cool. The legs weren’t touching the ground so there is no load on them. The legs move very easily when the motors aren’t attached, every pivot point has a bearing so there is very little friction on any of the motors. I’m speculating that the heat damage was caused a few months ago when I was still using a P1 as the master and had the full weight on the legs. Due to some of the testing the tibia movements resulted in locked motor rotors on a couple of legs. At that time only one motor failed, this motor may have been damaged and finally got to a failure point. In the meantime I added code to detect locked rotors by monitoring change to the encoder output. If the encoder doesn’t change by more than a value of 5 over 5 cycles of the PID routine, the PID loop is exited. This also accounts for situations where the actuator actuates an internal limit switch and stops.
    Thanks for the hint of checking the device manager and reset the com port there. I’ll give it a try next.

  • msrobotsmsrobots Posts: 3,485

    Well I am not a EE at all, I learn by burning things and not repeat it again.

    One could say that I am a fan of your project. In one of your posts your said 'all legs moving' that is quite a 'step' after just testing them alone.

    As for using the P2 as Central controller I think you are right, but I think there is no need to replace all the leg controllers, the P1 can handle that.

    This is a very cool project and I hope I can see this thing walking some time.

    GO, Bob, GO



  • Got the RoboPi P1 boards to talk to the computer again. Apparently the computer needed a full reboot vs just a restart. Anyway I’ve been able spend a few hours so far calibrating and fixing issues that have shown up. Got all but one fixed, the routine that is supposed to stop the motor if the magnetic encoder value doesn’t change (to prevent locked motor rotor issues and in the event the actuator activates its internal limit switch) is being triggered but the motor continues to run. In this case the motor angle position is 0 degrees and I want it to move to 52 degrees. PST shows the encoder output is not changing so this should stop the motor but the motor then runs until it actuates the actuator limit switch. Good puzzle to figure out!

  • Walked away from the code for a couple of hours and after coming back fresh, I almost immediately found one error. The tibia code was telling the femur motor to stop instead of the tibia motor! That fixed the issue where the tibia motor continued to run even after being told to stop.
    That left the problem where the tibia motor never doesn't start running because the encoder didn't show any motor movement. I determined this only occurs after changing motor direction, a clear indication of mechanical backlash in the linear actuator internal gear train. The fix was to add 50 msec to the PID loop. Since delay this is only necessary when the motor has reversed direction, I added a new flag that is set when the motor direction reverses and 50 msec is only added to the loop during the first loop. That solved both problems found earlier.
    One of the other things I have been working on is cleaning up the code to make it more readable and speed the code up. This requires adding more comments which help identify why some parts of the code are in there. I found myself removing some code that wasn't clear only to find out it's purpose later when testing. Not everything is immediately obvious as some code is needed because the computers are interfacing with mechanical systems which don't react as fast as the P1 can process. Good notes help reduce those mistakes!

  • Busy week, had some computer problems with the Prop Tool that took a bit of work to resolve. After some registry hacking fun, I was able to finally upload the latest code updates into all 6 leg controllers after finishing calibrating all the legs.
    Started reviewing my old notes on how to make the legs move using Inverse Kinematics (IK) again. When I've been at this point before I've just used IK to control a single leg, mainly testing routines to allow the leg to move in a straight line. Past issues with getting consistent straight line leg movement is what lead me to adding the magnetic encoders vs the original potentiometers to improve leg position resolution/repeatability. It also put me on the road to create PID-like software in the controllers to get better leg movements vs the earlier motor control coding.
    This leads to my current studies, how to get all 6 legs to move in a coordinated method so it can walk. To do that I have to combine each leg's coordinate system into a single coordinate system. The best way to do that is to imagine the center of the body as the 0,0 point of a X,Y grid. By moving the center of the body a given distance and angle, each leg will need to move the same distance and angle. This requires some precision starting measurements of the body to leg distances.
    Going back through the CAD files I got the dimensions of the base plate the legs attach to along with the additional distance to the coxa pivot point as the starting point. I decided to start working in millimeters (mm) instead of inches so I can work with whole numbers in the coding, which should make coding easier. So each leg is 250 mm distance away from the body 0,0 coordinate. Using this info and the fact the legs are 60 degrees apart, sine and cosine gave the body coordinates for each leg position.
    Next job is determining the formulas to convert a body position into each individual leg coordinate. I've studying some math examples to see how to apply the formulas to my setup. That pretty much brings you up to date with this weeks hexapod work. Hopefully by next week translating body to leg coordinates will be done and I can start coding that in for testing.
    As a side note, after finding the issue with the motor brushes melting, did some searching to see if anyone makes affordable brushless linear actuators. So far I haven't found anything I can afford, apparently brushless linear actuators aren't a common item. Of course even if I found them that would entail a lot of work to modify the robot to install along with needing new motor controllers vs the HB-25's I have.... Maybe some day it can be an upgrade!

  • PublisonPublison Posts: 12,200

    Good update. Go Bob!

Sign In or Register to comment.