TA development topic

Hi Guys,

I just copied the TA stuff from my hybrid program (based on 2.0) to the current 2.1 final version. The result?? Out of memory! :cry: Looks like we’ve pushed the BAP28 to it’s limits with the current Phoenix code :smiling_imp:

I’ll see if I can remove some stuff like the GP player for now. Hope this gives enough space. The silly thing is that the Basic Micro Studio only gives a lousy message: C:\Program Files\BasicMicro\Basic Micro Studio\bin\ld.exe : region text is full (...) No message about how much the memory is exceeded. How much I need to free up… Bummer!

Kurt, You recently been busy developing some new uC boards. Can you give me a suggestion of what board will be best for the job? We can’t drop on speeds and need more memory.

I do have an ARC32 board over here. Jim what do you prefer? One of the new boards or the ARC?

Thanks, Xan

Botboarduino! It is $35.00 compared to $100.00. :slight_smile: The mega would do an awesome job. But for now the only hardware I can supply will be Atom Pro or BBduino. Just days away from BBduino.

Hi Superguru! :smiley:

Yep, my guess right now is that we should go with the Arc32 as Lynxmotion sells them. My Arduino port compiles for the BotBorduino with the PS2, but I don’t think it would make it with XBee and TA stuff. I do have an older pre version 1 Arc32 board here as well, which would probably work fine for this. Also have a production one in my Phoenix. Dale promised me another one awhile ago, but…

If we go with Arc32, the next question should be, to use SSC-32 as well or to do it all with the Arc32. Both have their pluses and minuses. Code is in place for Arc32 alone, but would need a little work for Arc32 plus SSC-32, as the current SSC-32 code assumes things like TimerA where Arc32 or Bap40 have TimerB1…

Maybe I should build a few of my Bap64 designs :laughing: … (viewtopic.php?f=44&t=7331&p=76657#p76657) Keep toying with ordering a few boards built, plus maybe a solder paste stencil for about $15, and an electric skillet and try to build a few, as the chips are only $13. Probably not worth it, but could be fun.


Availability aside could you outline the pro’s and con’s of ARC-32 vs. Mega with our shield? ARC-32 = $99.00 Mega/Shield should be ~$65.00. Performance I dunno?

Superguru yes, lol

Thanks for the heads up! So the BotBorduino is short on memory for this.
Kurt, you can probably answer Jim’s question like no other. Is the Mega/Shield up to this job? Also, did you already port the code to the Mega? Sorry, I lost track of all the ports…

For now I would prefer to keep using the SSC for the following reasons:

  1. No interference.
    Updating the servo positions will probably be done using some interrupts and timers. What I learned it that they can easily mess up other stuff.
  2. KISS
    Since TA will increase complexity a lot it is better to keep it as simple as possible and let the SSC handle the servos.
  3. Flexability
    For now we “only” need to port the software to another platform if we want to swap controllers. If we also embed the servo driver in there it is harder to swap later on.

My proposal for now is that I swap the BAP for for the ARC + SSC for now. This way I’m not hold up by hardware for now. We can always port the code to the hardware of Jim’s choice. What do you guys think?


Yes the Shield is up to the task, especially if you still have the SSC-32. It has 256KB of memory which is very nice. It also has 4 USARTS, which again is real real nice. That is you have one for debug(USB), one for XBee, one for SSC-32 and a reserve one for things like Serial display… Arduino runs at 16mhz even though the underlying Atmega can run at 20mhz like the Arc32. The Arc32 with it’s 32 bit processor probably has a bit more horsepower, but I am not sure that is an issue. Especially since the Atmegas have more and I believe faster interrupts… Also since we are compiling our code versus running on an interpreter I am not sure if it does have more cpu power…

Now about Seeeduino Mega with Botboarduino Mega Shield : Yes the code is setup for it. Or at least was. Also since in the last couple of days Arduino has released it’s first official release (1.0), I am now converting all of the code I posted yesterday to this release. Luckily the phoenix code was already updated by another member yesterday :smiley:.

As for Cost, I am not sure which is cheaper: The mega with shield and SSC-32 or Arc32. Obviously if we add SSC-32 to Arc32, than that cost will be higher.

Now if we go with Arc32, I am on the fence on with or without SSC-32, now talking about your points.

1-2) Interrupt issues/kiss - Personally I am not sure which way is this.
a) with - Yes offload the servo work which is good. Nathan says the Servo support adds about 1-2% usage of Arc32
b) without - Use Serial output. Now if we are using XBees either Xbee or SSC-32 can be on hardware serial port, but not both. Assume SSC-32 is using bitbang. Have to use support to turn off interrupts from controller while we are doing our serial outputs to SSC-32. Also since bitbanging we are holding up the processor during the output of the characters…

  1. I have ported the code to a few different platforms already, again abstracting out the servo controller, allows us to go either way. I am currently in the background also trying to get this code to run on an Uno32 by Digilent. It uses a Pic32 running at 80mhz, 2 usarts with form factor of Arduino. They also make a Mega32 with the same form factor as Arduino Mega, too bad they don’t make it in the Seeeduino Mega form factor as this would really kick… But that is a different subject.

  2. Delays: With SSC-32 when your foot sensor detects something it has to send some serial data to the SSC-32 to tell it to stop and then some more characters to ask where it is and wait for the data to come back… Again assuming my earlier ideas of guesstimating by time did not work. Without the SSC-32, you can get the current positions, which simply reads a few memory locations…

Note: As I mentioned the current code does not support the Arc32 (or Bap40 or Bap64) with SSC-32. Used to: but was removed to get rid of #ifdef. In particular the following from the phoenix_drivers_ssc32.bas would need to be conditional:


;[InitServoDriver] - Initializes the servo driver including the main timer used in the phoenix code
; Timer A init, used for timing of messages and some times for timing code…

WTIMERTICSPERMSMUL con 64 ; BAP28 is 16mhz need a multiplyer and divider to make the conversion with /8192
TMA = 0 ; clock / 8192 ; Low resolution clock - used for timeouts…

;[Handle_Timer_asm] - Handle timer A overflow in assembly language. Currently only
;used for timings for debuging the speed of the code
;Now used to time how long since we received a message from the remote.
;this is important when we are in the NEW message mode, as we could be hung
;out with the robot walking and no new commands coming in.
push.l er1 ; first save away ER1 as we will mess with it.
bclr #6,@IRR1:8 ; clear the cooresponding bit in the interrupt pending mask
mov.l @LTIMERCNT:16,er1 ; Add 256 to our counter
add.l #256,er1
mov.l er1, @LTIMERCNT:16
pop.l er1

return ; Put a basic statement before…
;[GetCurrentTime] - Gets the Timer value from our overflow counter as well as the TCA counter. It
; makes sure of consistancy. That is it is very posible that
; after we grabed the timers value it overflows, before we grab the other part
; so we check to make sure it is correct and if necesary regrab things.
lCurrentTime = lTimerCnt + TCA

; handle wrap
if lTimerCnt <> (lCurrentTime & 0xffffff00) then
lCurrentTime = lTimerCnt + TCA

return lCurrentTime
Real simple changes, with things like TCA ->TCB1, needing to slightly change the itnerrupt to make sure the right interrupt bit is cleared and change the constants for conversions from ticks to MS and which interrupt ias assigned to TIMERINT…

So again no big deal and the changes are burred where most users don’t need to worry about. They simply need to call GetCurrentTime…

So I will let you make the call.

The Mega with SSC-32 sounds ultimately the most powerful and versatile solution. The delays associated with stopping servos goes with the extreme offload of processing servo pulses, so some bad with the good. If it can be worked around with the faster baud rate and binary coms it’s worth the trouble. Arc-32 even with SSC-32 seems to fall short on uarts and other performance hits like interpreting commands.

Hi gurus and friends! :slight_smile:

Are you talking about a total of 3 boards here?

I agree of keeping it KISS and I see the point of using the SSC-32 if you want to switch platform. Talking about platforms, what about the propeller board? The power of 8x20 MIPS should really give TA a big leap I hope.

ARC-32 + SSC-32 sounds just silly IMHO. Kurt’s BAP64 BotBoards sounds more logic with that combo. The BAP64 doesn’t cost much either, not sure about the board though.

When it comes to the ARC-32 board I have a love/hate relation to it. Incredible slow upload speed and no speaker is a pain. But having just one single board is the major advantage of it.

Just my 2 cents…

We all sure have a bunch of varied ideas of where to go here…

The main thing to remember here is other people need to be able to do this… I would love to drive this with the end goal of it just working the best that it can, but the BAP64 board isn’t even a product. The Mega is available and I will have some shields soon. The Propeller boards are not working and Mike has run into many problems. I will be sending them to someone else to work on. Honestly can’t we just take out some features to get it working using BAP and SSC-32?

The mega and shield is still one processor, taking up one space.

Hi Jim,

I totally agree with you that an end goal should be to gets lots of people interested in this and want to do this themselves. Personally I think we should pick a starting platform and get it working. While we are getting it to work, my guess is that there will be someone (like me), who will probably integrate the work into other platforms as I like to have options…

So to me, that leaves us two options:

BAP family: Maybe could strip enough stuff out of current code to make it run on BAP28, like run sequences, XBee support, …, but I personally think this would be counterproductive. If we go BAP route, I prefer Arc32, as we have more code space, 2nd USART, which also implies that we have a USART for the debug input/output, which I find very useful to have output that is not corrupted. As for BAP64 (or 40), I totally agree that there are no commercial boards and sorry for confusing things by mentioning it. If for the fun of it, I do try making a few :smiling_imp: , I may send you a couple to play with. The online tutorial that Sparkfun had showing soldering using a frying pan looked like it could be fun. But regardless, this would change very little in the code, especially if we are using the SSC-32. So my vote in this category is Arc32.

Arduino Family: I think we need Mega’s here for code size, USARTS, etc. (As you may guess, I prefer coding in C, so this would be my choice). I would for sure start off here with SSC-32. In the end it would be nice to have the shield, but I did most of my conversion work to Arduino before having the shield. When you are using the SSC-32, you really don’t have that many wires to hook up to the Arduino board.
3 wires to SSC-32 (RX, TX, GND)
PS2 (6 wires) and/or XBee (4 wires)
And for the TA stuff obviously we will need connections for the legs. Signal and ground Can use internal PU resistors for this.

I have most if not all of the 2.1 stuff integrated into the current code base. One thing I have not done yet, is to abstract out the SSC-32 stuff, like I sort-of did with BAP (for SSC-32 vs Arc32) and I believe I did on Propeller… I may soon take a pass at doing this, PLUS better abstracting of controller. That is instead of having function names like: InitController, ControlInput… I want to define a class, like Controller, which is an a header file. Than Each of the controllers will have an implementation and the main Code will do things like:

So if anyone wanted to start to play with running this on a Mega before they had a shield it would not be difficult. Could do with the one I am using (amazon.com/Arduino-Mega-2560 … 609&sr=8-2), But it much longer and would fun to fit it on the T-Hex, and our shield won’t work with it. Hopefully Mike will complete the other 4 prototype shield boards soon and you can play with one of them :smiley:

So I am game either way. If you already have an ARC32 sitting around, it might be good to start off by simply swapping it in for the BAP28 and continue to make progress. Could even do it both ways, that is you do on Arc32 and I port over to Arduino. This would imply that we have both covered, but will obviously be slower to debug as each time you want help I need to do the port… Or I could maybe get some of the new leg sensors on my TH4-R hex and have Arduino on it, put Arc32 on T-HEX3 and work both ways…

Let me know which way you wish to go.


Here is a proposal. Why don’t we give TA a fair shake with the current platform, Atom Pro 28 / SSC-32. Remove unneeded code, take advantage of the higher baud rate and binary comms. We have already gone to the extensive work of getting everyone using the same setup. There are countless hexapods out there that could be doing TA with foot switches added only. So this would create the biggest impact in the industry. Then when that is working as best it can I will personally make sure everyone has what they want for their ultimate solution. Let it go where it will from there.

I agree Jim. Lets hope removing the GP part is enough for free space. There are probably things that can be simplyfied in the XBee section too.

Jim from what you are saying, your preference is to keep it with off the shelf default configuration, with Bap28 and Arc32 and probably PS2. With this configuration, with the current 2.1 code base you have about 7K free space, with the full blown XBee stuff we have maybe .5K free. So you can probably start off with that configuration and see how much your code adds…

Compiling T-HEX PS2 for Bap28 SSC-32:
Ram: 308 free 1740
Program Space: free 7172

I did a quick update of the same code to run on Arc32:
Ram usage: 308 Free 3788
Program space: free 31710

Building for XBee on Arc32, left us with 25184 bytes of program space free…

I did a quick and dirty update to the SSC-32 driver to support the 3687 processor… Which I have included.


P.S. - The nice thing about this is that we can easily work with both Bap28/Arc32 and very little needs to change. Mainly pin numbers…
Phoenix_Driver_SSC32.bas (11.6 KB)

Do we really need any controller at all? Seriously stop laughing, it’s a gait engine. Let it walk forward into the unknown terrain. You could tether a couple pots/joystick to it for adding some control. 8 Channels actually, and they are fast and east to read. Low code city man. It would still be a breakthrough! ok I admit it’s a little personal for me to have TA on the basic setup. :confused:

Hi Guys,

Thanks for sharing your thoughts. :slight_smile:

For TA we need to add/modify a couple of functions:

  • LegFK (calculate position of the leg from it’s angles)
  • BodyIK (calculate body position and orientation from the position of the legs)
  • Gait (add TA functionallity in the gait to let it stop on contact)
  • Inputs (read TA switch inputs)

I gave removing some code a bit more thought. The math involved will double. I guess that in total the code will be increased by 30%. There are some functions that can be removed to make place:

  • GP player
  • All gaits except one
  • XBEE
    Both the GP player and gaits give us a few %. XBEE gives us much more but testing TA having the PS2 remote for control is not doable. That is why I swapped to the DIY remote at the first place. I’m think that removing some code will help us for now. But I’m afraid that we will run into the memory problem again real soon.
    I also agree with Kurt, Adding functionality, then removing it to add different functionality isn’t that effective. It will also be hard to manage. Also I saw that the A-Pod kit will also have pressure switches. With the extra math for the head and tail this will never fit. Also having the 4th DOF enabled for the THex will not fit.
    My conclusion: keep the BAP28Pro is not an option. :frowning:

I agree that having the ARC32 in combination with the SSC32 is a silly option. I brought this up to a temporary solution. I could easy swap the BB2 to the ARC and continue developing the software. In the mean time the new boards can be made public and we decide what platform to go with. If we decide to stick with the ARC, we can drop the SSC. Or drop it right away since Kurt says it isn’t going to be a problem. :slight_smile:

I think that having the same platform when developing is a pre. This way it is easier to exchange files so we could help each other. Both Kurt and I have an ARC that we can use. Kåre, do you also have an ARC available? I remember that you added sensors to your original phoenix. It would be great if you can join us since you’re brilliant in fine-tuning everything and you’re good with the math as well.

Jim, I get your point about the BAP28 being the default platform for a while now. Most people have that board and they can use it for every bot/kit available in your shop. Clearly enough the current phoenix code reaches the limit of the platform. I think it’s a good thing to split the platforms into different area’s.
**Normal: **BAP28, Botboarduino
These platforms can be used from small to medium robots and kits. Almost all LM’s current kits.
**Medium: **ARC32, Seeeduino Mega
These platforms can be used for medium to large robots and kits. Starting at kick-ass hexapods like 3DOF/4DOF THex with TA and A-Pod’s
**High-end: **RB100, and other OS based board
Yes, some day we will be adding linux or embedded windows to let the robot do real smart things. (Future plans though) Another topic :wink:

My proposal:
If I outline the previous points there are 2 options; ARC32 or Seeeduino Mega + SSC32. For now I will swap the BB2 with the ARC so I can simply continue developing. Then I think Jim should make the call since that is pure marketing. If Jim want’s to use the ARC, we change the code to drop the SSC. If Jim want’s to use the Seeeduino we port the code ones the hardware is done.

PS: I think it is good to have ONE development platform where we add new functionality. Then port the code to other platforms.

Please let me know what you guys think of my proposal.


Jim, I did not fully understand your last post…

It’s not important.

LOL, What about my prev post? :wink:

Great summary Jeroen!

Yes, I do have my original Phoenix with ARC-32 and feet sensors, don’t you remember?.. :wink:

So its RTR for TA. :smiley:

Hi Kåre,

I can’t remember seeing this image but is looks ready for the job. :slight_smile:
I do remember a closeup of the sensors. :blush: