Alfa release Phoenix Code

Let's Make Robots Project Ideas
101

Hi Zenta,

I integrated your changes into my sources and yes I think it does walk better again :smiley:.

Kurt

102

Hi Kurt,

Thats good to hear! The difference can only be seen in the very last cycle/step of a gait though.

103

Hi Xan and Zenta,

How are things going? Do you need any help testing or changing anything? Or are we about to release this version?

Thanks
Kurt

104

Hi Kurt,

I was a bit occupied with the garden for the last few weeks.

The software isnā€™t released for the following reasons:

  1. 4DOF support. KĆ„re, gave me some feedback on this. There where some parts of the code missing. Which I need to add. Also the version I mailed did not fully support his hardware which maked it harder to test. I have to see that I supply all the files next time. I hope that KĆ„re is willing to give it a full test run then.
  2. The variable speed on the GP player did not work properly. I did not check the GP player topic yet so Iā€™m not sure if the speed issue is solved.

I probably gonna play a bit with this in the evening. So I will check this as well.

The last week I played around with the xbee modules. I donā€™t have the 4 buttons like you both have so I need to figure out how I could get this to work. I use the push/rotate button you helped me out with. Iā€™m short of pins since the XBEE module uses one pin more. The push/rotate button needs 2 interrupt ports so I need to figure out if I can combine some pins.

Xan

105

Hi Xan,

Fully understand about garden and the like. Have been busy with that as well. My wife wanted chickens, so this year we tore apart the garden and I built a new chicken coup and run. Just finished putting the raised beds back inā€¦
Chicken-Coup-and-Garden.jpg

With this issues you mentioned:

  1. 4DOF - Can not help there as I donā€™t have any hardware to support it. I keep thinking of maybe trying to change my CHR-3 to 4dof, but would need partsā€¦

  2. Variable GP speed - I just emailed Mike about this. I did do some more testing as you can see in that other thread. But I think it may be more to do with how the SSC-32 does timings of steps, like maybe only allow it to move N units per 20ms time. That is if I tell the servo in a step to move 200 units in 45ms. If we say for example that 750us difference in pulses is about 90 degrees. That would imply 200 is about 25 degrees change. The HS645MG says it takes about .2 seconds to go 60degrees, so for it to go 25 degrees should take maybe: 83ms, which is close to about the time I am seeing with the test. My guess is the SSC-32 has some built-in limits for this and that is what we are seeing.

  3. XBees and IO IO pins. Yep that is an issue, which is why Zentas and My remotes no longer have working speakers. Let me know if I can help. You could probably easily convert to Arc32 or I will soon have some Arduino Mega codeā€¦

Kurt

106

Hi guys!

Ah, now I understand why you are interested in TA, Kurtā€¦ :laughing: Very nice environment and nature but not so nice for a hexapod that can only walk on flat ground.
The chicken coup with flower beds looks good! :smiley:

Iā€™ll do some testing around the 4 DOF when youā€™ve the code ready Xan. Just need to recalibrate itā€¦ The coxa should be easy but I think Iā€™ll have to do the rest of the jointā€™s.

It would be great if Mike found a way around the GP speed bug. Otherwise we could just speed up the sequences before uploading it to the EEPROM and then just use the 0-100% SM values.

107

Thanks Zenta,

Yep, my property is a good place for TA (or very large tires :laughing:)

On the GP side, I think we could simply just document it. That is it may not be a bug, but a limit on how fast the SSC-32 allows servos to rotate. We could do a scan of the sequence and calculate the max speed up for that sequence. I See in SEQ that you can set a maximum rate for a servo, but I donā€™t see anywhere, that this information is transfered to the SSC-32. Again I think we can live with the current functionality.

Kurt

108

Hi Kurt,

Yeah, no wonder why you have a tractor/excavator with big tiresā€¦

Personally, I can live with the GP too. Like I said, if you want a faster sequence you can simply modify the overall speed in SEQ. My experience of using only a sbyte size for the SM work fine too.

109

Hi Kurt,

In the last code you posted in the extra file for the ARC, I believe there is a little bug when setting the offsets.

[code]
+++ Write Servo OffsetsOffsets +++
+++ Reset after values updated +++
A) RR Hip Hor = -1400
B) RR Hip Hor = 600
C) RR Hip Hor = -1750
D) RR Hip Hor = -150
E) RR Hip Hor = 550
F) RR Hip Hor = -850
G) RR Hip Hor = 1300
H) RR Hip Hor = -1100
I) RR Hip Hor = -1500
J) RR Hip Hor = 400
K) RR Hip Hor = 550
L) RR Hip Hor = 1350
M) RR Hip Hor = 50
N) RR Hip Hor = 250
O) RR Hip Hor = 350
P) RR Hip Hor = -300
Q) RR Hip Hor = 300
R) RR Hip Hor = 1150
Use keyboard to adjust the servos
Ā± - to increment/decrement the current servo
0 - Will zero out that offset
1-9 - Set the increment default 50 Num * 10
@ - Clear all offsets from SSC

    • to choose next servo or a-z to choose specificā€¦
      <$> - Return to main program
      - to save away the updated values
      A) RR Hip Hor(31) Center= -1400[/code]

Settings offsets work fine but its the same text that come up for every servo (RR Hip Hor for all). I guess its an easy fix?

110

Hi again,

I think I found it.

_i is a word and looking at an older code the i variable is a byte.

So I simply changed this part:

for _i = 0 to NUMSERVOS-1 bCurServo = ServoTable(_i) ; Need to get to text name for servo xor.l er0, er0 ; zero out the whole thing mov.b @_I, r0l ;was _i shal.l er0 shal.l er0 ; multiply by 4 bytes per... mov.l #TT_TABLE:24, er1 add.l er0, er1 ; should have the address now mov.l @er1, er0 mov.l er0, @PTEXT hserout HSP_DEBUG, "A"+_i, ") ",str @pText\20\0, " = ", sdec AServoOffsets(bCurServo), 13] next

into this:

for i = 0 to NUMSERVOS-1 bCurServo = ServoTable(i) ; Need to get to text name for servo xor.l er0, er0 ; zero out the whole thing mov.b @I, r0l shal.l er0 shal.l er0 ; multiply by 4 bytes per... mov.l #TT_TABLE:24, er1 add.l er0, er1 ; should have the address now mov.l @er1, er0 mov.l er0, @PTEXT hserout HSP_DEBUG, "A"+I, ") ",str @pText\20\0, " = ", sdec AServoOffsets(bCurServo), 13] next

The i variable was already defines as a byte in the control_XBee fileā€¦ :unamused:

111

Sounds like you may have found it. I sure wish BAP Basic had some form of variable scope to avoid issues like this :frowning:

Kurt

112

Yeah, me to.
I did get a warning if I tried to use @_i in the asm code instead of @_I. Strangeā€¦

113

Yep, Basic upper cases all variables, so in ASM you must do so or they wont find eachotherā€¦

Kurt

114

Hi guys,

I was working on merging in some of the changes here into my Arduino version of the code. Xan I remember you mentioning that you needed the servo commit to be later in the code loop than what I had for some reason. So while updating my code I looked at the two functions:

[code]UpdateServoDriver:
gosub ControlAllowInput[0];

disable TIMERINT ;disable timer interrupt
for LegIndex = 0 to 5
; Calulate
GOSUB GetPWMValues [LegIndex]

serout cSSC_OUT, cSSC_BAUD, [0x80+cCoxaPin(LegIndex) ,CoxaPWM.highbyte,  CoxaPWM.lowbyte,|
	                         0x80+cFemurPin(LegIndex),FemurPWM.highbyte, FemurPWM.lowbyte,|
	                         0x80+cTibiaPin(LegIndex),TibiaPWM.highbyte, TibiaPWM.lowbyte]

next

;Send speed
serout cSSC_OUT, cSSC_BAUD, [0xA1,SSCTime.highbyte,SSCTime.lowbyte]
enable TIMERINT
gosub ControlAllowInput[1];

PrevSSCTime = SSCTime
return
;--------------------------------------------------------------------
CommitServoDriver:
;Send
gosub ControlAllowInput[0];
disable TIMERINT
serout cSSC_OUT, cSSC_BAUD, [13]
enable TIMERINT
gosub ControlAllowInput[1];
return[/code]
I have some concerns here about this code. That is I believe that in binary SSC command mode, sending the Time part of the command, is the trigger for the command to execute, not a CR which is shown in the commit function. I believe in this case the CR does nothing. So I believe with this code the delay stuff is not doing anything.

Or maybe my memory of the commands is off.

Kurt

115

Hi Kurt,

Good point. I just checked the topic about the binary commands. and here is a quote from Mike/Jim:

Looks like you are totally right about this one! I think that for binary mode we need to send the time command in the commit function. Changing this will also change the pause calculation before sending the commit since committing will be 3 bytes in stead of 1.

Thanks for finding this bug!

Xan

116

Thanks Xan,

Sorry I did not catch this earlier. My earlier versions were setup with the 3 bytes output in the commit so I never checked until I was comparing current code to my Arduino version. Last night I was merging in the 4dof / possible leg mix code into the Arduino version I found it.

Also I believe the UpdateServoDriver needs a little conditional code added to it to output the Tars servoā€¦ Maybe depending on condition (like its Tar length > 0ā€¦ or pin definedā€¦

Kurt

117

Question: What steps do we need to take before we can release this code as released or at least a public beta to be released?

I know the 4DOF and the 3/4 DOF code has not been fully tried out yet. I donā€™t have any configurations of robots to try this myself yet.

Anything else?

Why I am asking is for example I am trying out some new XBee packet code, that others may like to try out, but only the 3 or 4 of us up here can try this out.

Also I have the Arduino version that is working pretty well based off of this, that I would like to update the code in the Arduino Phoenix thread that has several fixes and is based off of this code base. Would like to do that at about the same time as the BotBoarduino board is releasedā€¦

Just wondering
Kurt

118

I wasnā€™t sure who you were directing the question to. For me, I am working on getting the BotBoarduino boards here ASAP. So my time frame is about four weeks right nowā€¦

119

Thanks Jim,

Actually It is sort-of a general question, to several/All of us.

  1. Xan - Do you think the general BAP/Arc32 code for the PS2 is good enough to release as a general beta for the 3dof Phoenix, T-Hex, CHR-3?

  2. Xan/Zenta/Me - Is the DIY/XBee version OK enough for me to to put up Beta version with maybe updated Transmitter code as well?

  3. Should one of us build an RC version. My gut says that it would be good to have one, but that we can do this over time. Still issues, like should we do DIY remote with RC, Hitec, ā€¦

  4. Updated release of Arduino Code that runs on Botboardduino as well as Megasā€¦ Would like to update the code soon as there are some issues with the current code I have up there, but could/should wait until Botboardduino is there in about 4 weeksā€¦

  5. In progress on Software library like Parallax object exchange?

  6. Someday need to try Propeller version again and update to same level of functionalityā€¦

That is all I can think offor now
Kurt

120

I have made some progress on the DIY XBEE work with delta messages, as I mentioned in the public thread. I think I have some of it working with the BAP28 transmitter as well as the Arduino one. So far I have only updated the Phoenix/THex code for Bap/Arc32. Since I am using the Alpha code not sure if I should post any of it up on the main forums yet. If anyone wishes to take a look, I have included some zip files to play withā€¦

Kurt
DIY_Remote-110922a.zip (26.4 KB)
DIY Transmitter with delta msgs.zip (35.8 KB)
Arc32 Phoenix DIY delta msgs .zip (43.1 KB)