Xan's Phoenix Code

[innerbreed]

forgive me but im confused as to what version you are using. you explained you have uploaded v2.0 and are having problems with it, but you posted v1.3 in your link?

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.

try loading up a current original code first. does it work?

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

im with you about this, but i mean to ask what are you trying to do except individual leg control for two legs at once?
if this is the only thing you wish to do, i think opening up a thread on it would be good.

[likwidchz]

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.

Quoting myself from the beginning,
I take the new .15 IDE and program my old code to test to see if it still functions “It works” then I load up the 2.0 code and program and it does not function. I have not made any changes to anything within the 2.0 code.

The 2 leg control bit, go ahead and put a pin on that idea, I would rather just get 2.0 working first, then once I know it works I’ll break it multiple times learning how to do what I want to do later.

–Aaron

[innerbreed]

ok with ya bud.
try using IDE v8.0.1.8 and not BASIC Micro Studio. it may have something to do with this. maybe it compiled the 3 sections of the code, but in the wrong order? just trying the obvious here.

Project file order:
1. Phoenix_cfg.bas
2. Phoenix_V2x.bas
3. Phoenix_Control_xxx.bas

i cannot think of any other reason as to why 2.0 wouldnt work and 1.3 does. ill keep thinking for you.

[likwidchz]

I have Basic Micro Studio .15 and the older version 8.0.0.17 installed same outcome using both software versions.

I’m out of ideas to lead to solutions at this point.

–Aaron

[zenta]

@LikWidChz

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.

Hi,

If I’ve understood you correctly you’ve not done any changes to the V20 code?
To make it work with your futaba RC the control file must be modified or it won’t work for you. The phoenix_control_diy-rc.bas won’t work with your futaba without any modifications.

[likwidchz]

Thanks zenta,

I see some odd variables in this code

IF Buttons = 0x0A and LastButtons <> 0x0A THEN ;A Button Walk Mode

I’m guessing that remote that this code works with was the ultimate remote that was being worked on last year with that Spektrum inside it along with the BB2?

If that’s the case I’ll start dissecting the code I posted above for button/movement assignment.
Since I do not have an on off switch via wireless I see the Hexon = 1 I believe I’ll need to have this set on automatically. I think this is the same thing you did in the 1.3 code I posted above in the pastebin link

This looks to be a good challenge to get in this again.

–Aaron

[zenta]

@LikWidChz

I’m guessing that remote that this code works with was the ultimate remote that was being worked on last year with that Spektrum inside it along with the BB2?

Thats correct. The main difference is that the 7.channel are used for sending the keypad commands. Setting the HexOn = 1 would be a good start.

[likwidchz]

Fantastic…

I believe channel 7 is the toggle switch on the top right of the T7C?

I would just have to duplicate what you did originally to select modes with the toggle switch like a piece of code that keeps track of how many times the toggle switch is pressed to loop though modes 1 - xyz

[zenta]

Sounds like you are on the right track. Good luck with the coding!

[likwidchz]

Howdy Zenta “Or to anyone who might know how to assist me”

I spent some time after work this evening looking over the code and I think Ive run into a simple hurdle I cant seem to figure out.
The goal is simply to get the bot standing when I turn it on.

What all do I need to set specifically in the code so that it thinks I have a remote and everything is on and awaiting movement instructions… I’m guessing this is going to be pretty easy although other then Hexon = 1 " I don’t know whats causing it not to stand up at all the normal initialization values as the 1.3 code.

Also

Are my choices for AwPulsesIn(0) - AwPulsesIn(6)… 0 being channel one and 6 being channel seven?

Thanks,
–Aaron

[zenta]

Hi,

I’ve done some more work on the Phoenix code based on Kurt’s hacked XBee/binary SSC version of Xan’s V20 code. I decided to post the code in Kurts DIY Remote Control XBee controller for Robotics thread.

I’ve tried to summarize what changes that have been done by Kurt and me:

;NEW IN V2.1k ; - Added XBee control and fast serial mode (Kurt) ; - Added binary mode for SSC32 (Kurt) ; - Inverted X direction in single leg mode (Kåre) ; - Modified sync part between BAP ans SSC while walking (Kåre) ; - Removed different gait types (Kåre) ; - Added constant (later variable?) for BalanceDiv Factor, other values then 6 can be used. ; - Moved GaitInMotion calc to the GaitSeq sub

You can read all about Kurt’s XBee and binary SSC control work in his thread
There was a minor fault in the single leg control when controlling the left side legs. So I’ve just inverted the X-direction. A little snip from the SingelLegControl sub:

ELSEIF (NOT SLHold) LegPosY(SelectedLeg) = cInitPosY(SelectedLeg)+SLLegY IF (SelectedLeg>=3 AND SelectedLeg<=5) THEN ;Invert X direction for the left legs LegPosX(SelectedLeg) = cInitPosX(SelectedLeg)-SLLegX ELSE LegPosX(SelectedLeg) = cInitPosX(SelectedLeg)+SLLegX ENDIF LegPosZ(SelectedLeg) = cInitPosZ(SelectedLeg)+SLLegZ ENDIF

I recently posted info about the sync part in this thread. Since the newest code are so fast I seriously didn’t see the point in having so many different type of gait. The gaits using the HalfLiftHeigth = 1 does the best performance, IMHO. I modified the wave gait to a 24 step gait. These are the gait I’ve choosed to use:

[code]GaitSelect
;Gait selector
;Removed some gait types, gaits using HalfLiftHeigth = 1 gives the best result

IF (GaitType = 0) THEN ;Ripple Gait 12 steps
GaitLegNr(cLR) = 1
GaitLegNr(cRF) = 3
GaitLegNr(cLM) = 5
GaitLegNr(cRR) = 7
GaitLegNr(cLF) = 9
GaitLegNr(cRM) = 11

NrLiftedPos = 3
HalfLiftHeigth = 1
TLDivFactor = 8	  
StepsInGait = 12	
NomGaitSpeed = 70

ENDIF

IF (GaitType = 1) THEN ;Tripod 8 steps
GaitLegNr(cLR) = 5
GaitLegNr(cRF) = 1
GaitLegNr(cLM) = 1
GaitLegNr(cRR) = 1
GaitLegNr(cLF) = 5
GaitLegNr(cRM) = 5

NrLiftedPos = 3
HalfLiftHeigth = 1	
TLDivFactor = 4	  
StepsInGait = 8	    
NomGaitSpeed = 70

ENDIF

IF (GaitType = 2) THEN ;Wave 24 steps
GaitLegNr(cLR) = 1
GaitLegNr(cRF) = 21
GaitLegNr(cLM) = 5

GaitLegNr(cRR) = 13
GaitLegNr(cLF) = 9
GaitLegNr(cRM) = 17
  
NrLiftedPos = 3
HalfLiftHeigth = 1	
TLDivFactor = 20	  
StepsInGait = 24	    
NomGaitSpeed = 70

ENDIF
return[/code]

Currently I’ve also been experimenting with different values for the BalanceDivFactor:

BalanceDivFactor con 5	;Other values than 6 can be used, testing...CAUTION!! At your own risk ;)

[code];--------------------------------------------------------------------
;[BalanceBody]
BalanceBody:
TotalTransZ = TotalTransZ/BalanceDivFactor
TotalTransX = TotalTransX/BalanceDivFactor
TotalTransY = TotalTransY/BalanceDivFactor

if TotalYbal1 > 0 then		'Rotate balance circle by +/- 180 deg
	TotalYbal1 = TotalYbal1 - 1800
else
	TotalYbal1 = TotalYbal1 + 1800	
endif
if TotalZbal1 < -1800 then	'Compensate for extreme balance positions that causes owerflow
	TotalZbal1 = TotalZbal1 + 3600
endif

if TotalXbal1 < -1800 then	'Compensate for extreme balance positions that causes owerflow
	TotalXbal1 = TotalXbal1 + 3600
endif

;Balance rotation
TotalYBal1 = -TotalYbal1/BalanceDivFactor
TotalXBal1 = -TotalXbal1/BalanceDivFactor
TotalZBal1 = TotalZbal1/BalanceDivFactor

return[/code]
It is possible to use other values than 6 (which make the correct mathematical balance). Using a lower value like 3 the balance mode gets much more visible and “alive” but can also give some unpredicted result under extreme poses (especial under single leg control). I’ll probably try this out some more later. I just wanted to mention it if someone was wondering…

I can’t remember who mentioned this first, but I moved the GaitInMotion calc from the Gait to the GaitSeq sub.

Ok thats it for now.
All credits to Xan for his great work on the V20 code! (Its always fun to play with your code )

[kurte]

Thanks Zenta for posting all of the updated code!

Will look at more later and make sure that is my starting point for arc32 code. Many of the differences will be removed from that code as it won’t be talking to an SSC-32. Will be fun

Kurt

[kurte]

Hi Xan and Zenta,

Not sure if this is the best place to post, but I do have a question on the code you did to fix the timing problem.
In particular in this code:

[code] 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 

#ifdef DEBUG_MAIN
lsumCycleTime = lsumCycleTime + CycleTime ; BUGBUG::: debug
;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
#else
;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
#endif
ELSEIF Walking = TRUE ; Wait one more cycle before we leave the walking mode
;sound P9, [40\2000,40\5000] ; Just an indicator
;Wait for previous commands to be completed while walking
pause (PrevSSCTime - CycleTime) MIN 1
Walking = FALSE

ENDIF

[/code]
In this last ELSEIF walking, you are using CycleTime, but the Cycletime is normally updated in the above if. Is that by design that use the time from the previous cycle?

My assumption is that what we are wanting is to not issue a new move until the previous move has completed. Looking at as conversion to HSERVO. Wondering if I can simplify the whole thing to simply check to make sure the servos are idle

Thanks
Kurt

[zenta]

@kurte

In this last ELSEIF walking, you are using CycleTime, but the Cycletime is normally updated in the above if. Is that by design that use the time from the previous cycle?

Oh…
To be honest i didn’t think about that. But I do think the end result will be the same though since the ELSEIF only occur once after a walking session. I’ll have to update that part. Thanks for pointing that out.

@kurte

My assumption is that what we are wanting is to not issue a new move until the previous move has completed. Looking at as conversion to HSERVO. Wondering if I can simplify the whole thing to simply check to make sure the servos are idle

As long as the robot are walking you’ve to wait until the current move are done but not when doing body translate/rotate for a more smooth movement. Somehow you need to know if the gait are still active or not. So i’m not sure if that only using the check idle function will work properly.

[likwidchz]

It seems like my question might have gotten skipped, is there anyone that is able to answer that for me?

Thanks,
Aaron

[zenta]

@LikWidChz

Are my choices for AwPulsesIn(0) - AwPulsesIn(6)… 0 being channel one and 6 being channel seven?

Yes, but you’ve to figure out another way for sending the button commands from ch7(ch6).

[innerbreed]

@LikWidChz

It seems like my question might have gotten skipped, is there anyone that is able to answer that for me?

Thanks,
Aaron

just above [main] you will see

; SSC SSCTime = 150 HexOn = False

change this to TRUE

HexOn = True

once you apply power it should just stand up and ready to move.

[likwidchz]

Thank’s I’ll try this when I get home from work.

Funny I did manage to integrate Kurte’s Assembly code into the RC phoenix 1.3 code last night, surprisingly it took me about 10 minutes, which is funny considering the 2.0 code I couldn’t even get to turn on my Phoenix.

That assembly code makes the world of difference for reading rcinputs rather then using Pulsin… although from my experience on this forum it really seems as if quite a bit of people on this forum really do not use RC control. It appears most are using either the ps2 remote, the Xbee or that crazy 400 button remote I believe was developed by Jim here and then others got together to add more buttons to the crazy thing!

any who Thanks Innerbreed for that seemingly easy tip I seem to have overlooked.

–Aaron

[karlelch]

Hi,

I am new here and I have question about Xan’s code.
Recently, I got a CH3-R hexapod. It works perfectly fine with the code created by PowerPod, remote controlled by the wireless PS2 controller. Next I downloaded Xan’s code v2.0 (thanks, Xan) from the project website (lynxmotion.com/images/html/proj102.htm) and tried it - unmodified - on the CH3-R (with the CH3-R configuration file, of course). It worked immediately and I was very impressed by the possibilities. There is only one thing I noticed and I can’t find out the reason for it:
When walking forward, backward etc. the legs move as they supposed to move (and it looks great!), but when I rotate the body (turning while walking, or just rotating the body with all feet at the ground doesn’t make a difference), the middle legs on both sides are just moving up/down but without the coxa sweeping back and forth. Since the PowerPod code works and the legs move correctly with Xan’s 2.0 code when walking e.g. forwards, I think it cannot be a wiring issue or a mechanical problem. I started to study the code, but it’ll take a while until I read the Basic code fluently (I usually work with C-related languages).
I would be grateful if someone gave me a hint about what could be wrong.

Best,
KarlElch

P.S.: This is a great forum; I only started reading a few days ago but I really like it. I appreciate the open discussions and that people share their code.

[kurte]

@zenta

@kurte

In this last ELSEIF walking, you are using CycleTime, but the Cycletime is normally updated in the above if. Is that by design that use the time from the previous cycle?

Oh…
To be honest i didn’t think about that. But I do think the end result will be the same though since the ELSEIF only occur once after a walking session. I’ll have to update that part. Thanks for pointing that out.

I was wondering if that part of the code could simply be something like:

[code] IF (GaitPeak > 2) or Walking THEN ;if GaitPeak is higher than 2 the robot are still walking
Walking = (GaitPeak > 2) ; remember why we came in here

	;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  
ENDIF

[/code]

@zenta

@kurte

My assumption is that what we are wanting is to not issue a new move until the previous move has completed. Looking at as conversion to HSERVO. Wondering if I can simplify the whole thing to simply check to make sure the servos are idle

As long as the robot are walking you’ve to wait until the current move are done but not when doing body translate/rotate for a more smooth movement. Somehow you need to know if the gait are still active or not. So i’m not sure if that only using the check idle function will work properly.

Sounds good, so I should just do minor surgery. I wonder if i should just continue to use the timer there like is shown above, or in this case get rid of the timer and simply put in something like:

[code] IF (GaitPeak > 2) or Walking THEN ;if GaitPeak is higher than 2 the robot are still walking
Walking = (GaitPeak > 2) ; remember why we came in here

	HSERVOWAIT [cRFCoxaPin,	cRFFemurPin, cRFTibiaPin,|
				cRMCoxaPin, cRMFemurPin, cRMTibiaPin,|
  				cRRCoxaPin, cRRFemurPin, cRRTibiaPin,|
				cLFCoxaPin, cLFFemurPin, cLFTibiaPin,|
  				cLMCoxaPin, cLMFemurPin, cLMTibiaPin,|
				cLRCoxaPin, cLRFemurPin, cLRTibiaPin]

command
ENDIF
[/code]
But I will take this up on the other thread…

Kurt