For the fun of it, I have been playing around with porting the Phoenix 2.0 code over C and have it run on my CHR-3 (Phoenix has Arc32 may do later…)
I am making some progress. It is now listening to the PS2 controller, it understands the start button and stands up. It does not want to walk yet, but that may be partially because my battery was low and I may have screwed up one servo .
But I thought I would give those few who are untested a sneak peek, as I do have some support things working, like an IOPrintf that allows me to use a pin and a mode to do printfs. PS2 support, a simple sound output function, … All of these support functions need some clean-up and standardizing and merging with the other in progress C library.
Once the battery recharges and the like next will be debug the gaits, test my Serial input function…
Quick update: my servo was not bad My updated printf had a bug with the value of 0… If anyone needs it let me know and I will update the zip file otherwise it will be in with the next round of updates.
Quick update: finally tried and fixed TASerin. So now I can verify that the SSC-32 supports GP and I now can run the one sequence that is stored on my CHR-3. Also API support for sound with multiple notes. IOPrintf fix for output of zero.
Kurt
Edit: Update - fixed hang issue. (Update in timer code) - It now is starting to walk and be able to shifts/translates…
Quick update:
Found problem in my porting of the Gait code… Now appears to be walking with all of the different sequences.
Kurt
P.S - It appears like my serial input/output functions are working at 115200 so I can drive the SSC-32 at full speed Note: I did not change the config file in the zip file to use the higher speed!
Thanks for always sharing your awesome work!
I’m just wondering if you’ve done any comparing of execution speed between the basic and C code. Are there any difference at all?
I have not done any comparisons yet. I know that there are some cleanups in the serial output code that will speed things up. Currently MY IOPrintf function calls the TASerout for one character at a time. There is overhead in that, which I can reduce by passing more characters at a time… But at least my first test worked at 115200 so I am happy.
Next things to do:
Cleanup - Extract all of the useful functions from my main code functions (IO, PS2, Sound, …) Put them in their own source files. Maybe an overall header file that includes the others… Work with MinionBuilder and others to maybe try to form a real library…
Expand the serial output to handle HSERIAL, Setup interrupt handlers to do it in the background.
Port over my XBee code - Both as stand alone support functions, as well as then my XBee code for the Phoenix
…
But right at this moment I am playing with my Tri-track and converting it over to use the Robo-claw from Basic Micro, I am using stripped down Rover/Arm code (i.e. only rover) on this. Currently setup to be in Sabertooth mode, but soon will be in other input modes and then start playing with the encoders… But that is a different topic.
I have not gotten this as far as I would like, but thought I would do a checkpoint anyway… Something about squishing 3 fingers of my right hand between two large rocks that I just moved with the back hoe slows me down.
I have the beginnings of the code in place for running the Phoenix with the PS2 and/or DIY XBee. If it receives a connect type of message from the XBEE is uses that, else if it gets a start button from the PS2 it uses that… May experiment using a Basic Micro bit switch to turn off the XBEE when I am using the PS2…
I have the XBee working with the hardware serial port that I have buffered and interrupt processing. But it is resetting the processor from time to time which I am still trying to figure out. Some of this includes setting up a default interrupt handler for all of the unused interrupts that I call off to instead of jump to and then dump some information including the stack. This helped me find out the I2C interrupt was being triggered after the initial fault as soon as I would enable interrupts. Init code clears out some of this stuff now. But still the initial fault?
Also I know that turning on Balance mode needs more work… Also lots more testing… Remember this is a work in progress!!!
Thanks, it has been a little over a week now and they are starting to feel better… Not near as bad as a 19" skill saw!
I turn it on and all of the legs want to curl up into the body. It is probably something simple like part of the code was the original 2.0 based and some may be some of later stuff of yours. I will soon try to merge in you later stuff and make sure it is all consistent.
Started to integrate your changes into the code and then found that it is using your new changes to the DIY remote, so can not do all the changes as I don’t have those knobs to turn
Well, I didn’t integrate them there for nothing…
I believe you can do the changes by shifting the mode for a joystick or slider. Another thing is that I now use the left joystick (up/down) for moving forward, thats a bit hard with the original throttle stick (not self-centering).
Ok I think I fixed the Balance mode problem. There was a problem, that I may not have converted a short value to a long value at the right time and as such a couple of the calculations in: BalCalcOneLeg
Did not work correctly. If anyone is playing with it, let me know and I can upload the fixes otherwise it will be in my next batch.
Good to see that the phoenix code gave you some more inspiration!
I have to check the other posts to see if there is any progress in the phoenix code - ARC combination…
Thanks, I do have the phoenix code running on a phoenix with an Arc32 as described in this thread: viewtopic.php?f=8&t=6042&start=30
This includes the ability to download sequences to the arc32 and run them…
I have not done much lately, but I thought it would be good to try to extract the more generic type stuff into a library that then have a separate project for the actual phoenix code. I have run into a few issues along the way which I will describe, but I think I have it limping along now and I should have the same functionality as the combined version from before.
Now to describe some of the issues I have run into and my current work around.
Basic Micro Studio has no provisions for building libraries.
Work Around:
a) still created a project for it, that includes all of the source files. This allows me to do compiles, see the error messages and fix them… But the dummy main source file does not have everything so there are link errors.
b) I created a simple make file for nmake to build the actual library. I believe I am using the same compiler settings for the files as Studio uses. I am using the archive tool shipped with studio to make the archive (.a). Work still to be done, Studio does not ship with any make programs (Make, GMake, NMake). Since I have used nmake in the past and had it I used it… GMake may be a better solution? I have not fully setup all of the source file dependencies to optimize when things get rebuilt…
C) Studio wish list: more control for building libraries
Thought of adding NMake and NMake clean commands to the Tools menu of studio. But currently the starting directory if not explicitly set starts up in some unknown place like c:\windows\system32… Also there is no clean way to capture the output of these commands and show them some place like the Build window. So currently I build at a command prompt.
Studio Wish list here:
a) If the startup directory is not set, default to the directory associated with the current project/file -Similar tools appear to do this
b) Someway to capture output. I may try adding the command line options like: nmake > nmake.log 2<#1 (double check syntax) to see if it will allow this to redirect both standard out and standard error to a file…
c) I wish Studio would monitor the status of open files. (wished it for awhile) Example if I have a .lst file open and I do a new build it would be nice, that when the build completes it would say something like: IOPins.lst has changed, reload? …
Could not get the the libraries: option in the c/c++ to work. Everytime the loader would say it could not find the library. Tried many different combinations. Note: did not work for me on stand alone command line either… With command lines, I tried: -L option to try to add directory…
Workaround: I hard coded it into the project36x4.xlc file for my project with a line that looked like:
INPUT(C:\Users\Kurt\Desktop\LynxMotion\C-Projects\BAPLib\bap28sup.a)
If anyone is interested in this stuff, there are several setup steps that I did and still some issues to resolve with going to a library:
a) To build this stuff my makefile assumes that the needed commands are on the command line search path. In Windows7, I did this by bringing up properties on Computer, selected advanced system settings, there selected environment variables, went to system variables and double clicked on path and added:
“;C:\Program Files\BasicMicro\Basic Micro Studio\h8300-coff\bin;C:\Program Files\BasicMicro\Basic Micro Studio\h8300-coff\h8300-coff\bin;;C:\Program Files\Microsoft Visual Studio 10.0\VC\bin”
This was the two directories with the compiler programs and the last one was where I had nmake.exe…
b) Issues with libraries: Where to put system startup functions as well as interrupt handlers and the interrupt vector. My library creates at least two interrupt handler (timer), hardware serial port, and probably others, So I want to handlers in the library, but how do I get these reflected in the interrupt vector. Can move all of this to library, but what if I want interrupts specific to my app…
c) Should start to merge all of this with MinionBuilder to cleanup my stuff and integrate a lot more of his stuff.
d) Should do some quick and dirty document that shows what is implemented…
This will be required in order to be able to easily share stuff with others. The first thing I look for when I want to do something in C is for an existing library that handles at least some of what I want to do. With the upcoming wide availability of the Arc32 board, I am looking to see if it will also be a great board to develop for in C. The Arc32 hardware ROCKS (I do not say this lightly), to be sure, but software can sure drive whether that hardware is suitable for a given application. I think the Arc32 has potential to hit it big for C development as well as it’s native basic like development. This is the hardware we need for robotics, IMO. We are going to need robust support for developing and sharing libraries of C routines.
This is standard C development stuff. Basic Micro Studio has great potential to meet all the requirements for a great C development environment.
I’m, real interested, especially now that the Arc32 is soon to be readily available to the masses. I have an Atom Pro on a BotBoard II to tinker with until I can get my hands on an Arc32 of my own. It would be nice to have a header file that makes a connection between the hardware pins on an AtomPro and Arc32 to the actual pins used on the appropriate MCU.
You’re doing some great work here, Kurte! Hopefully, once I have your current code (already downloaded) and can get up to speed on what you’ve already done, I can also help push things forward.
Quick update here:
Still no doc But I will get there sometime soon.
I have been playing around more with my library code including:
a) Fixed Makefile to use same settings as Stdudio does for compiling, so now both files with .c and .cpp both compile…
b) Started converting my coding style for where to put the { to what more of the people up on the forums appear to be using. May search for a version of the old utility cb (C Beautify) to make everything consistent. There have always been a few competing styles:
if (x)
{
...
}
or
if (x) {
...
}[/code]
I usually prefer the first form as the { and } line up, which makes it easy to match up, and some of the groups I worked with used this. Others like the second way as it takes less lines... No biggy... I have done more of the conversion in my BAPLIB directory, have not done so yet in CPhoenix2 directory.
C) My first reasonably working version of HSERVO (I hope) - I went through a couple of iterations here. I tried one with passing a variable number of args, but then there is no checking if my count matched... Tried a version which used the Arduino servo class, but did not like as there was no way to specify group moves and the classes did not help. So the current stuff looks like:
[code] HServoGroupMoveStart(); // start a group move
HServo(0, 1300);
HServo(1, 1400);
HServo(2, 1500);
HServo(3, 1600);
HServo(8, 1800);
HServoGroupMoveCommit(0); // do the commit with 0 time
I decided to to use mS instead of the HSERVO units of basic as it translates more directly to what people are used to. The apis allow you to start up a group move, specify any number of moves and then do a commit. If you do a HServo call while not in a group move, it does it immediately. You can also nest calls to Group move Start /End… Only when the count gets back to zero will the moves happen.
Currently only working on Bap28, using TimerW. I use all 4 compare match units GrA-GRD to start up 4 servos per 4ms cycle and the OVF to turn off any that were turned on. Appears to be pretty close timing wise. I have to do some fudging as to know how many servos I turned on, per cycle. Probably more fudging left to do, when for example multiple GRA-GRD happen on the same interrupt… Also lots more testing of the actual timed moves needs to happen. I did have code in that looked like:
for (i=0; i < 10; i++) {
toggle(5);
HServoGroupMoveStart(); // start a group move
HServo(2, 1300);
HServoGroupMoveCommit(250); // do in .25 seconds
pause(300);
toggle(5);
HServoGroupMoveStart(); // start a group move
HServo(2, 1700);
HServoGroupMoveCommit(250); // do in .25 seconds
while (!HServoIdle(2)) ;
}
And it looked like the timings and ramping up/down were in the ballpark. I probably need to do lots more tuning of the code… But in case anyone wishes to play…
.
My updated printf had a bug with the value of 0… If anyone needs it let me know and I will update the zip file otherwise it will be in with the next round of updates.
Note: I did not change the config file in the zip file to use the higher speed!
Ouch!
