Jim, you had mentioned L was working on this. Do you know when it would be available?
Not bugging you at all. Just wondering if it’s close enough I should wait for it.
If not, what exactly do I have to change in the powerpod basic program to make it compatible with the atom pro?
I remember something about the byte table has to be changed and something about resolutions from 100000 to 100 or something. Or is it not that simple?
kurte converted the program for my last hex and I tried to look off his to make the changes to mine but I keep messing up.
Kurt is the forums guru when it comes to converting Laurents code from Atom to Pro. I’m not wanting Laurent to get involved because it would only delay him from creating the PowerPod program which will help everyone the most. Laurent and God are the only ones who know how long this will take. But honestly even Laurent can’t answer this question because there is always the possibility of an unexpected thing or two that can take time to figure out. He’s the best I have ever seen and I can tell you when it’s done it will be phenomenal.
There were several little things here and there that had to change. I don’t know if I remember all of them, but the bytetable was one of them. There used to be some bugs in something like SQR that sometimes returned the wrong value (negative?). They handle divide by zero differently. There were differences in time scales for sound commands, there is no NAP command, had to convert to an appropriate sleep command…
I guess the question is what are you wanting to do right now. I can see a couple of options:
a) Take the inline version that I helped convert awhile ago and try to simply update all of the leg constants and the like.
b) If you are starting with SEQ stuff with the ripple gait, you can have SEQ output BAP code to run each sequence or with the new SSC32 you can store the sequence in the EEPROM. Then you can strip out all of the gait code out of the previous code and either insert the generated SSC32 code or a call to the appropriate sequence when the user presses the right button on the controller…
I earlier posted the steps I took to get the gait into my SSC32. Over the next while I will try to have a simple program to call them. What I don’t know now is what each of the sequences are supposed to do…
I see a new PowerPod up, but except for a few serout changes, I’m not seeing any significant changes. Weren’t there supposed to be some nifty gait changes; presumably for Phoenix?
You may have missed that PowerPod needed an update due to an error on the support for the Bot Board II. Laurent is now working with his Phoenix as we speak. He is working on making Phoenix walk with the current program and if sucessful he will move on directly to converting PowerPod for the Atom Pro. So the update here is he is working on it.
Can’t wait for the Atom Pro support for the Powerpod. I’m generating my own code as we speak, but the IK-based code that powerpod generates is far superior to the sequence-based code that I’m using
A question regarding the “Control” drop down box in Powerpod, what configuration does this imply? What does this do? The only obvious control function is PS2, but I don’t understand what the hardware configuration is for “serial” and “autonomous”?
I’m assuming that the “autonomous” mode is botboard+ssc-32 with no ps2 controller, but the code is still polling for the ps2 button presses…
The serial mode allow you to send serial commands to the Atom instead of the PS2 game controller. There are examples for the serial commands and program development included in the zip filke. The autonomous mode allow you to write / modify the code for the Atom to directly control the robots motion.
As Robot Dude mentioned, AcidTech(Nathan) could answer this much better than I can. But I believe the answer is a guarded yes.
That is, you can use the S_IN and S_OUT to talk to the PC. I use S_OUT all of the time for debug messages.
However the complexity is timing. That is the S_IN input to the Pro uses software (bit bang) to receive the input from the PC and has no hardware support (USART). So it can only properly receive data when your program on the ATOM Pro is sitting in a SERIN command. I have a version of my code for the BRAT that has a VB program to do the roughly equivelent functionality as SEQ, where I could use sliders to adjust the servo positions on my BRAT and it communicated back and forth to tell the BRAT to download the sequence or try one step of it.
It was working earlier, but right now my communication appears to be a bit flaky. It is on my list of things to fix this. The way I am planning to do this, is to add some more handshaking. Something like when the PC wants to talk to the brat, it will start sending a default prompt to the brat at a regular interval and wait until the BRAT sends some form of ACK. At this point the BRAT will be sitting in the SERIN command and should be able to properly receive the packet from the PC. You might need to try a similar approach.
Another approach is to use hardware support(HSERIAL). The pro has one USART that is on pins P14 and P15 that can be used for the communication with the PC. Using the hardware serial, you program does not have to be waiting in a SERIN command to receive the information. The problem here is that these pins are standard TTL output (+5v, 0v), where as the PC expects standard RS232 level signals. You could hook up an external circuit with something like a MAX232 chip to do the conversion, or if your bot also has an SSC32 on it that the PRO talks to, it has an unused 9 pin serial connector and the level conversion onboard. I have meant to try jumpering P14 and P15 over to the appropriate pins (the ones you removed jumpers from) on the SSC32 to see if this would work.
Seems like I missed this thread on the topic of sending commands to a BB2 from another uP board.
I believe this is the most logical way to do the interface. The hardware USART is used for communications, the Atom BASIC bit-bangs out the data to the SSC32.
The commands expected from the PC can be supplied by the “Serial CP H3” program, by a terminal program (sending hex bytes), or by another “supervisor” uP board. I used DockLight to send commands to my 'bot controller board in this manner. I can compile my program to take data from either my comm port or the wireless PS2 controller. I posted a set of test commands on another thread to demonstrate this. These commands can be sent by a uP board in a similar fashion. The “data” is the same, BASIC or C.
The DB9 is RS-232 on the BB2. Doesn’t the Pro follow the same convention? The TTL bit-bang port might use a different pin. Users can simply follow the BB2pdf.pdf file for connections (or the applicable tutorial for your board). I don’t have BB2 board, hope this helps!
