Hi Zenta,
Hope you are having a great vacation! I will update the PS2 to work the same as I like it better as well.
There was code built into my Arc32 phoenix code that talked to a VB app that understood the CSV files and EEPROM? (I forgot I will have to take a look again). The VB app has the ability for you to define a pin mapping table, that allows you to take some of your original sequences for SSC-32 and remap the pins to the order of the Arc32. I think the EEPROM on my Arc32 in the phoenix was an early one that maybe only had 2 or 4K instead of the released 32K. May try to swap in my other one instead. So currently only my first sequence runs completely…
I have not mentioned this yet, but at some point I would like the ability to call of to an idle function from the main code. This is the way I added some other functionality like keyboard monitor, where I had the ability to download sequences, dump sequences, set debug level… for the Arc32 (I do this as well for propeller, Arduino…), but not Bap28 as there is no hardware serial support for serial/usb… May have to do this as part of My unofficial version.
I might be in for a new top panel as well after we finished the mods
Ok, back to topic:
Kurt I just compared the PS2 code.
#if PS2DAT = 0
PUCR5.bit0 = 1 ; Note these pull-ups may not be sufficient for all PS2 remotes.
#endif
#if PS2DAT = 16
PUCR1.bit1 = 0x1 ; 16 is on H8 P11 which has a pull-up
#endif
I’m fine with it and also agree with the overrule functionality for the PS2 pins. (kurt thinks: finally!) One question though, Do we only need software pull-ups for pin 0 or should we make something like PS2DAT < 16 to make it functional for all pins and not only 0 and 16.
So far on BB2 the only likely candidates is 0 and 16 as P4 does not work as P6-p7 (theory is because P6-P7 are are 3.3v output, my guess it could be something else as PS2 consoles are 3.xV…), P8 is not normally used as P9 is speaker. But if we wanted to we could enable it as well, as it is backed by H8 pin (P80 and P15), P80 does not have a pull-up resistor, but P15 does, so we could also have:
PUCR1.bit5 set for P8. The issue would be is the user may not want pull-ups on their other IO pins…
I have held off doing any enhancements here until Xan has integrated the current stuff. Also as you can probably tell, I was playing around with an idea for a diversion Bap64…
My next task will probably be to integrate more of my older Arc32 extras code into the new code base. I probably need to do this as I just swapped the Arc32’s in my Phoenix and now I need to get code in place to set the Servo offsets and to be able to download sequences…
But now back out working on the garden/chicken coop.
I went to the Microsoft DevDays this week. That’s where almost all my free time went. I might post something about it because I’ve met a NAO which was pretty cool!
I had some robotic time yesterday. I updated the phoenix (with DIY RC) with the current version. This because I’ve got some cool sequences in there So the Phoenix config file is up to date as well. I’m in the middle of figuring out what you guys build for the GP player. Hope to proceed on this on Tuesday.
Sounds like you’ve had an interesting week Jeroen, Nao sounds like fun!
So you swapped the ARC-32 Kurt, was it one of the earlier version?
I’ve also been busy with different stuff, but the most interesting part is that I’m resurrecting my old Phoenix. This time with some “quick and dirty” switches for TA and with an ARC-32 board only. I’m gonna use this as a test platform for the phoenix/ARC code mostly for testing out sections for MorpHex. But also for joining you on the TA stuff.
All tibia’s are finished and some are already mounted to the hex.
Here are some pics. As you can see I borrowed Jim’s principle of function and I’m also using parts from his other SES tubing leg. It seem to work very well!
Sort of exploded view:
The lower holder-part is glued to the end of tibia:
Completed part:
The picture quality isn’t very good since I took them at my office at work. But you get the picture…
The new foot is a little offset from the center of coxa, but I don’t think that will be a very big problem. Thats actually also the case for the LM Phoenix too. And we all know she perform very fine.
I’ll update my old Phoenix thread later, just wanted to share it with you first.
Any thoughts?
(Sorry, if you feel I’m hijacking this thread Jeroen, but I felt its was a bit relevant too.)
Yes the NAO looks pretty interesting! No not being held up at all, I had other diversions as well and plenty to do, and I may have to lay off doing very much on computer for a few days as my wrists…
Zenta: yes I swapped out the earlier beta ARC32 card with a production one. I was having troubles with storing sequences in the EEPROM, the first one stored great, but the second one would work part way and be corrupted. The early beta ones had smaller EEPROMs on them, where production had 32K bytes.
Yesterday I did get the Arc32 extras to build as part of the new code. I put a couple ifdefs in the main code that if defined called off to two functions: InitIdleProc and IdleProc. IdleProc is only called when HexOn is false. Good enough for my stuff, but could actually put in main loop always as well. Unless there is something to do, It is a quick call as it simply checks to see if any there are any characters to process, if not returns…
I downloaded this version to my Arc32 phoenix and ran my VB application and was able to download the 3 sequences I had in one file to the phoenix and then was able to use the PS2 to run it. I need to double check my XBee connections as it did not work with new board yet. Next I need to try the Servo offset code and update the servo offsets.
As I mentioned the VB app worked well here, I used one of Zenta’s sequence files and loaded it, use a servo mapper function, which converted the servo numbers from the order he had to my Arc32 servo numbers and then downloaded them to the Arc32. May also play with adding a new check box to the VB app that says we are talking over XBEE and also add a drop down list to choose the robot and then add the ability to download the sequence that way… VB works fine for me here. But at some point I wonder if a flowstone version should be written, or better yet add the ability to SEQ…
Zenta, I like your modified contact switch legs! Soon we should be at a pretty good set of standard phoenix code and we can start playing with the TM
Very interesting! Where do you have the servo mapper function? In a stand alone program or in the VB program? It would be fun to convert my old sequences from my original Phoenix. (Almost 1000 steps in total! )
If the new USB SSC-32 come with a XBee slot a checkbox for XBee com would be very useful.
It is in a standalone VB application (downloadsequences). The program can read in EEP files or CSV files and allows you to view the different sequences. There is a BAP program that I wrote earlier that it can talk to and save the sequences either to an SSC-32 or to the EEPROM on the Arc32. The Arc32 version was also integrated into my Extras package for Arc32 phoenix.
The mapping is done in a secondary dialog. I allow you to enter in the new servo numbers (index order) and if you tell it to map, it will update all of the sequences that it read in to the new servo numbers. So far I don’t have a write back to file function, but you could always hook up BAP to SSC-32, run program to download, then hook up SSC-32 back up to PC and use SEQ to read it back in and save EEP file. If wanted it probably would not be hard to add this directly to VB app. Likewise could add additional protocol to be able to have VB app talk to BAP program to be able to read in sequences from robot…
I played around some with the download sequences VB app today and added a new button to save EEP file. This gives you a couple of options to try things out. The code is in place that it will only save the sequences that the checkboxs are on. This allows you to pick an choose which sequences to keep. It took a little debugging, as I forgot that when I do selective saves I have to update the sequence number as the first byte of the sequence…
This program also gives you the capability to load a CSV/EEP file with your old sequences, remap the pin numbers and write it back out to a new file with the new servo numbers…
The basic program is in the zip file with the starts of the extras code, which I still need to fully debug. Also will need to remove lots of debug stuff…
I am using VB2010…
I’ve added the GP player stuff you guys made. And made it compatible with the DIY RC and Phoenix since the phoenix had some sequences.
The only thing is that I’m not able to go any faster then full speed. The manual says that the speed can be +/-200 but 100 to 200 makes no visual difference. I monitored the GPSM value. This varies from -200 to +200. Am I missing something??
I downloaded the version 2.06EGP from here. I can double check this when I get home from work. I tested this with the phoenix + DIY RC. I could swap it to the PS2 so I can test the version Kurt made. I kinda doubt that this will work since I monitored the string which is send to the SSC. But I must have been overlooking something.
What is the max and min values? The manual says +/- 200
I think I am seeing differences in speed here. My PS2 version of T-HEX scales the values to ±200. I know at slower values it does slow it down some or to a complete stop at 0, but I have not done any speed testing to see if the time scaling is actually correct or not. Could probably write some quick and dirty code to do this. That is when we detect that it goes from step X to Step Y, could toggle a pin and use logic analyzer to test it (or could use timer in code to see how long the diff was)
So it is great to see you are getting some XBee stuff. I think the sparkfun adapter on my Phoenix failed yesterday, so I robbed one from a different robot for now… I think I have a few wiring problems with the new Arc32 in mine right now, The GP sequences hang when running and I have to wiggle a few wires to get it to respond again… There are times when I wish I put the Arc32 on top with 6" wire extensions, Would be a lot easier to experiment with changes… Like trying out Propeller board…
I can also slow up the sequence to zero and reverse it at the same speed. But if I check Zenta’s last video, his sequence runs much faster and I have the same sequence! So I think there is no difference when going over 100.
Yes I’m really happy to join you guys on the XBEE stuff. I went to an local RC shop to check if I could get the left gumball to auto center. But the guys there simply return the remotes to the factory when something breaks. So they didn’t have any parts. I also disassembled the gimbal itself to see what components I needed and what the options are to get the extra pot on there. But I’ve no idea how I could can remove the brackets at the inside of the stick to clamp it in a lathe. Probably the best way to go for me is to order 2 of the 4 function gimbals from servocity. Saidly enough they only ship to Canada or the US… :’(
So the Phoenix config file is up to date as well. I’m in the middle of figuring out what you guys build for the GP player. Hope to proceed on this on Tuesday.
)
I also disassembled the gimbal itself to see what components I needed and what the options are to get the extra pot on there. But I’ve no idea how I could can remove the brackets at the inside of the stick to clamp it in a lathe. Probably the best way to go for me is to order 2 of the