Next large robot



  • Still no idea on what caused the battery voltage to drop. I’ve examined each component in the power system with no indication where the problem came from.

    So I spent some time Drawing up new electrical schematics with all the electrical changes that have been made. This gave me something to think about what on how to install the electrical system. I found some nice plastic backing material that is fairly rigid and lasers nicely.

    I made up a new electrical panel Design and after a few experiments, was able to cut out the board. Unfortunately the first board caught on fire and I didn’t notice until a whole corner of the board had melted. 2nd board came out fine, here it is right after the laser finished cutting.

    I added a a lot of labels to help identify wires in future troubleshooting sessions. I used a white screen printers ink to fill in the ‘cut out’ lettering and device outlines.

    Here is the board mounted across 2 sides of the hexapod battery level. With the smaller battery I now have lots of room for this style of layout. I am getting ready to start running wires now.

    Here is a different viewpoint of the battery level. The area on the right side is the fuse panel for motor power distribution. On the opposite side is the fuse panel for computer power distribution.

    Lots of wires to tie in and make everything pretty. I still have a couple of parts out on order so I won’t be able to finish it up tonight. Should get most of the basic wiring done so I can test everything.
  • Looking very professional, Bob!
  • Fun day wiring up and testing the new power panel. Here it is with the new wiring. Still need to put in some zip ties to tidy it up.
    Here is the back side of the panel. Lots of cleanup still needed here. These are all small wires from the Plug-in sockets.
    Tested the power system as each section was wired together to make sure I didn’t accidentally create any wiring errors. I have good power output to the motors and computers now. I had to put some epoxy on the sockets on the right side, the plastic panel is fairly thick and the laser makes the sides of the cutout slick so the sockets want to push them out when I plug into them. That’s what stopped tonight’s work as the epoxy needs to cure.
    Next step is machining some new access holes in the aluminum plate that is the top of the battery level. This is to provide better routing of the power cables up to the motor controllers and computers through the deck. Right now the power cables pass up through the middle of the plate and then fan out to the motor controllers. This just makes a mess/maze of wires on the motor level. The new holes will be along the outer edges of the plate making the wiring less messy.
    I finally realized that there were 2 sets of fuses in series going to the motor controllers. I believe I put some in-line fuses in originally before I got the dedicated fuse panel that I’m using for power distribution. Removing those fuses will help with the wiring simplification process.
  • During the wiring process I finally got the Lascar voltmeter panel re-programmed for lithium batteries and installed. That’s when I noticed that the battery was showing 14.24 volts with no load but as soon as I turned on the main key switch the voltage dropped to 13.9v. A considerable drop since it only powers up a 12v LED at that point. Turning on either the motor or computer supply with nothing connected except the relay and indicator LED on the switch dropped the voltage to 12.7v. Clearly there was a serious problem. After extensive checking I couldn’t find any wiring error that could cause the symptoms I was seeing so I started to suspect the battery itself. I removed the shrink wrap and made measurements directly from the battery terminals, upstream of the BMS. As I suspected, the actual battery voltage didn’t change as I turned the switches on and off. Pretty clear indication that I got a bad BMS board. Visual inspection didn’t show anything obviously wrong, I couldn’t feel any hot spots (maybe it’s time to get a thermal imager) either. I contacted the vendor and they agreed with my assessment and will send a new board as soon as they get new ones in (shipping delays due to COVID-19).
    I’m using the time to clean up some other wiring and fix a few things I always planned on getting around too but never found the time. Should have the power system re-wiring done in the next couple of days and then start re-assembly. I want to permanently mount the master computer and figure out a better mount for the 6 RoboPi computers. The RoboPi computers have only 2 mounting holes that are diagonal from each other so the boards are wobbly as I plug and unplug connections. This has resulted in stripping the tapped holes the nylon screws connect to, and the boards fall down. There has to be a better method of securing the boards. I think I could machine a plastic ‘box’ that holds the board by the edges and then attach the box to the wall.
    If I haven’t received the replacement BMS by the time I finish all that, I can temporarily bypass the BMS and run the robot directly off the battery. I don’t want to start drawing large loads on the battery without a functioning BMS to avoid damage to the battery.
  • Worked more on re-routing the computer and motor power wiring. Came to a standstill on that when I needed to crimp some Molex power connectors and realized the last time I crimped I borrowed a crimper from work. Since I’m retired that avenue isn’t available so I had to order a crimper to arrive next week. In the mean time I’m working on other robot related ‘fixes’ that need attention.
    First, came up with a better way to mount the RoboPi boards, a long standing problem.
    Using the laser cutter I cut a plastic frame the fits around the board. At the top and bottom are retaining strips of plastic that keep the board in-place.
    Here is what it looks like installed. The plastic frames are glued to the plastic outer skin panels.
    Next task was removing the master computer to drill and mount a centrally located eye bolt for attaching the rope safety harness while testing various leg routines. This requires the master computer to be moved so I mounted it next to the eye bolt and secured to the computer level deck. Not sure I like that location yet but it can be easily moved later if needed.
    Cleanup of the power wiring meant moving all the main wiring runs to the battery level and then up to the individual legs. With the lithium battery requiring much less space than the gel cell, there was room to move the 12v to 5v DC-DC Converter down to the battery level. Way in the back of the photo is the backside of the new power board. I moved the shunt back here as the spot on the front of the board had it interfering with the battery level plastic covers.
    Lastly, here is a view of the interior of the motor level, much cleaner less cluttered with wires running everywhere. Seems like a waste of space, at least until the coxa motors slide in there.
    Going to be mostly on hold until the crimper arrives. Then I can start re-assembling the legs and get back to programming again.
  • DiverBobDiverBob Posts: 794
    edited 2020-06-02 - 04:28:01
    Got the new crimper a few days earlier than expected so was able to put together the new power connectors to the motor controllers. Since everything looks nice a pretty now I put together a video walkthrough of the robot base in its present form. I also video’s putting all the legs back on but that takes 30 minutes and I could only change the speed by 2x with my software so I left that out.
  • just WOW.

    Love your attention to details.

    go Bob go...

  • Yeh! Got my replacement BMS board in the mail for the lithium battery. Got the old board off (found a crack through one of the components, probably the problem area!) and installed the new board. Initial tests were good, plugged it into the robot and no voltage drop when the robot main power enabled. Turned on and verified the motor power was on and all 18 motor controllers powered up with good voltages. Turned on the computer power switch and, nothing, no power to the computers. Verified power through the relay and to the 12v-5v converter bit the output voltage was reading about -1.4v. Then I realized the voltage was negative, quick check made me realize I had accidentally reversed the output power leads. Turned everything off and swapped the output wires, pulled all the fuses to the computers prior to turning it back on. Now I was getting the expected 5v output. Started adding the fuses one-by-one and watching the voltage. Got all the fuses back in and voltage was steady. Then I actually looked at the computers and not one of them had their power LED lit. I pulled each fuse again and saw that every fuse (2amp) had blown. I only had a couple of 5 amp fuses left so I put one in and that computer started backup. Checked 3 computers and they were all good. Thank goodness the fuses saved me from myself. I’ll get the right size fuses tomorrow and individually test each computer to make sure there aren’t any lingering effects.
  • Tested everything and I only had a problem with the #2 leg. The coxa motor wasn’t responding to commands. Loaded the leg test software and found the coxa encoder wasn’t responding. Removed the leg and bench tested it, found the encoder would respond as expected so the problem was between the leg controller and the encoder plug in. Did some more digging and finally found the Negative power pin to the encoder somehow got loose and wasn’t making a good connection. Once that was fixed the leg needed to be re-calibrated. Once that was done the leg was tested and now the coxa PID is oscillating, it overshoots the target, reverses itself and overshoots again, continuously.
    If it isn’t one thing it’s another! To late to investigate tonight, normally oscillations are caused by bad PID multiplication constants but changing the calibration should have no effect on PID operation.
    At least the new battery is working well! Plenty of power now.
  • Continuing the saga of finding an issue, troubleshooting to determine the cause, fixing, re-calibrating and then test. Today it was the coxa encoder on leg #1 wasn’t responding. After removing the leg was able to determine the solder connection on the encoder for the data output line was broken. Next stop is to re-solder that connection. No recalibration needed this time as I don’t have to disassemble the encoder setup.
    Earlier, after fixing the #2 leg coxa oscillations discovered a faster way to copy changes to the leg program to all 6 legs. Before I had leg specific values listed as constants and manually blocked out the constants that weren’t specific to the leg I wanted to copy to memory, very time consuming and easy to mess up. Since I have more memory available than I expected at this point, I just wrote a simple PUB routine with an IF statement that loads the correct global values based the specific leg number. Now all I have to do is change the leg number constant and load the program. I only need a single copy of the program now instead of 6.
    I also cleaned up the leg down sensor activation code. Originally the leg sensor sometimes activated but with little to no actual weight being applied so the leg stoped immediately but now the sensor isn’t activated. Added a time delay of of up to 175ms where the sensor is checked every 25ms for activation before the leg stops. This Time interval was determined by testing and making sure a leg didn’t travel so much where an adjacent leg could be lifted.
    I have noticed that the body is ‘tilting’, legs 5 and 6 are about an inch higher than the legs on the other side. Using the leg down sensors in the programming resulted in this difference occurring slowly over several days. I believe I have the Parallax 3 axis angle sensor in my toolbox, that can be incorporated to help identify when the robot body isn’t level and then the appropriate commands used to bring itself back level. Or, use the existing kinematics value for height to determine specifically which legs need to be lifted or lowered. Hmmmmm, maybe even a combination of both methods.....
    Was hoping to be able to video some simple robot movements based on earlier coding but problems jump up and have to get figured out first. Maybe later this week if I can catch a break! The wife and I will be traveling out west soon so won’t be able to get work on the robot for a few weeks.
  • RaymanRayman Posts: 11,349
    edited 2020-06-23 - 02:51:59
    Wow, what a beast! Almost 1000 lbs., is that right? Okay, I see like 200 lbs, right? Around weight of human...
    Looks like something boston dynamics would do...
  • Had another leg down sensor go on the fritz, it was reading as active with the leg 2 inches off the ground. Ended up disassembling the leg to check for broken wire/sensor but everything was coming up good electrically. Ended up putting everything back together and the problem disappeared on its own. However I saw that I was getting spurious leg down sensor activations with legs up, and when a leg was down the leg down signal would flicker also. This issue was affecting all the legs at one time or another so it was time to re-think the leg down sensor setup.
    For those who have been following this, the leg down sensor is just a flexible potentiometer wrapped around each robot foot and protected by a rubber cover. One side of the pot goes to +3.3v on the RoboPi computer board and the center pot connection goes directly into a P1 pin configured as an input. The program just checks if the pin is reading 1 which indicates the sensor is activated. Although it is simple, it seems to have some side effects that are troubling. Not just the inaccurate readings but also when the leg is raised it can take 2-3 seconds before the pin returns to a 0 value.
    To counter all this I went back to looking at using the RoboPi MCP3208 ADC as the input from the sensor. I wasn’t using the ADC as the previous driver code I used required a spare cog (none left to use now) to run, so I checked all my historical copies of 3208 drivers to see if one of those could be used. All but one I found required a cog (I could re-write a driver to not use a cog but that was an option for later), JonnyMac came to the rescue again! He has a great little Spin based driver that didn’t run in a cog. I had to do some surgery on the driver code as his driver is set up with the DO and DI pins connected together and the RoboPi has those pins hard-wired to separate P1 pins. After some quick tests using the Prop Experimenters board (love that board for these kind of situations!) I had a valid ADC value coming into the test board.
    I found the ADC input values were fluctuating even without touching of the sensor but it appears that if I test for a ADC value >500 then I can safely assume the leg is touching a surface. Removing pressure results in an immediate drop in the ADC output value so that is great also. I tested the sensor with just a connection to +3.3v and the P1 pin, the other sensor connection was left open instead of connecting it to ground so it matches the current setup (I didn’t really want to have to re-wire all 6 sensors if I didn’t need to). At this point I don’t really care what the actual ADC value is, just need to treat the sensor like a switch input.
    Tomorrow I’ll figure out how to incorporate this into the leg controller software and give it a whirl! I want to have this fixed before we leave on our trip, hate to have to remember where I left off when we come back.
  • Rayman wrote: »
    Wow, what a beast! Almost 1000 lbs., is that right? Okay, I see like 200 lbs, right? Around weight of human...
    Looks like something boston dynamics would do...
    I missed your comment earlier. Yes, it weighs in at around 190 right now!
    I wish I had Boston Dynamics resources and budgets! This would have been done years ago.
  • DiverBobDiverBob Posts: 794
    edited 2020-07-01 - 12:15:15
    Got the leg controller code updated and tested with the new leg down sensor input. Each leg has been uploaded with the new software so next step was to run through my battery of leg testing using the master computer. However the code uploads and when the Propellor tool gets into the ‘Verifying’ phase it throws an error that the serial port can’t be read. I shut everything down, restarted the desktop and am still getting the same results. Tried to search for options in the P1 forum but that search function there isn’t very good.
    I checked and I do have a spare Activity Board, I may plug that in later and see what that does. I didn’t run into any issues with updating the 6 individual RoboPi boards so I know my cables are good.
    Edit: The leg controller computers all work fine, it’s the master computer which is using a Propeller Activity Board that is failing to upload code.
  • We are back from our summer travels out west so it’s time to dive back into the robot again. I had to re-read several of my past posts to see where I left off this time. It looks like the master computer is a problem now so have to figure out that one out.
    I decided to replace the master computer as it was running kind of slow going through all the Kinematics equations when moving the legs. That required me to have it do fewer calculations but the leg movements were getting jerky. Anyway, the P2 chip has come a long way and lots of tools are available for it so i ordered the Rev C evaluation board and am planning on spending some time learning how to program it. I still need a floating point engine with sin, cosine and tan and the ability to run multiple serial ports, not sure anyone has done anything like that yet but I’ll see what’s out there.
  • Looks like bigger is better, that's a pretty big robot
  • AwesomeCronkAwesomeCronk Posts: 983
    edited 2020-09-13 - 01:25:45
    I once wrote a python library for sin cos and tan That you might find useful. I’ll see if I can find a copy of it, because I did it from scratch. I ended up using a Taylor Series for sin and calculating cos and tan from sin and cos. For their inverses, I brute forced the answers and checked them against their base function. 😝
  • AwesomeCronkAwesomeCronk Posts: 983
    edited 2020-09-13 - 02:49:33
    I found the python code for the trig functions! I wrote it so that it is accurate to however many decimal places is defined in the 'terms' variable.
    from decimal import Decimal
    degrad = 'deg'
    pi = 3.141592653589793238462643383279
    terms = 9    #number of terms used for the trig calculations
    def radtodeg(radin):
        return radin * (180 / pi)
    def degtorad(degin):
        return degin * (pi / 180)
    def sin(anglein):    #working
        if degrad == 'deg':
            return rawsin(degtorad(anglein))
            angle = anglein
            return rawsin(angle)
    def arcsin(ratioin):    #not working
        if ratioin > 1 or ratioin < -1:
            return False
            attempt = Decimal('0')
            target = Decimal(str(ratioin))
            for i in range(-2, terms + 1):
                print('Editing place {0}'.format(10 ** -i))
                for j in range(10):
                    if Decimal(str(sin(float(attempt)))) == target:
                        print('angle found.')
                        return attempt
                    if Decimal(str(sin(float(attempt)))) < target:
                        attempt += (Decimal('10') ** -Decimal(str(i)))
                        print(attempt, end = ' ')
                    if Decimal(str(sin(float(attempt)))) > target:
                        attempt -= (Decimal('10') ** -Decimal(str(i)))
    def cos(anglein):    #working
        if degrad == 'deg':
            return rawsin(degtorad(90 - anglein))
            angle = anglein
            return rawsin(90 - angle)
    def arccos(ratioin):    #working, sometimes
        if ratioin > 1 or ratioin < -1:
            return False
            attempt = Decimal('0')
            target = Decimal(str(ratioin))
            for i in range(-2, terms + 1):
                for j in range(10):
                    if Decimal(str(cos(float(attempt)))) == target:
                        attempt *= -1
                        while attempt > 180:
                            attempt -= 180
                        if attempt == Decimal('-0'):
                            attempt = Decimal('0')
                        if degrad == 'rad':
                            return attempt
                        if degrad == 'deg':
                            return radtodeg(attempt)
                    if Decimal(str(cos(float(attempt)))) < target:
                        attempt += (Decimal('10') ** -Decimal(str(i)))
                    if Decimal(str(cos(float(attempt)))) > target:
                        attempt -= (Decimal('10') ** -Decimal(str(i)))
    def tan(anglein):    #working
        a = sin(anglein)
        b = cos(anglein)
        if (not a == 0) and (not b == 0):
            return a / b
            return False
    def arctan(ratioin):    #not working
        if ratioin > 1 or ratioin < -1:
            return False
            attempt = Decimal('0')
            target = Decimal(str(ratioin))
            for i in range(-2, terms + 1):
                for j in range(10):
                    if Decimal(str(tan(float(attempt)))) == Decimal(target):
                        return attempt
                    if Decimal(str(tan(float(attempt)))) < target:
                        attempt += (Decimal('10') ** -Decimal(str(i)))
                    if Decimal(str(tan(float(attempt)))) > target:
                        attempt -= (Decimal('10') ** -Decimal(str(i)))
    def rawsin(angle):    #return the result of sine of the supplied angle, using radians
        angle %= 2 * pi
        if angle > pi:
            angle -= 2 * pi
            if angle < -(pi / 2):
                angle = -pi - angle
        elif angle > pi / 2:
            angle = pi - angle
        final = 0
        den = 1
        for i in range(1, 2 * terms + 2, 2):
            den *= i
            final += (angle ** i) / den
            den *= -(i + 1)
        return final

    As you can see by the comments, I couldn't ever get the arc-trig functions working. I wrote their functions sort of minimax-esque. They start in the hundreds' place and for ten iterations, they compare their input against what their base functions return for their attempted result. They then modify their attempt as needed, marching from the hundreds place down to however many decimal places are defined in the 'terms' variable. For some reason I could never get them to register that they had a match, so they always printed out the entire minimaxing process and never returned anything. I hope you find this useful!
  • I once wrote a python library for sin cos and tan That you might find useful. I’ll see if I can find a copy of it, because I did it from scratch. I ended up using a Taylor Series for sin and calculating cos and tan from sin and cos. For their inverses, I brute forced the answers and checked them against their base function. 😝

    Thanks for the code! I spent some time yesterday reading up on the P2, lots of info out there but not well organized at this point. There are several languages available for use, I will probably start with the new version of Spin and see how that goes first. Next step is to figure out where and how to download the code, it isn't as straight forward as it used to be, I've never had a need to use GitHub so there's another new thing to learn....
  • Happy to help!
  • Time for another update! I’ve been studying the P2 processor and playing around with some simple programming on it. There isn’t a floating point library made up for it yet so I started looking into using a table-based approach for the trigonometric calculations. To make things faster I will do everything as integer math so a normal cosine value like 0.8663 will be handled as integer 8663. That should go a long way towards improving processor speed.
    Another item that I need is the ability to run several independent serial ports, each leg controller has its own send/receive connection to the master. The P2 has smart pins which can be configured as serial ports, right now I’m just learning how to use them just using a single port to a terminal. I need to figure out how to set it up for 6 separate ports.
    I had to totally disassemble the robot as I sold my big 12x36 gunsmith lathe. The robot was setup right in front of the lathe so needed to move it out of the way for when it gets picked up this week. I’m going to miss the lathe but I haven’t really needed a lathe that large for a while and with no new projects planned for a while, I decided recovering the space is more important. I can see getting a much smaller lathe later, they are just too handy to have around just for making parts.
    This has been a slow month for work on the robot with little forward progress but it is continuing. As the weather here gets colder and outdoor chores close down for the winter I’ll be spending more time on hobby related projects.

  • I haven't looked at your code but, will the CORDIC unit help with your trigonometric calculations?
    It can rotate coordinates and convert between polar and cartesian systems.
Sign In or Register to comment.