Alfa release Phoenix Code

Let's Make Robots Project Ideas
21

Hi Kurt,

Sounds great! I hope your Basic Micro Studio can handle this correctly.

If I got this correctly the main problem is that some pins have pull-up resistors and other don’t. The pins I use on the BAP (12-15) do have them. But moving the remote to other pins or pins on another board we will get in to trouble right?
Ok, if we can’t go without the #ifdef’s it’s fine by me. But for configuration I would like to do something like:

  • PS2DAT con P12 ;PS2 Controller DAT (Brown)
  • PS2CMD con P13 ;PS2 controller CMD (Orange)
  • PS2SEL con P14 ;PS2 Controller SEL (Blue)
  • PS2CLK con P15 ;PS2 Controller CLK (White)
  • cEnablePullUps con 1 ;PS2 Controller Pull-up resiters (Comment out when not needed)
    Is this an option?

Yes I removed the non BAP related code. I did this because the hardware related code should be in the driver file. If I’m right we should be able to make a separate driver file for the ARC and one for the BAP40. Am I right or am I missing something?

Kurt, I hope I don’t get on your nerves by removing a lot of your work… I want you to know it certainly isn’t my intention.
Most of the users have one hex with one hardware setup. So my idea is to have a set of files for a different hardware configuration. This way, one does not have to figure out parts of code they never going to use. There will be a clean set of code for each of the hardware configurations.

If you are fine with this idea I would like to ask of you if you can build a driver file for the ARC and BAP40. The changes for the hardware dependent code should be in there. We also should update the DIY-RC and DIY-XBEE version. I’m fine my adding the “shut up” function in the main code. :slight_smile:

Thanks for your great input!

Xan

22

Hi Xan,

Well, actually studio does get confused, it thinks that the file opened up is only used in the project that was opened from and if I do a compile of another one, it does not save away the files… But I can work with it…

PS2: The DAT line of the PS2 requires a pull-up resistor. That is on an actual Ps2 console, there may be multiple controllers on the same input line, so the active one when necessary will pull the data line low, but they never set it high. On the actual PS2 controller they also had a pull-up on the clock line as well, but we don’t need that as our code actively puts the value high and low. The ABB had pull-ups on P4 and P7, which worked for Atom but not Pros… So BB2 put ones on P12 and P15. So if you now need to move the PS2 to different pins, you need to add some form of pull-up to DAT line. It turns out on the H8 of the Bap28, some of the IO pins do have built-in pull-ups that can be enabled. They are very weak, but work for most of the Lynxmotion PS2 receivers. This is what I had the code try to enable.

There are a variety of ways to add the pull-up code, which on the BAP, which is pin specific, but simply requires you to set an appropriate bit in one of the H8 IO registers… We could add the option you mentioned, but personally not sure if it makes the code easier to read than simply having the IF being driven by the actual value of PS2DAT, but for the most part this is all minor stuff…

Actually it is all BAP code we are talking about :laughing: You removed all of the non Bap28 code.

I totally understand your desire to have 100% clean code, that is specific to the end users specific configuration. But I don’t think we can or should try to get 100% there. Example: None of my Hex robots have EYES, so there is code in the main area that is not specific to any configuration that Lynxmotion sells. I personally think EYE code should be under a #ifdef of the pin number…) So to be completely clean we should build configurations of the code that PS2 based with eyes and another version of the code for PS2 without eyes. And none of my robots have LIPOS, so we should build versions with PS2 with or without Eyes and with or without LIPOS. So in theory we could end up with quite a few configurations, which would also be extremely confusing. Especially if later I decided to change something in my configuration, what file(s) do I need to update if I now have a LIPO or … But to be clear I totally agree with your desire to reduce this to a reasonable minimum, which is why in the code that I have that I have been integrating in this, I have removed a lot of built in debug code that I can compile in or out. Sometimes I think of leaving some, for example PS2 diagnostic code that I could turn on to see what data is being received. Why would I potentially leave this? Because I can not count the number of times I have had to recreate this for users whose PS2 does not work…

Yes I could create new code files for each of the BAP platforms. The main thing that changes is the Timer. They are also simple differences. The only things that change are the Timer variables, Interrupt name and conversion factor to convert the counts to milli seconds. Boy how I wish the BAP stuff had better ways to abstract things. That is with Arduino code I simply call millis(); I don’t care what speed the CPU is, the same code works if running on 168, 328, 1280… Will also need to move some or all of the LIPO safety code there as well. Why? Because in their infinite wisdom, when they created the Arc32 they decided to add a new command HServoStat to read in the Analog data, instead of abstracting out the hardware implementation and simply having the user use the adin command…

Xan, I hope you don’t think I am trying to fight you here, I think you are doing a great job. I am simply trying keep the code as inclusive to as many people as possible. I also worry that when new functionality is added, it will be only usable to the users who have that exact configuration, or there will be 10 versions of the same code, all slightly different, which can also be a pain to maintain… So hopefully we will find a happy medium… I can see a day that we are adding TA code and you run out of code or data space on the Bap28 and have to make decisions. Maybe it will be to add options to the code to #ifdef out parts of it, or maybe you will decide to try an Arc32 or… Just trying to keep our options open.

On the running sequences code with speed changes. I have most of the code in place. Still a little more to do, but I know what it is. Will also add that the Arc32 version as well and then will upload new set of projects to look at.

On DIY XBee, I have it compiling, but I need to figure out different configurations for this as mine does not have the extra pots that Zenta’s does, so need to remap some (Probably under ifdefs :laughing:). Was also waiting for your drop last night as the rotation stuff has code in it for changing the rotation centers, which it sounded like you added to the main code…

Kurt

Xan,

23

Just a note that there are currently 4 revisions of the PS2 cable, and they all have slightly different colors. May want to just list the function and leave the colors out.

24

Hi again,

I think I have the run a sequence with speed adjustment code working now for PS2 on SSC-32 (THEX). I have not implemented it fully yet on ARC32 emulation of sequence code yet. Need to figure out what changing the speed implies. That is if you are in step X which takes lets say 100ms to complete and you say go to speed 200% does this start at this point or at the start of the next step. Or if you say go to speed -100% does it first complete the current step or does it start NOW…

With the PS2 code, I left the default when you press the R2 button to run the sequence at 100%. I switch to variable mode if during this you press the R1 button. Feel free to change or suggest change… I have included the current code/projects. The XBee version does not compile yet as I need to figure out some of the new stuff and how to configure for with pots and without…

Kurt

P.S. - You will probably want to remove some of my PS2 init code…
Phoenix21k.zip (49.1 KB)

25

I now have the XBee code building, I had to undo some of the changes I had made to the code as the variables changed to BodyRotY -> BodyRotY1, which was where I started from, when I used Zentas earlier version.

I have the extra 2 pots under #ifdef. Zenta or Xan do you have suggestions on Joystick/Slider… usage when we don’t have Zenta’s hardware modifications to the remote. That is the Left joystick UP/Down does not self center and 2 less controls. For some of this I will probably default to control usage of earlier versions, but does anyone have any other suggestions? Xan this will probably be the same control usage for DIY RC version.

I will start playing with it next, and will add in the GP player feedback. To do this I will probably create the 4th project for T-Hex/SSC-32/XBee.

Kurt
Phoenix_Control_DIY_XBee.bas (52.7 KB)

26

Hi Kurt & Xan,

What do you use the (throttle) left up/down joystick for, wasn’t it body height? I’m using the left pot for that. So far I’m not using the right pot very much. But having the left joystick self-centered is very convenient. The ifdefs for extra pots are ok for me. But this also mean that if you choose to add two extra pots the left joystick also need to be modified. If I recall, Xan also wan’t to add two pots when converting to XBee. The question is if he manage to modify or replace the gimbal… :wink:

For avoiding even more ifdefs for pots and centered Ljoy I suggest to keep it like you posted.

When it comes to the use of #IFDEF I agree with you both… :unamused: I like the feature of turning off/on some parts and for debugging. And as Kurt mentioned memory space on the BAP28 are going to be challenge. For example I can’t compile my 4DOF T-Hex with the GP part included.

I also like the code clean and easy to read. Using several files and projects is a good solution.

I hope you can come up with an agreement without to many restrictions. :smiley:

27

just a note, I inquired with Dale with Basic Micro about the ifdef and graying out the non used parts of the code. I’m not sure if it will happen or not though.

28

Sounds good. The last email I received from Nathan (about a week ago he said)

As for color coding, It would be nice but my gut tells me there will still be issues with it. For example currently, if you have a project open, and you are working on the third file in the project and you have a lot of the variables defined in the first file, it will only color code the variables in the third file if you have the first file open. And if you are the rare person like me who may have multiple projects open that use the same files, it does not handle this overly well. But every little bit helps!

What he was referring to as the #define issue, was maybe some way for me to define the C equivalent of #define, such that my debug stuff does not look like:

#ifdef BASICATOMPRO28
serout s_out, i9600, ...]
#else
hserout  ...]
#endif

Where maybe we could define something up front that defines something like: DebugOutput] and it would expand out appropriately depending on the platform (C macros…)
Not holding my breath, but would be nice. If he does implement a reasonable version of this we can bury a lot of the potentially conditional code.

29

Hi All,

Ah, I was away for one evening to do some sporting and look at all the new posts :slight_smile:

Good to hear it’s on the todo list. :slight_smile: This would defiantly improve the readability.

Kurt, as for all the #ifdefs. You are totally right that the current release has some custom code like the eyes which is not stock for the phoenix. I know that we can’t get rid of all #ifdefs and I’m pretty sure we will find a good solution in the middle. :slight_smile:

You’ve got this totally right! I want to have the left stick auto centered as well and add the pots on the sticks as well. As for what stick controls what; I’m sure that what you guys will come up with will be great to work with. I just join along when my remote is finished. But that will be after V2.1 is released. :wink:

Let me know if I forgot to answer something!
Thanks guys!

Xan

30

Jeroen, got the Xbee stuff on order. Will send it with the Phoenix parts probably next week.

I have Aurora gimbals on order from Hitec. These are a little better than the ones we used to make the DIY radios, they were from a Laser 4. These new gimbals have the parts needed to autocenter. I should have them in June I think…

31

Sounds Great. From this I am reading it is time for me to update my DIY remote to add at least one knob and change the left stick to a self centering one. I do have one that I ripped out of an Exceed RC remote control earlier. Not sure how hard it would be to mount it. It looks like it has the same 4 mounting holes. But it also has 2 center adjustment things that would require slots cut in the plate, or somehow remove them… (Or should I wait for the Aura ?)

Zenta, you say you don’t use the right pot much, so I am thinking of leaving this one off and still have the speaker. Sound reasonable?

Kurt

P.S - If this looks easy I will do it quickly now, else may ifdef different mappings for now. Do have a few other things to work on, like:

Order parts for Arduino
Help with coding here
Documents…
Finish Chicken coup ( install fence and gates, build perches, reinstall garden beds, plant, …)

32

We cut the adjustment tabs off the laser 4 gimbals so we didn’t have to put the slots into the panel. Let me know if the ones you have can’t mount and I will send you some of the new ones when they get in. Maybe we can have a hub made that would make it easier to add the pot to the stick. I’m not going to try and embed the wires though. I think it should work ok…

33

I think it will mount. I cut off the tabs and it looks like the screw holes will work. Looks like it has about 5K pots in them so that should work. Need to solder on different wires, probably cut a larger servo extension wire in half. and then figure out which sides to mount black versus red such that the Resistance goes in the same direction as the old one. Currently don’t have the patience or the machinery to drill holes through to run wires or the like so will probably mount pot(s) below my 4 switches to the right of the keypad, alternatively could mount in the side of the case, but that may make it harder… Suggestions?

Kurt

34

Yes, that sounds reasonable in your case. Oh, I just forgot. I do use the right pot too, on A-Pod for controlling the mandibles… :wink:

If you are able to get your hands on some rather small pots I would recommend placing them near the gimbals. A place where you easily can reach them without having to move your hand to much. Maybe on the top-side of the case.

35

Thanks,

The new Gimbals works :slight_smile: I had to rerun the calibrate function (Glad I added that), as the resistors on this are the 5K range, but run from more or less 0-5K where the HITEC ones don’t change as much. Old code in place so it did not recenter the Y of the new joystick. Was able to get close by adjusting the remains of the tab that I cut off…

My local Radio Shack only had the rather large pots, may be able to scrounge some others, but may temporarily wire in these big boys and maybe mount them in the temporary cover I put in place to cover where the RC transmitter was. Will also use the smaller Sparkfun or Parallax Xbee holder and probably put the xbee inside the case… Should be good enough to test things out. And can probably reach a finger over to maybe manipulate it while still on joystick. At least that is my current plans…

Update: I think I have it all back in one piece now:
DIY-Remote-with-updates.jpg

As you can see the new control does not look quite the same as the old ones. Not sure if I should put a plastic cover over it to make it semi-match the other one. Maybe someday should come up with a standard layout and make a new top plate, but for now this gets me back up and running.

I rebuilt the Transmitter with the extra pots code installed, so now I can get back to testing the update Alfa code with DIY…

Kurt

36

Looking good Kurt!
So now you have extra pots and centered stick, thats great! :smiley:
One thing I would prefer on the pots is to have pots with a tactile feedback when its centered, like a balance pot on a stereo amplifiers. Mine doesn’t have that but I imagine it could be useful in some cases.

37

Thanks Jim! I’m looking forward to upgrade to XBEE. :smiley:

June? That’s not exactly “Order today. Receive tomorrow” :slight_smile:

I found a local shop who is selling parts for RC cars/helicopters and etc. I’m gonna pay them a visit today and see if they have something to get the left gimbal to autocenter. Some time ago I asked a friend to help me with the pots on the gimbals. He has a lathe at work and is able to make the holes for the wires. I hope he also has an idea for a hub to place the potmeters. It would even be cooler if we could exchange the current stick with a a complete, normal-size, potmeter. But I didn’t check if that could work…

Kurt, I see you went pretty quick with the update. That’s great!!

Something else… I read that you have to choose between the speaker or potmeter. Maybe we could overthink to swap the BAP for the ARC in a later stadium… But personally I want to focus on the TA for now. So much ideas and cool stuff to do! :smiley:

Xan

38

Yep, I decided that I would rather spend a little time now and get it working, such that I don’t have to worry about what to do to keep the code compatible with Zenta. It will take me a little time to get used to the new layout of things, like using the pot for the body height. For me the slider is more obvious, but if of course the pot was part of the the stick itself, it makes it easier to control it all at once… Maybe when Jim gets in the new Sticks and figures out, some standard pots and mounts for them, I may upgrade to them. Then just need to put a blank over where the receiver was removed…

Yep, I miss the speaker. I think it is nice to have the ability for audio feedback for example when the robot is getting into trouble or the like…

Maybe have to write a Botboardduino Mega version :bulb: Can use temporary hardware like Seeeduino Mega, which has 16 analog inputs and maybe 60 digital… Then maybe Zenta could add another 8 controls :laughing:

Now to do some more testing with updated XBee. Like feedback and control of running sequences. Will need to change all of my robots to handle it… At worst at least to ignore the added bytes to the packet…

Kurt

39

I have been playing around with the updated remote and the code for it. I have put in the feedback code for running sequences and seeing feedback. In the XBee version, instead of having to push a different button to enter into speed/direction change mode, I default to 100 which is run 1 to 1 and if the right stick vertical gets moved out of the deadband zone while the sequence is running it then switches to output different speed multipliers… I think this is more intuitive than what I did on the PS2. I will probably go back and change the PS2 version to do the same, but thought I would get your input…

Side note: I wonder if the cTravelDeadZone define in the core code should maybe be moved to the CFG file or at maybe allow the CFG to override. That is it could be:

#ifndef cTravelDeadZone cTravelDeadZone con 4 #endif

Yes I know that you don’t like #ifdef, but what I was wondering is if the the Deadzone should be the same for XBEE/RC/PC control as it is for PS2… Just a minor thought.

I have uploaded an updated version of the sources including 4 projects. My emulation of changing the execution speed of sequences in the Arc32 is mostly in place but still needs some testing/tweaking…

Update: Fixed at least some of the Arc32 speed issue. That is I was doing TimeDelay= (requested time)*SM/100 which is wrong should have been:
(requested time)*100/SM (note actually it is ABS(SM) as negative implies run backwords…) Still need to do more work testing and probably tweaking to this…

Also forgot to mention. I did add in call outs for don’t interrupt me now code…

UPdate2: I updated the PS2 as well to use the assume run sequence at 100% speed unless the user moves the right joystick…

Kurt
Phoenix21k.zip (59.3 KB)

40

Sounds like a very good and intuitive solution. I like it! :smiley:
I’ll take a look at this part of the code when I’m back from my vacation and try it out.

Btw, where did you post info on how to upload sequences to the ARC-32?

I’m thinking of playing a bit more with the ARC-32 solution so I might put together my old original Phoenix with an ARC-32 only. Also a good test platform before I start the code work for MorpHex. Will be fun to bring Phoenix back to life again.