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.
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.
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.
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.
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.
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.
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.
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. 😝
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))
else:
angle = anglein
return rawsin(angle)
def arcsin(ratioin): #not working
if ratioin > 1 or ratioin < -1:
return False
else:
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)))
print(attempt)
def cos(anglein): #working
if degrad == 'deg':
return rawsin(degtorad(90 - anglein))
else:
angle = anglein
return rawsin(90 - angle)
def arccos(ratioin): #working, sometimes
if ratioin > 1 or ratioin < -1:
return False
else:
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
else:
return False
def arctan(ratioin): #not working
if ratioin > 1 or ratioin < -1:
return False
else:
attempt = Decimal('0')
target = Decimal(str(ratioin))
print(type(target))
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....
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.
I’m studying the discussion at: https://forums.parallax.com/discussion/88799/some-cordic-documentation/p1. This is a good discussion on CORDIC and I’m working at understanding what is being discussed. I haven’t looked at the CORDIC unit itself, is that in the P2 code repository?
In the meantime I have some code used by many hexapods, Phoenix.bas, that uses integer math and table-based sine/cosine. I copied the sine table into the Propellor Tool and converted the code to Spin. Limitations include that it works in 0.5 degree increments, I want to see if I can use linear interpolation to get 0.1 degree increments instead. The sine part seems to be working OK, need some work on the interpolation still. The cosine part isn’t even close so I need to figure out where I’m making my coding mistake. Also need atan but most of the reading I’ve seen so far indicates I can calculate that from the sine/cosine values.
I got JonnyMac’s simple serial unit to work so I’m using that for debugging. Chip wrote a great debug unit for the P2 but it only works on Pnut at this time. I understand they are going to incorporate it into the P2 Propellor Tool at some point, that will be very helpful.
Haven’t spent much time figuring out how to run multiple independent serial devices yet. Haven’t seen anything like the 4 port serial units that the P1 has in the library.
I’m studying the discussion at: https://forums.parallax.com/discussion/88799/some-cordic-documentation/p1. This is a good discussion on CORDIC and I’m working at understanding what is being discussed. I haven’t looked at the CORDIC unit itself, is that in the P2 code repository?
In the meantime I have some code used by many hexapods, Phoenix.bas, that uses integer math and table-based sine/cosine. I copied the sine table into the Propellor Tool and converted the code to Spin.
If you have some BASIC code already, you might be able to compile it with FlexProp (which supports BASIC as well as Spin2 and C). It could save you some work. For that matter if you write your code in BASIC you can just use floating point directly (declare variables like "dim x as single") and use the built in sin and cos. If you still find the floating point too slow, FlexBASIC has a --fixedreal option which uses 16.16 fixed point in place of IEEE floating point.
For sin/cos on the P2, you definitely will want to use the hardware CORDIC instructions rather than trying to use tables or a Taylor series; the hardware instructions are fast and reasonably accurate. Here's a snippet for calculating sin() with the CORDIC on P2. It's in C, so you can use it directly in FlexProp, but translating to Spin2 should be easy:
#define PI 3.14159265f
#define PI_2 1.570796327f
#define FIXPT_ONE 1073741824.0f /* 1<<30 */
#define PI_SCALE (FIXPT_ONE / (2.0f*PI))
/*
'
' calculate sin(x) where x is an angle in
' 2.30 fixed point, where a whole circle (2pi) is
' 1.0
' returns a value from -1.0 to +1.0, again in 2.30 fixed point
'
*/
int32_t _isin(int32_t x)
{
int32_t cx, rx, ry;
x = x<<2; // convert to 0.32 fixed point
cx = (1<<30);
__asm {
qrotate cx, x
getqy ry
}
return ry;
}
/* calculate floating point sin(x), where x is in radians */
float sin(float x)
{
float s;
x = x * PI_SCALE;
s = _isin(x) / FIXPT_ONE;
return s;
}
float cos(float x)
{
return sin(x + PI_2);
}
Thanks for the ideas on Cordic. I’m not a C programmer so I’m sure there are some nuances in there I’m not fully understanding just yet. This inspired me to search on P2 Cordic and came up with an old thread “ https://forums.parallax.com/discussion/127241/cordic-for-dummies/p1” that has a great explanation on what Cordic means and how it is calculated. I’m going to try out Bean’s code and see how fast it is at calculating sin/cos/tan. I like the way he set it up to use integer math and using +,-, and shifts to get the values.
You discussed the P2 hardware cordic instructions, are you talking about the Math Methods? I saw the Math Methods in the Spin document. There is a QSin and QCos method but I was unable to locate any examples on how these could be used. I’ll have to put together some simple routines to see how these work. Based on the description it appears that it takes a length value and an angle value which is rotated around a circle to give either the X or Y Cartesian coordinate.
You discussed the P2 hardware cordic instructions, are you talking about the Math Methods?
I was referring to the hardware (PASM) instructions. The P2 can do Cordic in hardware, there's no need to implement software versions of trig functions (or they can just be small shims that use the hardware to do this). For example, the qrotate instruction in the __asm section of the C code I posted above basically calculates the sin of a fixed point number.
Chip has exposed most of these in Spin2, so if you don't want to use assembly (even inline assembly, which is available on P2) you won't have to.
By far the easiest way to do trignometry on the P2 would be to use a language like BASIC or C that has floating point built in. Then you can do all your math using familiar operations, and use the built in sin(), cos(), etc. functions (which probably use the hardware; FlexProp does, at least).
Thanks for the further explanation. Since I am most familiar with programming using the Propellor Tool I was trying out using it and the Math Methods described in the P2 documentation. I was attempting to use the QSin math method but the propellor tool tells me that its not an expression term. I haven’t been able to locate any example code showing its use either.
So it looks like I need to break down and try out the FlexProp GUI! Something new to learn how to use. I’m still pretty new to the P2 programming and setup, it’s so similar to the P1 that the differences are what reach out and catch you off guard.
PropellerTool is not up to date yet, you need to use Pnut or FexPropGUI/Flexspin however it is called now.
Since your code is Spin1 right now Eric's solution might be better for you because you can compile Spin1 code for the P2, except PASM that needs to get replaced.
Spin2 is slightly different from Spin and that bites you sometimes, but I think most of your Spin code should run on a P2 well.
I wrote a two port serial driver with buffers in the lut ram, but JonnyMac has a more flexible solution posted able to use a variable number of serial ports out of one cog, I have not tested it, but it will possible solve your Master to client communication, his code is usually excellent to read and understand.
Mike, I agree that the Propellor Tool for P2 still needs some work. I downloaded FlexProp today, now reading the documentation and start playing with it. I really like JonnyMac’s code, I use it in the the master and leg controllers. I was trying out his SimpleSerial code on the P2 for debugging information since Chip’s Debug code appears to be only installed in Pnut so far.
It sounds like FlexGUI has floating point built in to the C and Basic sections, unfortunately I’m not familiar with C and never learned VB, haven’t had the need to learn it when I was working in IT. That will make it more exciting to start converting my master P1 code over to the P2.
The interesting part of fastspin is that you can write multilangual programs, so you can write in Spin and use a C or basic 'object' to do floating point and return the result.
Comments
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.
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.
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.
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.
Love your attention to details.
go Bob go...
Mike
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.
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.
Looks like something boston dynamics would do...
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.
I wish I had Boston Dynamics resources and budgets! This would have been done years ago.
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.
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.
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)) else: angle = anglein return rawsin(angle) def arcsin(ratioin): #not working if ratioin > 1 or ratioin < -1: return False else: 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))) print(attempt) def cos(anglein): #working if degrad == 'deg': return rawsin(degtorad(90 - anglein)) else: angle = anglein return rawsin(90 - angle) def arccos(ratioin): #working, sometimes if ratioin > 1 or ratioin < -1: return False else: 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 else: return False def arctan(ratioin): #not working if ratioin > 1 or ratioin < -1: return False else: attempt = Decimal('0') target = Decimal(str(ratioin)) print(type(target)) 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 finalAs 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!
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....
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.
In the meantime I have some code used by many hexapods, Phoenix.bas, that uses integer math and table-based sine/cosine. I copied the sine table into the Propellor Tool and converted the code to Spin. Limitations include that it works in 0.5 degree increments, I want to see if I can use linear interpolation to get 0.1 degree increments instead. The sine part seems to be working OK, need some work on the interpolation still. The cosine part isn’t even close so I need to figure out where I’m making my coding mistake. Also need atan but most of the reading I’ve seen so far indicates I can calculate that from the sine/cosine values.
I got JonnyMac’s simple serial unit to work so I’m using that for debugging. Chip wrote a great debug unit for the P2 but it only works on Pnut at this time. I understand they are going to incorporate it into the P2 Propellor Tool at some point, that will be very helpful.
Haven’t spent much time figuring out how to run multiple independent serial devices yet. Haven’t seen anything like the 4 port serial units that the P1 has in the library.
If you have some BASIC code already, you might be able to compile it with FlexProp (which supports BASIC as well as Spin2 and C). It could save you some work. For that matter if you write your code in BASIC you can just use floating point directly (declare variables like "dim x as single") and use the built in sin and cos. If you still find the floating point too slow, FlexBASIC has a --fixedreal option which uses 16.16 fixed point in place of IEEE floating point.
For sin/cos on the P2, you definitely will want to use the hardware CORDIC instructions rather than trying to use tables or a Taylor series; the hardware instructions are fast and reasonably accurate. Here's a snippet for calculating sin() with the CORDIC on P2. It's in C, so you can use it directly in FlexProp, but translating to Spin2 should be easy:
#define PI 3.14159265f #define PI_2 1.570796327f #define FIXPT_ONE 1073741824.0f /* 1<<30 */ #define PI_SCALE (FIXPT_ONE / (2.0f*PI)) /* ' ' calculate sin(x) where x is an angle in ' 2.30 fixed point, where a whole circle (2pi) is ' 1.0 ' returns a value from -1.0 to +1.0, again in 2.30 fixed point ' */ int32_t _isin(int32_t x) { int32_t cx, rx, ry; x = x<<2; // convert to 0.32 fixed point cx = (1<<30); __asm { qrotate cx, x getqy ry } return ry; } /* calculate floating point sin(x), where x is in radians */ float sin(float x) { float s; x = x * PI_SCALE; s = _isin(x) / FIXPT_ONE; return s; } float cos(float x) { return sin(x + PI_2); }You discussed the P2 hardware cordic instructions, are you talking about the Math Methods? I saw the Math Methods in the Spin document. There is a QSin and QCos method but I was unable to locate any examples on how these could be used. I’ll have to put together some simple routines to see how these work. Based on the description it appears that it takes a length value and an angle value which is rotated around a circle to give either the X or Y Cartesian coordinate.
Chip has exposed most of these in Spin2, so if you don't want to use assembly (even inline assembly, which is available on P2) you won't have to.
By far the easiest way to do trignometry on the P2 would be to use a language like BASIC or C that has floating point built in. Then you can do all your math using familiar operations, and use the built in sin(), cos(), etc. functions (which probably use the hardware; FlexProp does, at least).
So it looks like I need to break down and try out the FlexProp GUI! Something new to learn how to use. I’m still pretty new to the P2 programming and setup, it’s so similar to the P1 that the differences are what reach out and catch you off guard.
Since your code is Spin1 right now Eric's solution might be better for you because you can compile Spin1 code for the P2, except PASM that needs to get replaced.
Spin2 is slightly different from Spin and that bites you sometimes, but I think most of your Spin code should run on a P2 well.
I wrote a two port serial driver with buffers in the lut ram, but JonnyMac has a more flexible solution posted able to use a variable number of serial ports out of one cog, I have not tested it, but it will possible solve your Master to client communication, his code is usually excellent to read and understand.
Enjoy!
Mike
It sounds like FlexGUI has floating point built in to the C and Basic sections, unfortunately I’m not familiar with C and never learned VB, haven’t had the need to learn it when I was working in IT. That will make it more exciting to start converting my master P1 code over to the P2.
Anyways, have fun!
Mike