Ok I think those helped!
Here is a new video of it:
i416.photobucket.com/albums/pp245/Kurts_Robots/th_ShowingBalance.jpg
What do you think? I know it is not a great video, but I think it is working a lot better than before!
Kurt
Hi Kurt,
It sure looks better but I still feel its not like it should be, what happends in the last part of the video? Did you try to translate the body?
Hi Acidtech,
It’s a good thing he did. 
We sure can use some improvements in speed so every good suggestion is more then welcome!
I’ve build myself a test setup with a separate ABB and SSC to make testing easier. I want to start rewriting one of the main functions getsincos to fixed point one and then compare the calculation speed with the original one 
I’m curious about the result.
I’ll keep you updated!
Thanks, Xan
PS. You have to fill me in about the meaning of AFAIK and IIRC 
Hi Xan,
I hope we can save some time. I’m very excited to hear the result. The TOFLOAT command are used alot so this gives me a little hope.
BTW: I was also confused by AFAIK (As far as I know) and IIRC (If I Recall/Remember Correctly), I had to google it 
Thanks to Acidtech.
Yes toward the end I did Shift Body and then Rotate body (L1 and L2)
One other reason you should move to fixed point is you can easily convert fixed point basic into fixed point assembly code for those sections of code that need an even bigger boost of speed. I’d guess you could get another 5X to 10X improvment on going from fixed point basic to fixed point assembly. Most basic commands have 20cycles of overhead just to parse and execute the command token. In the same time it takes to process one basic token(not including executing the actual tokens function) you could run 10 assembly adds/subtracts or 1 assembly multiply/divide. There is alot of room for speed improvment. Of course it gets harder to code to get that speed improvement but it’s nice to know you can get it if you need it.
Hi all,
I just mailed Jim V1.3 of the code. The new version includes some minor changes in the PS2 remote.
- L1 & L. Stick Shift body X/Z
- L1 & R. Stick Shift body Y and rotate body Y
And the best of all, it also includes Zenta’s balance calculations! Thanks for all the great work you put in to this Zenta! The balance calculations really Rock! 8)
Xan
10 minutes! Now that’s what I call fast!
Thanks Beth!
Xan
Great work Xan!
Thanks for the credit, its fun to know its “out there” and I hope this kit and project will inspire people to start with robotics.
Any new video?
Yep I think it’s a good idea to shoot another one. But it will have to wait for Saturday. I feel more like a mole lately, driving to work and back in the dark. And since I don’t have the same quality “shooting“ lights I need to shoot it in the light to get a clear picture
Fixed point update:
The integer sin and cos functions isn’t as precise as the floating point sin and cos. The integer ones divide a full circle in 256 parts which are steps of 1.4 deg. When we look at the phoenix femur, the end (knee) will have steps of 1.8mm. The tibia will have steps of 2.6mm. Personally I think this doesn’t do the job. 
Another option is that I stay with the floating point fsin and fcos and convert it to fixed points as soon as possible. This way we do have the same precise and win some speed because the rest will be fixed point.
Acidtech, is there another way to get a the same precision without using the fsin and fcos? 
Xan
you could create your own fixed point cos() lookup table, you only need 45 degrees worth of entries so a 256 byte table would have a resolution of 0.175 degree. If you are using 8.8 for a fixed point format you only need the .8 part in the table since all entries are < 0.
something to consider: does BAP have a constant storage class where values are stored in program memory rather than data memory?
Yep, you can do things like:
mySinTable bytetable 1,2,3,4,5...
If bytes are not large enough you could use wordtable
Kurt
Hi!
The first thing I like to say is: Sorry for my bad english
I’ve read this topic a few weeks ago.
Why do you not use a PIC instead BAP?
The PIC 16F877 has 31 IO PIN, hardware USART, I2C and SPI.
The maximum clock source is 20Mhz.
This means PIC are 5MIPS (Million Instruction Per Sec) capable instead of BAP’s 0.1.
If you prefer the basic language, there are a lot of Basic compiler to program the PIC directly. I think basicmicro’s MBasic is create a binary code to PIC.
Note: The first basicStamps are based on microchip PIC. Because the basic intrepreter eat a lot of processor time they switched to the bigger hitachi and ubicom controllers
Ease of use mainly.
EddieB beat me too it but I’d also suggest making your own sin tbale lookup. The one table could work for both sin and cos. You probably have plenty of code space left so a 512 or 1024 byte hit won’t be too bad. Plus if you use it instead of the sin/cos commands you’ll be saving the space that would normally be used by those commands(around 300 bytes).
Ease of use yes but also speed and functionality. Running basic on a PIC is much slower than running it on the BAP(ie see the standard BasicAtom). Of course you could go to other languages(C or raw asm). The catch there is most of the PICmicro C varients don’t have nearly the commands the BAP has available to the programmer. If thats what you want though the BAP supports C/C++(without all the nice basic commands though). And if you want to compare BAP to PICmicro(any 16F or 18F series) in assembly langauge speed the BAP will eat the PIC for breakfast. I’ve not used the PIC24/30/33 series chips but from what I’ve read on them they are significantly different from the chips most people use. I don’t have any idea how they would stack up against the BAP. Of course I don’t know if there is even a basic for those chips yet.
So I just got my phoenix up and running, and already I’ve confused myself. On the complete Phoenix tutorial (lynxmotion.com/images/html/build139.htm ), the program named: photri01.bas works perfectly fine on my bot.
However I tried using v1.2 and v1.3 on Xan’s project page here: lynxmotion.com/images/html/proj102.htm
And was unable to get them to work at all. I load the program on the Basic Atom Pro without problem, but it just sets all servos to their home position and doesn’t respond to the PS2 controller at all (but the PS2 controller links up)
Weird that the newer code doesnt respond at all, but the older code works no prob. Am I missing something here?
You have to hit the start button on the PS2 remote to make it work…
Kurt