Xan's Phoenix Code

Lynxmotion Legged Robots
501

OK, that’s incredible: the Atrax works with the V2.0 code now! The IDE in use is now BMStudio 10014. In fact, I tried re-install the oldies 8.0.1.7 and 8.0.1.8 without any result. I tried to come back on the V1.3 with 8.0.1.8 too: no result any more!! Ow big deception! And finally on Basic Micro Studio 10014, I put away the 2nd “enable” in the 2nd bas file (phoenix_V20.bas I believe), then build and program. That goes well.

Now it’s time to reprogram the fangs, lights and gaits. I’let you show it in a cup of days. Fantastic!
Thanks for your help.

502

I’m using the new 2.0 code but need help with something.

I want the sensor to be able to scan when the head is turned right (one servo on pin 28) and when it’s turned left and when back in the middle again. in this way i can use one sensor to scan three sides.

Sensorinput: adin P19,scanrange ;Read sensor 1 value IF scanrange > 250 THEN Sound P9,[10\4000, 10\4000, 10\4000, 10\5000, 10\4000, 10\5000, 10\5500] serout cSSC_OUT, cSSC_BAUD, "PL0SQ", dec GPSeq, "ONCE", 13] ;Start sequence ENDIF RETURN

This will tell the GP-Player that when an object is near it has to turn its head right (500ms) left (1000ms) and back to the middle (500ms).

so now i want the sensor to scan when it’s at the middle first, to see if there’s an object in its way. Then move to the left, and scan again to see what’s there, and if there’s something on the left i want it to be able to do another sequence. For the right side the same thing.

Can anyone at least tell me how to pernounce this servo on pin 28 and it’s width? Like IF servo28pin > P1800 then GPplayer… or sensor.

and any other help is welcome!

503

im using V1.3 for a current project and i need to perfect the offsets of the servos as alignments are out, so instead of taking it apart and configuring the SSC for serial connection, is there a way i can add code so i can manually code the offsets though the Atom. kinda like how the PowerPod generated codes are written.

would something like this work?

;-------------------[Servo Offsets] serout SSC_OUT,SSC_BAUD,"#",dec | RRHipSwayPin,"po-90 #",dec | RRHipRotatePin,"po0 #",dec | RRHipZPin,"po-89 #",dec | RRKneeZPin,"po0 #",dec | RRAnklePin,"po80 #",dec | LRHipSwayPin,"po85 #",dec | LRHipRotatePin,"po0 #",dec | LRHipZPin,"po0 #",dec | LRKneeZPin,"po0 #",dec | LFAnklePin,"po0 #",dec | RFHipSwayPin,"po-90 #",dec | RFHipRotatePin,"po0 #", | RFHipZPin,"po89 #",dec | RFKneeZPin,"po0 #",dec | RFAnklePin,"po80 #",dec | LFHipSwayPin,"po85 #",dec | LFHipRotatePin,"po0 #",dec | LFHipZPin,"po0 #",dec | LFKneeZPin,"po0 #",dec | LFAnklePin,"po0",13]

and were would this be best placed in V1.3

thanks again.

504

Hi,

the best place for adding the offset should be in the CheckAngle function (or with a new function direct before it).
If you do this in the ServoDriver function you can damage your Servos.

EDIT:
Ok, little mistake from me. The values in CheckAngels are in degrees not as PWM.
You must implement it in ServoDriver.

serout SSC_OUT,SSC_BAUTE,"#",dec RFCoxaPin,"P",dec ((TOINT(TOFLOAT(-RFCoxaAngle +90)/0.10588238)+650 + RFCoxaCenter-1500) min 650) max 2350 ]
505

ok great thanks i will try this later this evening. :wink:

506

You could probably do it that way, which should work fine. Another approach would be for using a program to set the SSC-32 register offsets. The information about these registers is found: lynxmotion.com/images/html/b … m#ssc32reg

I have not done it this way yet for my Hex, but may. On my brat I have code that if I hold down a button while I power up, it enters a servo configure mode. In here I use buttons (or keyboard in some cases), to adjust the servos and then save away the zero positions… On the brat I do this into the EEPROM of the Bap28, but on the hex could use the hardware registers to do this…

Just a thought
Kurt

507

Ah, thats just brilliant Kurt!
I found the ReadServoOffsets function but couldn’t find the save part in your Brat code (I looked in the XBee version), did you share that part too?

508

Ooops actually in the brat I had a seperate program… I think Lynmotion may be using it now as well…
So many platforms so many different…

Kurt
mechbratsf.bas (7.95 KB)

509

I have used this as i meantioned before but iv placed it in [INIT]… works fine.
i didnt want to use registers as i didnt fancy messing with pins etc as my SSC is upside down and not easily accessible

anyway thanks guys.

510

Actually I was thinking you could simply have a basic program write these registers out for you. ie you don’t have to touch the board…

Simply serout the R command like you do with any other command. Registers 32-63 hold the offset values. so if you knew that the offset was supposed to be 5 for servo 0, you would do something like:
serout cSSC_OUT, cSSC_BAUD, “R32=”, dec Servo0Offset, 13]
This is assuming that the variable I had above was correct. You may have to also update R0 to enable these as well…

Well at least that is what I plan to do sometime soon, as I will be putting together a phoenix to go along with my CHR-3. But may again configure the phoenix one to use BAP EEPROM as it may be running on an Arc32… At least I was told it was in the mail :smiley:

Kurt

511

Thanks for sharing your servo offset finder program Kurt!

The ARC-32 in the mail! Awesome! 8)

512

I wonder how the ARC32’s are coming along production wise?

513

Me too.

The only information I have is what I have seen posted here and the latest post on Friday from “Basic Micro” up on the BM forum saying that he is has completed the document for the motor controller and was going to work on the Arc32 document ion over the weekend.

So hopefully they are getting close.

Kurt

514

Hi,

I’ve been doing alot of testing with Xan/Kurt’s XBEE version of the V20 code lately. There is especially one part that I’ve not been 100% satisfied with. If you look at this code:

[code];Sync BAP with SSC while walking to ensure the prev is completed before sending the next one
IF (GaitPosX(cRF) OR GaitPosX(cRM) OR GaitPosX(cRR) OR GaitPosX(cLF) OR GaitPosX(cLM) OR GaitPosX(cLR) OR |
GaitPosY(cRF) OR GaitPosY(cRM) OR GaitPosY(cRR) OR GaitPosY(cLF) OR GaitPosY(cLM) OR GaitPosY(cLR) OR |
GaitPosZ(cRF) OR GaitPosZ(cRM) OR GaitPosZ(cRR) OR GaitPosZ(cLF) OR GaitPosZ(cLM) OR GaitPosZ(cLR) OR |
GaitRotY(cRF) OR GaitRotY(cRM) OR GaitRotY(cRR) OR GaitRotY(cLF) OR GaitRotY(cLM) OR GaitRotY(cLR)) THEN

  ;Get endtime and calculate wait time
  GOSUB GetCurrentTime], lTimerEnd	
  CycleTime = (lTimerEnd-lTimerStart)/WTIMERTICSPERMS 

  ;Wait for previous commands to be completed while walking
  pause (PrevSSCTime - CycleTime - 45) MIN 1 ;	Min 1 ensures that there alway is a value in the pause command  
ENDIF[/code]

This code ensures that every step in the gait are finished moving before we start a new step. This works perfect when we are walking but I’ve discovered that when the robot are finished walking the pause command are sometime still beeing executed (very random), simply because one of the GaitPos/Rot <>0. When using the latest fast XBEE code the body rotation and translation part gets very choppy (not smooth) if this pause command are active. For some reason this wasn’t so visible when doing RC-control. I debugged all the GaitPos/Rot values and discovered that sometimes these values didn’t go to zero when the robot wasn’t walking, some of them halted to +/-1 or 2. The joystick was centered so that wasn’t the reason.

For avoiding this I rewrote this code a bit. I added two variables in the gait section:

GaitPeak var byte ; Saving the largest (ABS) peak value from GaitPosX,Y,Z and GaitRotY Walking var bit ; True if the robot are walking

Changes to the sync code in main loop:

[code];Sync BAP with SSC while walking to ensure the prev is completed before sending the next one
GaitPeak = 0 ;Reset
; Finding any incident of GaitPos/Rot <>0:
FOR LegIndex = 0 to 5
IF GaitPeak < ABS(GaitPosX(LegIndex)) THEN
GaitPeak = ABS(GaitPosX(LegIndex))
ELSEIF GaitPeak < ABS(GaitPosY(LegIndex))
GaitPeak = ABS(GaitPosY(LegIndex))
ELSEIF GaitPeak < ABS(GaitPosZ(LegIndex))
GaitPeak = ABS(GaitPosZ(LegIndex))
ELSEIF GaitPeak < ABS(GaitRotY(LegIndex))
GaitPeak = ABS(GaitRotY(LegIndex))
ENDIF
NEXT
IF GaitPeak > 2 THEN ;if GaitPeak is higher than 2 the robot are still walking
Walking = TRUE

  ;Get endtime and calculate wait time
  GOSUB GetCurrentTime], lTimerEnd	
  CycleTime = ((lTimerEnd-lTimerStart) * WTIMERTICSPERMSMUL) / WTIMERTICSPERMSDIV 
  ;Wait for previous commands to be completed while walking
  pause (PrevSSCTime - CycleTime) MIN 1 ;	Min 1 ensures that there alway is a value in the pause command  
ELSEIF Walking = TRUE ; Wait one more cycle before we leave the walking mode
  ;Wait for previous commands to be completed while walking
  pause (PrevSSCTime - CycleTime) MIN 1  
  Walking = FALSE

ENDIF[/code]
FIY, TRUE and FALSE are defined as 1 and 0 (const).

This code may not be very elegant but it works very fine for me though. Any suggestion for making this more effective would be appreciated. The GaitPeak variable might not be the best name since it doesn’t contain the largest value only the value that are higher than zero, hence the ELSEIF.

Edit: The pause command should be pause (PrevSSCTime - CycleTime - 45) MIN 1 ; for “normal” RC or PS2 use.

515

Howdy all,

I just got a chance to load up 2.0 Pheonix code and for some reason I cant get it to run right/
I have pastebin.com/ziXmU4UN <-- this code on it currently modified for the same pin configurations as the 2.0 code and I loaded it on and tested it, and it functions.

I load up the Pheonix_v20 project file
I see the cfg, the v20 code and diy-rc.bas loaded, When I hit program it loads all 3 and writes it.

I do see the ssc32 activity light blinking when its on so I know its receiving commands, I did test all 6 input pins with my RC test file that simply does a pulsin of all 7 channels and spits the data out via serout.

so It’s been a while since I had really poked around with my toy… I have the 1.0.0.15 version of Basic micro studio…

I’m convinced its something easy but who knows.

Thanks,
–Aaron

516

Bump:

Anyone available for help here?

517

you haven’t actually said whats wrong you just said its not working? are you getting any movement at all, is it not functioning properly? does the code seem to be running and responding to your rc inputs but your just not getting movement? why us an offsite lick to the code.? there may be something wrong with it. or maybe its the IDE?? :wink:

518

Howdy,
The phoenix doesn’t move, the servos do not appear to be powered.
The only thing it does do is when I use the right stick and push it all the way to the right it beeps once at me.
I’m not sure its the IDE, I don’t get any programming errors once I hit program although I could be wrong. I’m using .15 version of the Basic IDE so I’m not sure if that’s the correct one to use, it is the latest.

If you want me to post the 2 pages of code here I can do that :slight_smile:

I see the ssc32 activity light blinking when it is on, so I know its receiving commands… I’m kinda out of ideas personally.
But again I toss the code I put on pastebin on it, the thing works fine and I had modified the pins so they are identical to the new 2.0 code but still no love.

thanks,
–Aaron

The code is something Zenta sent me last year for RC phoenix usage with an un-modified T7C remote as someone requested it from him and he had shared it with me, I looked over the code and started adding and removing features along with making many changes to attempt to gain better knowledge on the code, and I added individual leg control, with an attempt to get the front and rear 2 legs to be controlled like chopsticks and pick something up although… long story… I’ll save that for another time

519

i see… well having read: I looked over the code and started adding and removing features along with making many changes to attempt to gain better knowledge
i feel this might be the problem. its very easy to miss something out or add something that should/shouldn’t be there.
why would you need to modify the code?

would i be right in thinking you are using 1.3 but have used segments from 2.0? :confused:
limp servos. can only mean three things:

1: batterys? guess you have checked this?
2: the function for HexOn is not established? (how are you getting the robot to its INIT pos?)
3: remove the (IF SSC_LM_SETUP) its not followed by Endif nor do you need it as you have only stated one arrangement for the pins.

520

Innerbreed,

This is not a problem. I have recompiled the 1.3 RC code zenta sent me atleast 100 times trying new things.

This is a silly question :slight_smile: … I mean its code… You always modify code… I modify code to learn so that’s what im doing :slight_smile:

I would love to do that actually although its more work then its worth at this point id rather add some things i came up with to the new 2.0 base and start there. but to answer your question No I’m not using 2.0 features in 1.3.

I have done all this in the 1.3 RC code
but if your asking about the 2.0 code I haven’t done this… I’m under the assumption you just hit program and it works, if I’m missing something then that’s why I’m here asking questions :slight_smile:.

but #3 – are you referring to the code I’m using or the 2.0 code?