Alfa release Phoenix Code

Let's Make Robots Project Ideas
81

Hi Zenta,

Almost finished implementing the extra DOF.
Can you tell me what these values are for?

TGA_A_H4 var sword TGA_B_H3 var sword
Xan

82

Hi Guys,

Here is a new Alpha release of the code. The whole list should be in there. I only included the phoenix config file for now. I will update the THex files asap.

Zenta, Can you help me out by testing the 4DOF? You have to change some version in the phoenix config file. You can enable the extra DOF by uncommenting this constant:

c4DOF			 con 1	 	; Switch between 3DOF and 4DOF

Please feel free to test the code. If you guys don’t find any bugs I will add the additional config files and the package will be ready for release!

Up to TA!!! 8)

Xan
PhoenixCodeV2.1Alpha20110511.rar (24.5 KB)

83

I’ve realized that its been a long time since I worked with this stuff… :unamused:
They are used for different conditions when calculating the tars angle. What made me a bit confused at the moment is that I’m referring to some PEP notes that I can’t find. :blush: I’ve to check my PC at work to see if I can find the correct PEP version there…

Argh… :imp: I’ve to be better in taking more notes and make more comments in the code…

84

Hi Xan,

As long as we are only using the PO registers the 4DOF won’t work for other than me without the servo horn offsets in the IK leg sub.

Defined in config file:;-------------------------------------------------------------------- ;[Joint offsets] ;First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then: cFemurHornOffset con 150 ;Snap out the horn one click upward cTarsHornOffset con 150 ;Snap out the horn one click inward ;--------------------------------------------------------------------

Must be in the LegIK sub:

;IKFemurAngle FemurAngle1(LegIKLegNr) = -(IKA14 + IKA24) * 180 / 3141 + 900 + cFemurHornOffset

;Tars angle TarsAngle1(LegIKLegNr) = (TarsToGroundAngle1 + FemurAngle1(LegIKLegNr) - TibiaAngle1(LegIKLegNr)) +cTarsHornOffset

I’ve not recalibrated my T-Hex for only PO yet either, but I plan to though.

But I’m wondering when looking at the files you just posted. Are you not planning to support XBee or ARC-32 in your next Phoenix code release?
Kurt shared several files May the 3. supporting this. Its kinda hard testing your code when it doesn’t support the hardware. For example; yesterday I finished my old Phoenix with the ARC-32 only + feet sensors. The code Kurt posted for the ARC-32 worked very fine. :smiley: (The LiPo saftey didn’t work correctly so I need to take a look at that though. + some other minor bugs…) I find it very useful to have an universal code that work with different hardware.

85

LOL, I exactly know what you are talking about. I often have to dig deep to remember what things are for. LOL
But it would be good to have some comment with it :wink:

Ok, If I got this right we’re talking about 2 different things here. We’ve got the PO registers for calibrating the legs. Those should be in the SSC registers. And we’ve got the default angle, or angle offset for the servo. When I look at the 4DOF tutorial
the femur should be horizontal

The tars should be in line with the tibia and perpendicular to the ground

So after doing this you want to snap out the horn and move the fermur one click up, and the tars one click inward. So the default angles will not be 0? I guess this has the same reason as placing the coxa servos in an angle of 60 or 45 deg right? Just to get a good default setup?

LOL, That’s about time then :wink:

You’ve got a good point here. Kurt and I talked about how to support different uC platforms and remote controls. As you have seen my latest zip there is a 4th file called SSC driver. This one needs to be replaced with the ARC driver. The RC remote file can also be replaced with the XBEE file from kurts post.

When I posted the file my clock showed 0:00 so I was in a hurry. I only zipped my phoenix project and forgot to include Kurts ARC and XBEE support files. But you can use the ones from Kurt.
As far as supporting different platforms; I would like to have the phoenix code available for both ARC and BB2+SSC and maybe others in the future. But I currently don’t have an ARC setup to test the functionality. So I totally have to rely on you guys to test this. My XBEE stuff is in so I should be able to test this code as well. But once switched to XBEE I would not be able to test the DIY RC. But then again, I think I’m currently the only user…

I tested this by simply applying 5V to the input. once I pulled the pin the bot switched off. I didn’t test this with the lipo (yet).

Xan

86

Sounds like you got it. Yes its kinda the same as with the coxas. Its easier to calibrate the leg sections with horizontal and 90 deg positions instead of fiddling with small angles.

Yeah, yeah… You know I hate the calibration part… :stuck_out_tongue:

Ok, I’ll try that. I just did a file comparing with WinMerge and found that the main difference in the core file is mainly that you added the 4DOF part. But Kurt had ;USE_IDLEPROC con 1 in the start of the file. That mean its not in use either since its commented out. So it should be ok then.

That might have to do with me testing it on the ARC-32. We need to use HSERVOSTATE and not ADIN to read the voltage, right? I also would like to be able to send this voltage back to the DIY remote. Would it be more appropriate add the code for sending it in the XBee control file? - not messing up the core file. I do like having the main/core file as a “clean” common base. Especially when we are about to start on the TA work. My little queen hex is so ready for that! :laughing:

87

Hi again,

It was the HSERVOSTATE thing…

The cVoltagePin must be set to P33 (not just 33) in the config file.

Voltage = HSERVOSTATE cVoltagePin ; Read VL

Seem to work fine.

EDIT: Also,

BodyRotX1 = 0 BodyRotY1 = 0 BodyRotZ1 = 0
in the CheckVoltage sub must be fixed point… :wink:

Btw, there are also a little issue with the sync stuff after ending walking. I’ve to look into that too.
You’ll hear from me when I’ve got time for it.

88

Hi Guys, I think I have everything merged back in. (Mine still has the #ifdef for the extras, but…).

Zenta, thanks for mentioning WinMerge, I downloaded and used it, which helps… Used to have such tools when I was working and missed it. Actually the ones I used to work with also could take 3 or more source files, the first was the checked in version and the others were the changed ones and it could try to automatically merge the code and then show you the differences and if it had problems with conflicts…

I found some subtle things that were changed a bit ago, like renaming cSound to cSPeakerpin, which some of my code still used the other…

Xan, I found your version did not compile on the PS2. Looks like you renamed a variable and missed changing it in one location…

I compiled all 4 of my projects and tried some of them out (PS2 on t-hex and XBee on Arc32 phoenix). So I will upload my stuff. Zenta if there are corrections please let me know so I can integrate them.

Note: the zip file has the Basic project that I use to download sequences to the Arc32. I load in some of your old phoenix sequences. Use the remap servo numbers. I define the order as: 31,30,29,28,27,26,25,24,23,15,14,13,12,11,10,9,8,4
Hint: you can enter them 1 at a time with the add button, but it also parses for comments and adds multiple items at once… Also Zenta if you are using one of the original test Arc32’s it had a 4k EEPROM on it (at least mine did), so it will corrupt things if you download too many sequences… The production one I have has 32K bytes.

Kurt
Phoenix21k.zip (112 KB)

89

Hi Kurt,

Actually, it was Xan that tipped me about WinMerge… :laughing: I do also find it very useful.
I’ll also do some more testing around the code when I get time for it. I did note that the speaker didn’t beep when changing function on the DIY.

I’m using the exact same servo pin config on the ARC-32 as you did for Phoenix. But I’m using different pins for speaker and eyes. Just for the fun of it I’m thinking of using 2 Starlite RGB LED’s for the eyes. :laughing: I do also hope to test the GP part one time.

90

Hi again,

Well in that case thanks Xan for finding it :slight_smile: Now I can delete another editing system (slkedit) off of my machine that I kept for this reason, my version is only about 12 years old and I don’t wish to spend $300 for the current version…

As I mentioned in the previous post, the speaker pin was renamed and I did not catch that in the previous build, hopefully I got them this time.

Kurt

91

Hi Guys,

Thanks for the feedback on the code. I will check the PS2 file and the things Zenta mentioned on the 4DOF files.

Zenta, did you find the notes on the 2 mysterious variables?
Could you test the GP player functionality since my sequence looks much slower then the one in your youtube vid.

I just upgraded my hardware to XBEE. THANKS Jim! I upgraded my THex and DIY remote. The Phoenix will follow as soon as I got this setup to work. I left the PS2 receiver in there to make testing the PS2 file easier. :slight_smile:
Where can I find some information about how to configure XBEE. It would be helpfull to know what I need to change. :slight_smile:
Information about the DIY Remote pin layout would be cool as well.

Thanks Xan

92

Hi Xan,

Sounds good that you received the XBees! Not sure what all you received, so I will need to guess here. There is lots of stuff up on the thread:
viewtopic.php?f=21&t=5447 but it’s now 31 pages long…

On the transmitter side, I am now using the same configuration as Zenta, which from the Transmitter with Extra pots is:

[code];==============================================================================
; [IO Definitions] Lets define what each IO line is used for.
;==============================================================================
; p0, left vertical joystick
; p1, left horizontal joystick
; p2, right vertical joystick
; p3, right horizontal joystick
; in4 - Col1 on keypad
; in5 - Col2 "
; in6 - Col3 "
; in7 - Col4 "
#ifdef USE_XPOTS
Display con 8 ; LCD Display
'Speaker con 9 ; Speaker; Disable speaker when used extra potmeter
Row0 con 10 ; Row 0 on keypad
Row1 con 11 ; row 1 on keypad
Row2 con 12 ; Row 2
Row3 con 13 ; Row 3
; P14 RXD ; HSERIAL
; P15 TXD ; hserial
RowB con 9 ; Cmd buttons new row , XP: ex-speaker
; p18 - Left slider
; p19 - Right slider
; p16 (AX0) - XP (eXtra potmeter), Left potmeter
; p17 (AX1) - XP (eXtra potmeter), Right potmeter
#else
Display con 8 ; LCD Display
Speaker con 9 ; Speaker
Row0 con 10 ; Row 0 on keypad
Row1 con 11 ; row 1 on keypad
Row2 con 12 ; Row 2
Row3 con 13 ; Row 3
; P14 RXD ; HSERIAL
; P15 TXD ; hserial
RowB con 17 ; Cmd buttons new row
; p18 - Left slider
; p19 - Right slider

#endif[/code]
The code also assumes that you have added the 4 buttons to the remote control to allow you to configure things…

As you can see we have used up all 20 IO pins including the one that the speaker uses. I think the version I am running right now is the one on Page 30 of the thread just before Zenta posted about the new Gimbals…

The latest zip file I uploaded to this thread had my T-Hex configuration for XBee: On this one I use HSerial so it use P14 and P15. I also use a third IO line which if you have the sparkfun adapter you solder a wire into the RTS connection. I Use P7 as well as P8 output a lower voltage than the other pins and the XBee expects 3.3V.

To configure the XBees, I use a Bap program, XBeeConfigure (I think it is called) that is part of my earlier zip files, I think the most recent one I put up was put up on Sep 22nd (page 25). In this program you can see if you can communicate with the XBee. If you have not configured it before use the option for 9600 baud (default for XBee). Then you can choose a My value (set to unique id number for your robots and remote), Also a title for it and a new baud rate. I believe we are all using the 62500 when talking with Baps using hardware serial port.

Once you get both Remote and computers set up, you should be able to start up the robot and the remote. On the remote, page through some configuration stuff, until you get the select by name page. You can then hit the A key to try to discover new robots (it does an xbee DL command). Sometimes I have to do this several times before it will find one… Once it finds one or more robots, you can use the right joystick (up/down) to scroll through the list and then use the logical enter key to choose one. The chosen one will show up with an *, then you can page back to one of the standard pages. You can then hit the 0 key on the remote to do the start…

Kurt

93

Hi Kurt,

Thanks for the good information.

I’ve got:
3x 1mW chip antena XBEE modules
3x XBEE Explorer Regulated
1x XBEE Explorer USB

I don’t have my left gimbal fully springloaded yet. And I don’t have the 2 additional potmeters. Instead of the 4 buttons I use the push/rotate button you helped me with some time ago. I will join you guys with the same remote setup later on. But for now I will only change the RC module for the XBEE module. I will try to get the controls as close to yours as possible to make file sharing easier.

I’m not quite sure what you are saying here. I’m aware that the Xbee module needs 3.3V. The regulator board takes care of that for the power. But how did you lower the voltage on the TX/RX pins? Or can I simply connect them to P14 and P15? You need P14 and P15 to use HSerial right?

Thanks! This is very useful information! I will try this out tomorrow. (Can’t wait! :slight_smile:)

Xan

94

Hi Xan,

On the robots I use three IO lines, two of them SIN/SOUT connect to HSERIAL (p14/P15 on BAP). The Sparkfun module takes care of lowering the voltage from the input pin. The output pin from the XBEE appears to create a high enough high to work OK with Baps, but I am using the RTS connection of the XBEE with the Don’t bug me code we talked about earlier. The issue is that sparkfun regulated does nothing to this pin and as such whatever the BAP generates is what the XBEE sees. But by luck the Bap28 has a lower voltage output on P7 and P8, so I simply use it.

Kurt

95

Hi,

If you look at this part of the core code:

[code];Sync BAP with SSC while walking to ensure the prev is completed before sending the next one
GaitPeak = 0 ;Reset
Walking = 0
LegIndex = 0
; Finding any the biggest value for GaitPos/Rot:
WHILE (LegIndex < 6) AND NOT Walking
GaitPeak = ABS(GaitPosX(LegIndex)) MIN |
ABS(GaitPosY(LegIndex)) MIN |
ABS(GaitPosZ(LegIndex)) MIN |
ABS(GaitRotY(LegIndex)) MIN |
GaitPeak

	IF (GaitPeak > 2) THEN ;if GaitPeak is higher than 2 the robot are still walking
	  Walking = 1;
	ENDIF
	LegIndex = LegIndex+1
WEND

IF Walking THEN ; Walking, sync required
  ;Get endtime and calculate wait time
  GOSUB GetCurrentTime], lTimerEnd	
  GOSUB ConvertTimeMS[lTimerEnd-lTimerStart], CycleTime

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

This code doesn’t sync the very last cycle of a gait cycle. Even when every GaitPos is < 2 at the end of a gait cycle the last step is still in motion. So I modified the code to work like intended in my original code.

This is the result:

[code];Sync BAP with SSC while walking to ensure the prev is completed before sending the next one
GaitPeak = 0 ;Reset
LegIndex = 0
; Finding any the biggest value for GaitPos/Rot:
WHILE (LegIndex < 6) AND NOT (GaitPeak > 2);Walking
GaitPeak = ABS(GaitPosX(LegIndex)) MIN |
ABS(GaitPosY(LegIndex)) MIN |
ABS(GaitPosZ(LegIndex)) MIN |
ABS(GaitRotY(LegIndex)) MIN |
GaitPeak

	LegIndex = LegIndex+1
WEND

IF (GaitPeak > 2)  or Walking THEN ; Walking, sync required
  Walking = (GaitPeak > 2)      ; This make sure the last walking cycle to be synced
  ;Get endtime and calculate wait time
  GOSUB GetCurrentTime], lTimerEnd	
  GOSUB ConvertTimeMS[lTimerEnd-lTimerStart], CycleTime

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

I’ve tested the code and the result is very visible (in my eyes… :wink: ).

96

Hi Kurt,

Thanks for the Information. I will connect SIN/SOUT to P14/P15 and move the PS2 remote to the pins you talked about earlier in this topic. The RTS connection is not regulated so needs to be connected to P7 or P8 (I’ll check you’re code to see which one you used). How come that P7 and P8 have a lower voltage? Is this documented in the BAP datasheet? Totally new to me :slight_smile:

I have some robotic time this evening! :slight_smile:

Xan

97

Hi Zenta,

Thanks for figuring this out. I did see something strange in the gaits but I spend to less time playing and walking around for sure! I’m happy to have a alpha release topic for this :slight_smile:

Thanks guys!!

Xan

98

Hi Xan,

I was slightly off here, it turns out it is P6 and P7 with the lower voltage. It is actually now in the datasheet for the Bap28 :open_mouth: I believe they set it up at lower voltage as they set it up for hardware I2c and made it so you could hook up 3.3v devices…

Kurt

99

Hi Kurt,

Do I need to configure something to get it to 3.3V or does a logic 1 on P6 and P7 always result in a lower voltage of 3.3V?

100

P6 and P7 always result in lower voltage, although they are compatible with 5v Input… This was why it was suspected the PS2 did not work on the ABB board with Atom Pros, which had the PS2s on P4-P7. But I am not sure if this was the reason as I have run PS2s on Propeller that run at 3.3v, but that is off the topic.

Kurt