H3R with Atom Pro?

Lynxmotion Legged Robots
21

I’m looking into this. I have used the new 135 version and did not need to change anything. I’ll let you know what I find.

22

My guess is that he quickly put the values in order 12-15, when I look at my original 135N I see

DualShock DAT con P4 CMD con P5 CLK con P7 SEL con P6

Notice that it is not in order…
My code was set up like:[code]
DEBUG_MODE con 1 ; Conditional code to work in debugger.
PRO_CHIP con 1 ; define if we are compiling for the pro.
#if PRO_CHIP

SND_SCL con 1 ; use on pro.

;DualShock
DAT con P12
CMD con P13
CLK con P15
SEL con P14

;Serial port to SSC32
SSC32 con P11
SSC32_BAUD con i38400

#else ; definitions for ATOM chips
SND_SCL con 1000 ; use when compiling on ATOM

;DualShock
DAT con P4
CMD con P5
CLK con P7
SEL con P6

;Serial port to SSC32
SSC32 con P15
SSC32_BAUD con i38400

#endif[/code]

Hope that helps

23

Good work Sparticus !

now, i think there’s still a problem with the main loop time…
as the BA Pro 28 is 3X faster than the BA 28 and as the main loop time is synchronized with the ‘T170’ value in the ‘big’ serout line (the one just before the “goto main” instruction)…
i think the program will need a pause value in the main loop, just before the “goto main” instruction, try “pause 100” then 110 120 etc…when the legs are shaking when moving, it’s too much.

if you don’t add this pause, i think the gait loop is unable to perform in complete, as the program is sending to many order to the SSC-32…
i think it’s sending a new position while the previous move (all with a T170 sync value) is not already finished

now, you have many CPU time to add some feature (A/N input test for example etc…), so, if you add some code, you’ll have to decrease the new pause value according to the CPU time you’re using…

24

Thanks for the input, I wondered about some of this when I first got mine working. I plan to get back to my Hex soon.

What I was thinking of trying was to keep a semi real time clock. Maybe steal some code from the Brat:

ONINTERRUPT TIMERAINT,handle_timera 
PMR5.bit3 = 1 
TMA=4   ;increments on clock/256 
ENABLE TIMERAINT 
...
handle_timera 
   overflowtime=overflowtime+256 ; adjust to make it semi-real time...
   resume

So then in my main loop, I could have code that would remember when the last output to the servos was and then before it outputs again wait for the right amount of time.

Does this make sense?

25

Doh! You’re right…

26

Hi all,

i agree to Laureatus: i have ported the code (syntaktically) and my bot behaves like some grumpy old man, shaking and whirling. :slight_smile:

i already started to play around with the timein of main-loop. however: i think that is not a good way: whenever you tweak your code, you have to refiddle the pause length.

something interrupt driver makes more sense, or: even better (and probably more easy): some kind of self adjusting mechanism. Perhaps measure the time for one main loop and calcing the pause value accordingly.

Just my 0.02ct.

regards
M

27

I agree. I am still spending more time with the Brat. However I did spend an hour or so getting my changes back into my code and installing the PRO back onto the Hex. The changes are going a bit slow now as I am running on generator. Our power has been out since yesterday morning!

What I have tried doing is the following:

; We want to make sure we waited enough time from the last output to allow the SSC32 some time to process the last command...
gosub WaitForSSC
serout SSC32, SSC32_BAUD, |
	"#",RRHH,RRHH2,"P",DEC HipH_Pulse(0),"#",RRHV,RRHV2,"P",DEC HipV_Pulse(0),"#",RRK,RRK2,"P", DEC Knee_Pulse(0),| 
	"#",FRHH,FRHH2,"P",DEC HipH_Pulse(2),"#",FRHV,FRHV2,"P",DEC HipV_Pulse(2),"#",FRK,FRK2,"P", DEC Knee_Pulse(2),|	
	"#",MLHH,MLHH2,"P",DEC HipH_Pulse(4),"#",MLHV,MLHV2,"P",DEC 3000 - HipV_Pulse(4),"#",MLK,MLK2,"P", DEC 3000 - Knee_Pulse(4),|	
	"#",MRHH,MRHH2,"P",DEC HipH_Pulse(1),"#",MRHV,MRHV2,"P",DEC HipV_Pulse(1),"#",MRK,MRK2,"P", DEC Knee_Pulse(1), |	
	"#",RLHH,RLHH2,"P",DEC HipH_Pulse(5),"#",RLHV,RLHV2,"P",DEC 3000 - HipV_Pulse(5),"#",RLK,RLK2,"P", DEC 3000 - Knee_Pulse(5),|	
	"#",FLHH,FLHH2,"P",DEC HipH_Pulse(3),"#",FLHV,FLHV2,"P",DEC 3000 - HipV_Pulse(3),"#",FLK,FLK2,"P",DEC 3000 - Knee_Pulse(3),|
	"#",DeckP,DeckP2,"P",DEC Deck_Pulse,"T170",13]
		; maybe output some debug information	
gosub SetupNextSSCWait[170]
...
;--------------------------------------------------------------------
handle_timera 
   overflowtime=overflowtime+256 
   resume

;-----------------------------------------------------------------
; We want to make sure we waited enough time from the last output to allow the SSC32 some time to process the last command...
;
WaitForSSC
	DISABLE TIMERAINT
	currenttime = overflowtime + TCA
    SSCWaitTime = SSCWaitTime - (currenttime - lasttime)
    if SSCWaitTime > 0 then
   		sleep SSCWaitTime
   	endif
	return   	
      	
			
SetupNextSSCWait[SSCWaitTime]
	lasttime = TCA
	overflowtime = 0
	ENABLE TIMERAINT 
	return

I found that I needed to turn the timer interupt off when I am doing my serial outputs. I have not finished debugging all of this yet, but something like will work…