Alfa release Phoenix Code

Let's Make Robots Project Ideas
121

Hi Kurt,

Sorry for my extremely late reaction. Please PM me any time if you need a quick reaction. I have to admit that I’m not quite sure what the latest status is. I remember that the 4DOF needs to be tested and that I was in the middle of upgrading my remote to XBEE. My vacation and “home”-projects kinda wiped part of my memory… :frowning:

Currently I’m replacing my driveway, which is our last “home”-project for this year. :smiley: I’m planning to get back on robotics in about a week or 2. First thing on my robotic list is XBEE and a new release.

Feel free to post your current version as beta version if you want. I don’t want to hold you guys from improving the code when I’m hold up by other projects.

Hope to be back soon!!

Thanks, Xan

122

Yep, I know about home projects as well :smiley:

As for 4DOF, I ordered some extra parts on Saturday (with the new free shipping), that I will attempt to convert my CHR-3 into a CHR-4. I am hoping that the 645s will be up to the task.

As you can probably tell, I have been playing around with the XBees stuff and seeing if I can speed up the protocol more.

Will be great to have you back :smiley:

Kurt

123

Hi Jeroen,

Long time no see. :smiley: It will be great to have you back!

I have just one more home project as well. Then I’m in for a long winter of robot bliss! lol :slight_smile:

124

Hi guys,

I will post a beta version in the next couple of days. I did a quick look and the SSC-32 based version still has the issues of sending the Speed stuff as part of the update drivers and not part of the commit, so it wont be waiting properly. I will fix that. I also see that it is not doing any output for the optional 4th DOF, which I will also hack in. Will test that part probably next week as even if the parts shipped today, they probably won’t get to me until Friday at best…

Likewise the Arc32 version, is not doing any output for 4th degree. Also has code in place to not output Speed for first move to work around HSERVO issue. Will check to see if this is still needed with current IDE.

Zenta, Xan, Robot Dude… let me know if you want me to post them here first and give you a chance to take for a quick shake down cruise…

Kurt

125

Quick update: Here is a zip file for T-Hex with PS2. Has changes for commit and some support for 4dof…

Also Arc32 version of phoenix code with PS2…

Kurt

EDIT: Also here is a quick and dirty Serial version for T-Hex, that works with the powerpod test program…
Phoenix Beta 2_1 Phoenix Arc32 Ps2.zip (31.2 KB)
Phoenix Beta 2_1 T-Hex SSC-32 Serial.zip (21.1 KB)
Phoenix Beta 2_1 T-Hex SSC-32 PS2.zip (21.2 KB)

126

Hi Jim and Kurt,

Thanks for the warm welcome back! :smiley: Looking forward to spend the cold days with my bots again :slight_smile:

@Kurt, I’m really short with my time at the moment since I need to get my driveway ready for this Saturday. The contractor will make the new driveway this Saturday and I need to do some pre-work (cabling, water-pipes) before that.

If you think the version is good to release as a beta, feel free to do so :slight_smile:

Thanks Xan

127

Thanks Xan,

Good luck with the driveway. Put in lots more cables, conduits, etc than you think you need, as you will probably find out later you forgot something.

I need to make a minor change to the T-HEX PS2 version. I still have the override in place to move PS2 to pins 16-19, to allow me to use the hardware serial port for XBee… Should remove that for general consumption…

Kurt

128

I ran into some issues with the T-Hex 4DOF code and setup. I will work on my version of a work around, but thought I would mention it here and then later on the public beta thread…

With the 4DOF legs, we first go through and first find the servo offsets and then we move two of the servos by 1 click (15 degrees). When Zenta did this originally he simply added some offsets into his code to compensate for it. If he was using the servo offsets, which are limited to less than 15 degrees, he then added some code to the T-Hex 4DOF code that compensated for these 15 degree changes. In particular:

In the config file:

;-------------------------------------------------------------------- ;[Joint offsets] ;First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then: cFemurHornOffset con 150 ;Snap out the horn one click upward cTarsHornOffset con 150 ;Snap out the horn one click inward

And in the main code he changed:

;IKFemurAngle FemurAngle1(LegIKLegNr) = -(IKA14 + IKA24) * 180 / 3141 + 900 + cFemurHornOffset ... TarsAngle1(LegIKLegNr) = (TarsToGroundAngle1 + FemurAngle1(LegIKLegNr) - TibiaAngle1(LegIKLegNr))

To make this more table driven, to allow per leg configuration, I changed our current 2.1 code, to make it Table driven…
That is I added to my config file:

[code];--------------------------------------------------------------------
;[Joint offsets]
;First calibrate the servos in the 0 deg position using the SSC-32 reg offsets, then:
cXXFemurHornOffset con 150 ;Snap out the horn one click upward
cXXTarsHornOffset con 150 ;Snap out the horn one click inward

; Set up to have per leg offsets…
cRRFemurHornOffset1 con 0 ;cXXFemurHornOffset
cRRTarsHornOffset1 con 0 ;cXXTarsHornOffset

cRMFemurHornOffset1 con cXXFemurHornOffset
cRMTarsHornOffset1 con cXXTarsHornOffset

cRFFemurHornOffset1 con cXXFemurHornOffset
cRFTarsHornOffset1 con cXXTarsHornOffset

cLRFemurHornOffset1 con 0; cXXFemurHornOffset
cLRTarsHornOffset1 con 0; cXXTarsHornOffset

cLMFemurHornOffset1 con cXXFemurHornOffset
cLMTarsHornOffset1 con cXXTarsHornOffset

cLFFemurHornOffset1 con cXXFemurHornOffset
cLFTarsHornOffset1 con cXXTarsHornOffset
[/code]
Note: I hacked on my version here to set 2 legs to zero as they do not have any offset… Still old leg…

I then defined the cFemurHornOffset as a swordtable and then changed the code like above except use LegIndex…

; Servo Offset Table ccFemurHornOffset1 swordTable cRRFemurHornOffset1, cRMFemurHornOffset1, cRFFemurHornOffset1, cLRFemurHornOffset1, cLMFemurHornOffset1, cLFFemurHornOffset1 #ifdef c4DOF ccTarsHornOffset1 swordTable cRRTarsHornOffset1, cRMTarsHornOffset1, cRFTarsHornOffset1, cLRTarsHornOffset1, cLMTarsHornOffset1, cLFTarsHornOffset1 #endif
Now I have a couple of options here. Example could change the swordtable above something like:

; Servo Offset Table #ifdef cRRFemurHornOffset1 ; Per leg definitions... ccFemurHornOffset1 swordTable cRRFemurHornOffset1, cRMFemurHornOffset1, cRFFemurHornOffset1, cLRFemurHornOffset1, cLMFemurHornOffset1, cLFFemurHornOffset1 #else ccFemurHornOffset1 swordtable 0, 0, 0, 0, 0, 0 #endif

Note: this change is helping the CHR with T-HEx 4 legs walk better… Note: I have not check out T-Hex 3 to see if it needs something like this as well.

Suggestions?

Kurt

129

Hi Kurt,

When I read your post the first thing that came to my mind was: “Why not simply add the horn offset to the servo offset?” But then I realized that the servo offsets are moved to the SSC. Am I right that the SSC registers are not large enough to store the servo offsets + horn offsets?

If not, I like the table setup. But you can remove the #IfDef’s. Just set the offset to 0 in the configuration file if you don’t need them. Hate #ifDef’s… :unamused:

Xan

130

Yep, the Horn offset in Zenta’s original stuff was simply added to the servo offsets, but when we moved this to the SSC-32 offsets, it is limited and as such he added the code to add on an additional thing of Horn offset.

My current code does not actually have the #ifdef, but it won’t compile with all of the current …_cfg*.bas files, so we simply have to add it to them.

I know that you hate #ifdef :stuck_out_tongue:: , but we are trading off code robustness/flexibility… Personally I really wish that BM Basic had the concept of #define like C does. As I would/will (in Arduino case), add the + SERVOHORNOFFSET(legindex) on to the equation. In the normal case of 3DOF with no offset, macro will be defined to simply return 0 and the compiler will optimize it away…

Kurt

131

Hi Kurt,

I’ve downloaded all your Beta releases from this topic. I would like to get them up as final release. But as usual I have some questions :wink:

Here is my old dusty list:

When looking at the final version it seems that some points are finished by you! Thanks!
6. Looks like it’s all in there. Is it tested?
14. If I can remember, there was a bug in the SSC. Is this fixed?
15. Is this tested?

I also found a little variable IDLEPROC. Can you tell more about it? Is it just for testing? what does it doe exactly?

You posted different zip/rar files with the different setups (example: Phoenix with PS2). I think this is a smart idea! This keeps it simple for the end users. What do you think Jim?
Side note: Kurt, how do you arrange your files? Do you have everything in one folder or all separate folders? Having separate folders makes it easy to keep the needed files together but you can also get in trouble when tracking changes of a shared file like the core.

I quick and dirty changed the DIY XBEE file to make it compatible with my 2DOF joysticks. I changed the name of the current DIY XBEE to “Phoenix_Control_DIY_XBee_3DOF_Joys.bas”. My changed file is called “Phoenix_Control_DIY_XBee_2DOF_Joys.bas”. I don’t think it’s worth sharing but if you think different, let me know.

The header of the XBEE DIY file is outdated. The in commend called controls are from the DIY RC with 2DOF sticks. Since the file is updated to your version of the remote, can you update this please?

Edit: oh, and what is in the “ARC extras” file?

Thanks! Xan

132

If you like it, I like it! :smiley:

133

It is always good to have questions :wink:

The SSC-32 is working OK with limitations. That is you can only speed up

4DOF/mixed. Is in and at least partially tested. I went from a 3DOF CHR to a 4DOF CHR with T-HEX legs. I also did some testing with only 2 legs converted than 4, than 6…

IdleProc and Arc Extras file are inter-related. That is the extras are just that. I have a debug monitor that checks to see if there are any inputs on the USB serial port, when the program is in an idle state. In there are things like turn Debug on or off, plus the ability to download sequences which I store in the EEPROM of the Arc32, plus there is a function to allow you to view what sequences there are, plus there is a command that allows you to enter into servo zero offset mode and find the appropriate offsets, which again are stored in the Arc32 EEPROM. All or part of this can be configured out, which for example Zenta does to get enough room on some robots.

Yes, I split these all out as separate zip files as it looked like the 2.0 versions were that way on the project pages. I personally keep all of them in one folder as I don’t want to have to remember to make the same change N times…

The comments file names for the DIY files could easily need to be updated. I have not paid as much attention to these, as so far there are only 3 or 4 of us that use them.

Hope I answered all…

Kurt

P.S. - will be great to have these finalized and released.

Side note: also for Jim, Beth, … I am still wondering about some level of archives. For another project Arduinos and UNO32, I have made changes to the PS2X_LIB to make it run on the UNO32 (which is PIC32 based). I have been talking to the developer of it on how best to maintain the sources and have it run… He is using the GIT command and has his sources hosted on GITHUB as are many other of the projects I see for Arduinos and the chipKits (Uno32). Wonder if we should do something like that as well. Don’t have any experience yet with GIT…

134

I forgot to mention in the previous post, that with the DIY XBee version, I will probably try to make a version that handles multiple different remotes. Why? Because I will have a couple different ones in different configurations and it would be nice to have it such that I could pick up any remote, choose the robot and use it. The code will handle differences by the type of data returned. Also this may be inline with having a few different kits with different configurations sold by lynxmotion.

That is, it could maybe handle:
a) Simple 2 joystick with sliders, like the original.
b) Added 3rd knob per joystick or the like
c) Nunchuck version…

Kurt

135

Beth is looking into the GIT thing. I know nothing. lol

136

Ok, Let’s make a zip file for each of your kits. You can use the packedges in the tutorials. And a zip file containing all files for our custom builders

  • Phoenix, SSC32, PS2
  • 3DOF T-Hex, SSC32, PS2
  • 4DOF T-Hex, SSC32, PS2
  • Custom: All files including XBEE and ARC files

Am I missing something?

137

When reading the SSC manual it should be possible to slow down. Jim, any news on this?

It sounds like it is fully tested then. What part is not tested yet?

Can we move this variable to the ARC file? I don’t think it’s used in the core. Would you like this debug functionality kept in the final release?

Thanks, yeah I think that having all files in the same directory is the way to go. As said in my prev post, I’m gonna make a zip file for each of the kits to get new builder started quickly.

If I ask you very sweet, can you help me out and update the header for me? :unamused: I don’t have the same functionality on my remote yet. So I’m afraid I will overlook something…

As always: Yes! Thanks Kurt!

138

I can think of multiple ways to handle different remotes.

  1. Having a file for each type of remote. cons: you have to change the project file and reprogram the bot when using a different remote
  2. Having a single file and use #ifdefs to switch between different remotes. cons: you have to reprogram the bot when using a different remote. All #ifdefs don’t make the code more readable…
  3. Let the remote send a “Initiallization packedge” to tell the bot what remotes is connected. Then change the remote type. Cons: The robot will always be stuffed with a lot of code that is rearly used. I think most users (including myself) always use the same remote.

Personally I like the way of having multiple files to setup the configuration. But this offcourse is my personal thought. :slight_smile: You can always build a one-file-suits-all remote file. As long as it fits in there, there will be no issue :slight_smile:

Xan

139

3a) Have the remote send the init packet. Have a file or a set of files that you can enable one or more different configurations, which you can enable or not. So if you only have a 2DOF joystick configuration you simply enable that and that is all of the code that is included in your robot. That is the direction I will aim for. Personally I am not sure how much additional code that will really add. That is, in the control file you are maybe setting 10 or so variables to control things. Move X, Y, Z, Rotate X, Y Z Translate X Y Z. Speed, leg lift… The code could probably be set up such that when the init packet arrives a table is init which tell where each parameter is mapped from, In some cases there would need to be some additional support to switch things around. Like with original remote, buttons to change from walk mode to translate mode, …

I know you hate ifdef’s but I personally hate file proliferation as that also creates real headaches. That is you add 2 new features to yours and I add 3 new ones to mine and someone else wishes to use these features…

As for most users always using the same remote, that is very true, except maybe, you would like to play with my VB app that runs on your PC and talks to the robots using the XBees. Or maybe you want one of your robots sending commands to a second robot… Lots of fun possibilities.

Luckily we don’t need to nail this down yet as there are no standard remote control kits being sold. Once there are, than we can see how best to handle the different configurations that Lynxmotion sells.

Kurt