Kurt's Phoenix with Arc-32

[zenta]

Thanks Kurt,

I don’t think I noticed your reply, due to the two EDIT’s in my previous post.
I hope your hand are doing better, take care!

[kurte]

Thanks again, it is getting better.

So far I have not needed the RTS line on the arc32 as both serial communications I currently do are through hardware serial ports. If later we want to add an LCD or the like, well then maybe. But since we can display stuff on the DIY remote, well…

Kurt

[linuxguy]

@zenta

I like your suggestion of adding a speaker to the ARC-32.

I was suprised to see the Arc32 did not have a speaker/buzzer integrated on it. It’s really the only thing I can say is missing, even though I see where it could be easily added. It’s used often enough, it really should be right on the board though.

8-Dale

[linuxguy]

@kurte

First - yes the XBEE stuff will be compatible - (I hope). I suspect that the main differences with Arc32 version is that I am going to have to convert all of the HSERIAL stuff to HSERIAL2 stuff. The bright side is I will also be able to convert the debug serout s_out to HSERIAL at a high speed. This is where I really wish that the Basic supported Macros. Sure would be nice for the XBEE stuff if I could simply do things like:

Why does there need to be a change from HSERIAL to HSERIAL2? Is it just a name change or is there much more going on behind the scenes? I know there is a speed difference between the BAP and Arc32, but couldn’t this be handled internally to the Basic Micro code? Are there other considerations that require this change?

@kurte

But you do it the way you got to… Alternatively it sounded like Nathan would consider a way to tell the compiler to swap the HSERIALS, which would help in this case (Will keep my fingers crossed )…

This is what I am talking about. Don’t expose any more change for users than is absolutely necessary. This includes source code changes when switching between boards.

Both BAP and Arc32 only have a single added hardware UART. Having to use HSERIAL2 implies more than one added UART.

8-Dale

[xan]

@linuxguy

@zenta

I like your suggestion of adding a speaker to the ARC-32.

I was suprised to see the Arc32 did not have a speaker/buzzer integrated on it. It’s really the only thing I can say is missing, even though I see where it could be easily added. It’s used often enough, it really should be right on the board though.

8-Dale

I think they made the decision of dropping the onboard speaker after hearing all the terrible beeping sounds comming of the phoenix code

[acidtech]

HSERIAL and HSERIAL2 are two different UARTs on the ARC32. On other AtomPro modules there is only HSERIAL since they only have one UART. On the ARC32 HSERIAL pins are also s_in and s_out. HSERIAL2 pins are th eTX and RX on the AUX2 header.

We didn’t put a speaker directly on the ARC32 board because of routing limitations. Just couldn’t do it. We did keep that in mind though and have a daughter board that will be available in a couple months or so. The daughter board connects through the AUX1 header(though you don’t need to connect all the pins to use it). It will provide a speaker(not a buzzer), 4 LEDs, 4 individual buttons, a 4 way micro joystick, a 3 axis accelerometer(MMA7260), a MicroSD card slot and an optional 128x128 full color LCD screen(Its a Nokia screen thats about 1.2"x1.2" IIRC). The board will have it’s own (maybe programmable) AtomProPlus/3687 onboard with eeprom as well. The boards will ship with code to access all the hardware via the i2c,(maybe)spi, and TX,RX pins of the AUX1 header.

Depending on how hard it is to access the board to program custom user code without a special programmer(may just use the Nano USB adapter) that functionality may or may not be available and unless I can figure out how to auto detect async serial versus sync serial then SPI mode communications may not be supported either. I2C and async serial are definitely going to be supported though.

[kurte]

@linuxguy

@kurte

But you do it the way you got to… Alternatively it sounded like Nathan would consider a way to tell the compiler to swap the HSERIALS, which would help in this case (Will keep my fingers crossed )…

This is what I am talking about. Don’t expose any more change for users than is absolutely necessary. This includes source code changes when switching between boards.

Both BAP and Arc32 only have a single added hardware UART. Having to use HSERIAL2 implies more than one added UART.

8-Dale

Yep, it is still on my wish list with Nathan! The hardware for the BAP28 has a single UART. The Bap40 and Arc32 have two UARTS. The first UART RX/TX are connected to S_IN/S_OUT and the second 1 RX2/TX2 is connected to some standard IO pins. I wish there was a clean way to abstract the differences away. In C would use #defines to take care of the differences, but in basic I have to call either HSERIN or HSERIN2, likewise for HSEROUT and HSEROUT2…

You simply have to do a simple API change for each call. It has been awhile, but I think I did do some wrapper functions for most of the API calls to minimize the number of changes or #ifdefs that I would need.

Kurt

[linuxguy]

@Acidtech

HSERIAL and HSERIAL2 are two different UARTs on the ARC32. On other AtomPro modules there is only HSERIAL since they only have one UART. On the ARC32 HSERIAL pins are also s_in and s_out. HSERIAL2 pins are th eTX and RX on the AUX2 header.

Ahhh, OK. My mistake here then. I somehow though the AtomPro had two UARTs also.

@Acidtech

We didn’t put a speaker directly on the ARC32 board because of routing limitations. Just couldn’t do it. We did keep that in mind though and have a daughter board that will be available in a couple months or so. The daughter board connects through the AUX1 header(though you don’t need to connect all the pins to use it). It will provide a speaker(not a buzzer), 4 LEDs, 4 individual buttons, a 4 way micro joystick, a 3 axis accelerometer(MMA7260), a MicroSD card slot and an optional 128x128 full color LCD screen(Its a Nokia screen thats about 1.2"x1.2" IIRC).

That’s a nice feature set for an add on board. I especially like the addition of the display and capability of having a nice simple user interface.

@Acidtech

Depending on how hard it is to access the board to program custom user code without a special programmer(may just use the Nano USB adapter) that functionality may or may not be available and unless I can figure out how to auto detect async serial versus sync serial then SPI mode communications may not be supported either. I2C and async serial are definitely going to be supported though.

Even though using I2C is generally more involved, I do prefer it over SPI when writing code. Now, make the BAP and Arc32 capable of being I2C slaves as well as masters and that would make me extremely happy. The reason I’d like to see the I2C slave capability is it would allow me (and others) to use a BAP or Arc32 as a slave to a board like the BeagleBoard (which I have) or Gumstix (considering purchasing at some point). I know I could do it as a serial slave, but UARTs are typically already in short supply, especially with BeagleBoard and Gumstix boards.

8-Dale

[acidtech]

Kurt, I do plan on making HSERIAL/HSERIAL2 reversable. Send me a reminder in email though. I tned to forget things even though that one should be pretty easy.

We’ll, I’ll be writing I2C slave code for the daughter board(using the i2c hardware). I expect I can make that into an hi2c system when I’m done.

[linuxguy]

@Acidtech

We’ll, I’ll be writing I2C slave code for the daughter board(using the i2c hardware). I expect I can make that into an hi2c system when I’m done.

Have you seen these SC16IS750 I2C/SPI-to-UART IC? I’m planning to get a couple of these at some point, for experimentation. UARTs are always in short supply with most micros, and this might be a worthwhile chip to use to get more. I’ll be adding a small breadboard to WALTER so I can experiment with custom circuits.

8-Dale

[tom_chang79]

How’s your Hexapod coming along with the ARC-32? I really like how the servo controller and the main processor is on a single board…

[kurte]

I have not done much on this lately. I have most if not all of the phoenix 2.0 functionality working on it. Since then have been playing with Roboclaw and build C libraries for the pro… Hope to get back to it soon. Will probably soon start working on converting my XBee code from terminal replacement ASCII mode to packet mode and open up some more possibilities…

Kurt

[zenta]

Hi Kurt,

I do have a little bug when running your code on the ARC-32. Every time when I start the robot (HexOn -> True) by hitting the “0”. All servos jumps far away from the position it should and then move fast back to the correct position. It all happens in a fraction of a second, but its pretty irritating though. So far I’ve solved it by not turning on the servo power until after hitting the “0” for turning the Hex on. Did you experience this or is it just an issue with mine ARC board?

[kurte]

Hi Zenta,

I think I have seen something like that. I have not investigated yet. My guess is that I am not initializing all of the servos first with a time of 0 for the move so it does a quick move thinking it is starting from servo pulse width 0 to the new position… I will try to take a look soon, but have company arriving today for several days, so not sure when…

Kurt

[kurte]

Yes it was that I was not calling hservo with a zero or no time for the first time, so it was trying to move to the desired position from never never land. In addition to this, if you did a FreeServos, where we moved all of the servos to -30000, which actually tells the system 0 pulse width, then when you hit 0 again it tries again to move from never never land. So I create a new bool variable. If it is true I don’t pass time values if false I do. I set it at the start of the program and in free servos…
Changes in: ServoDriverCommit and FreeServos and the variable defined and initialized…

Kurt
phoenix_v21.bas (53.1 KB)

[zenta]

lol, thanks for the fix Kurt. I didn’t expect it that fast so I got your hint and fixed it too. But I don’t think I did it the exact same way though. I did only change the code in the servo driver commit. I wasn’t aware that you needed to do something with the freeservos to. Since I’m using digital servos they never get very “free” though.

;[Servo Driver Commit] Do the actual HSERVO in the commit phase ServoDriverCommit: IF HexOn AND Prev_HexOn=0 THEN hservo [cRHipYawPin \ aswHipYawHServo(cRightleg), | cRHipRollPin \ aswHipRollHServo(cRightleg), | cRFemurPin \ aswFemurHServo(cRightleg), | cRTibiaPin \ aswTibiaHServo(cRightleg), | cRAnklePitchPin \ aswAnklePitchHServo(cRightleg), | cRAnkleRollPin \ aswAnkleRollHServo(cRightleg), | cLHipYawPin \ aswHipYawHServo(cLeftLeg), | cLHipRollPin \ aswHipRollHServo(cLeftLeg), | cLFemurPin \ aswFemurHServo(cLeftLeg), | cLTibiaPin \ aswTibiaHServo(cLeftLeg), | cLAnklePitchPin \ aswAnklePitchHServo(cLeftLeg), | cLAnkleRollPin \ aswAnkleRollHServo(cLeftLeg), | cCogShifterpin \ aswCogShifterHservo ] ELSE hservo [cRHipYawPin \ aswHipYawHServo(cRightleg) \ abs(HServoPos(cRHipYawPin) - aswHipYawHServo(cRightleg)) * 20 / SSCTime, | cRHipRollPin \ aswHipRollHServo(cRightleg) \ abs(HServoPos(cRHipRollPin) - aswHipRollHServo(cRightleg)) * 20 / SSCTime, | cRFemurPin \ aswFemurHServo(cRightleg) \ abs(HServoPos(cRFemurPin) - aswFemurHServo(cRightleg)) * 20 / SSCTime, | cRTibiaPin \ aswTibiaHServo(cRightleg) \ abs(HServoPos(cRTibiaPin) - aswTibiaHServo(cRightleg)) * 20 / SSCTime, | cRAnklePitchPin \ aswAnklePitchHServo(cRightleg) \ abs(HServoPos(cRAnklePitchPin) - aswAnklePitchHServo(cRightleg)) * 20 / SSCTime, | cRAnkleRollPin \ aswAnkleRollHServo(cRightleg)\ abs(HServoPos(cRAnkleRollPin) - aswAnkleRollHServo(cRightleg)) * 20 / SSCTime, | cLHipYawPin \ aswHipYawHServo(cLeftLeg) \ abs(HServoPos(cLHipYawPin) - aswHipYawHServo(cLeftLeg)) * 20 / SSCTime, | cLHipRollPin \ aswHipRollHServo(cLeftLeg) \ abs(HServoPos(cLHipRollPin) - aswHipRollHServo(cLeftLeg)) * 20 / SSCTime, | cLFemurPin \ aswFemurHServo(cLeftLeg) \ abs(HServoPos(cLFemurPin) - aswFemurHServo(cLeftLeg)) * 20 / SSCTime, | cLTibiaPin \ aswTibiaHServo(cLeftLeg) \ abs(HServoPos(cLTibiaPin) - aswTibiaHServo(cLeftLeg)) * 20 / SSCTime, | cLAnklePitchPin \ aswAnklePitchHServo(cLeftLeg) \ abs(HServoPos(cLAnklePitchPin) - aswAnklePitchHServo(cLeftLeg)) * 20 / SSCTime, | cLAnkleRollPin \ aswAnkleRollHServo(cLeftLeg)\ abs(HServoPos(cLAnkleRollPin) - aswAnkleRollHServo(cLeftLeg)) * 20 / SSCTime, | cCogShifterpin \ aswCogShifterHservo \ abs(HServoPos(cCogShifterpin) - aswCogShifterHservo) * 20 / SSCTime] ENDIF

It worked fine though.
Thanks for your update Kurt!

[kurte]

Thanks Zenta,

Acutally your fix may fix both ways as the Previous hex on will be false after the free servos… May change to that way as it keeps from needing another variable to keep track of.

Kurt

[acidtech]

The next release of Studio, HServo will not use the speed argument if the current position is -30000(or -24000 on AtomPro24/28).

[jefe]

Hey, I just got a bunch of the parts necessary to finish my arc32 hexapod; I was wondering, do you have a finalized version of the arc32 phoenix code? Is it just the one uploaded above zenta’s post up there? also, what pins on the arc32 board did you plug the 2 PS2 controller cords into? I’ll trawl in the phoenix code to see if I can find it, for now

[kurte]

I have not made very many changes to the Arc32 phoenix code for awhile so the one I posted earlier should be close. Zenta has made changes since then, but a lot of those changes were for using the DIY XBee control. Also the latest change to not do a little jump at startup time may not be necessary as the latest version of Studio now ingores the speed values if the servos were previously not turned on. (logically at -24000 on bap28 or -30000 on Arc32). More details about that in the what changes from build to build post in the Basic Atom… forum.

Kurt

PS2 connects to the pins on the Aux2 header.