Lynxmotion Tech Support

I am strongly considering setting up my own versions of the Arduino Phoenix code. Will probably set this up as several projects up on my Github account. The problems I am having with my/Lynxmotion current stuff is that it is all in one project and it is hard to setup and maintain multiple configurations that I can make changes to and then compile the code for several different configurations, using several different processors, or input devices, or Servo Drivers, or actual robot configurations, as all of the sources live in one directory that Must be the same name as the main Sketch...

So instead I am thinking that main sketch will turn into a simple shell, that calls off to main code that lives in Arduino Libraries. I am thinking of having 3 libraries, could go more could go less, Something like: Phoenix_Core, Phoenix_Input, Phoenix_ServoDrivers. I could make this all one library or could make it into 10 libraries and have a library for Phoenix_PS2_Input, Phoenix_RC_Input... Or could have these all with simple #ifdefs on which could gets included. However I want for example all of the Input classes to all be defined to the same class definition, like wise for Servo Drivers (SSC-32, Native Arduino Mega, Pic32, ...)

Then the main sketch like for a BotboarDuino, CHR-3, PS2, might be as simple as:


Thoughts? Suggestions?
Kurt

That could certainly work, and would be encouraged! Having reusable libraries for lower level functions is an excellent way to code.

A set of #defines will include the required header files and libraries. Listing all the options one might want, and either commenting out the define lines or setting them to 0 is a good way to see what's available to a particular program. OK, I see serial, PS2, and oh yes, there is an R/C lib that I should try! You get the idea.

Core or "Engines" to build 'bot control programs would be very useful.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

Hi Kurt,

That's probably a good idea to make it much more versatile.
But what if you want to edit the libraries? Do we need to use another editor for the libraries and then try to compile the current project in the Arduino IDE?

_________________
[b]Kåre Halvorsen, Zenta[/b]
-----------------------------------------
Zenta's blog
http://zentasrobots.com/
Zenta's YouTube channel
http://www.youtube.com/ZentaOlbaid
-----------------------------------------

I typically use the Programmers Notepad (PN.exe) that is part of the winavr package for editing. Once you make the changes to the files you can then go back to the Arduino IDE to compile them as part of the project.

FYI - With Arduino 1.0.1, it looks like the made it to minimize how many files need to recompile each time, so builds go quicker.

Kurt

I am playing around with some of this and having some issues on trying to figure out valid ways in the Arduino environment to do what I would like to do... In particular, how to have #defines set to configure how the libraries associated with the program are compiled.

For example: I would like to define something like: "#define USE_PS2" and when I build the program it will compile in the PS2 input controller... However I am not finding an easy way to pass this on through the compiler to build the library files. Obviously putting this into the .INO file will not work as that compiles separately. I am trying to maybe define a file in the sketch directory, with a name like: "Phoenix_Cfg.h", which I then am trying to have included in the library files. However so far I am not having any luck getting this header to be included.

Anyone try something like this before and had any luck? On normal GCC type builds I would simply define this as stuff that gets passed as defines as part of the environment, but not sure here?

Kurt

Sometimes i see a build file.

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

I thought that the Arduino IDE simply mashed together all of the files into one large program in the order that they're included. Meaning you could just include a config file first and that would come before anything else...

_________________
Devon Simmons, Former Programmer for Lynxmotion.
I can try to help, but I can only offer you my best effort.

Nope: there are a lot more details in: http://arduino.cc/en/Hacking/BuildProcess

You can learn a lot about what is going on, if you go into the Arduino Preferences and turn on the Verbose Compile option. In addition to seeing the generated commands, you will also see any compiler warnings that the Arduino Environment may have detected. Note: Sometimes it is not a good thing to not see possible errors...

All tabs that do not have an extension are concatenated together and built, however any tabs that have an extension such as .c or .cpp are built separately. This includes all library files.

When you do an Import Library into your sketch the compiler will append a -I<pathoflibrary> onto the GCC compile line for each file that is built. This is how the library header files are found. This is also why if a library depends on another library you must do an import library of both libraries into your main sketch so that the compiler can find both sets of headers. Note: if your source code use the include syntax like: #include "MyHeader.h" in quotes instead of brackets like: #include <myheader.h>, the compiler will also search for the header file in the directory in which the source file is located.

The problem is that the generated compiler command does not add a -I option for the generated sketch folder, so there is no way for the libraries to include headers that are located there.

In other environments, I would pass through the options, by passing arguments to the compiler, with an option, like: -DUSE_PS2 or -DUSE_SSC32. This is easy to do in makefiles, likewise it is easy to do in other environments like AvrStudio or ... where you usually have a Projects Options dialog, where you can pass additional options to the compiler and/or linker.

Hope that makes sense.
Kurt

I would now like to make a second stab at factoring the code into projects as i have several different robots with several different ways to handle the servos ((SSC-32, Arduino Mega itself...) and several different input devices and I would really love to be at a point where they all share as much of the common code as possible. Also I would like to do it in such a way that does not bloat the code. Part of the configuration could be easy by having the actual .INO file call off in Init to the different libraries and pass in things like which IO pins to use and the like, but what is not obvious is ways to say, don't include any code associated the GP Sequence as I want to save space.

Again this would be doable if I could somehow pass in Per Project settings (would do this in non-Arduino environment), Also it would be doable if Arduino would add the directory of the .INO to the header search path (but it does not).

One approach that would probably work, would be to have the majority of the code actually in header files (.h) instead of source code files(.cpp). Then your .ino files may end up looking like:



Note: May need to split some of these headers into two parts like:
Phoenix_input_PS2_Defines.h
Phoenix_input_PS2_code.h

But I am hoping I won't except maybe for Core as all of the class definitions and the like should be defined there...

Make any sense? Ideas?

Kurt

I have been playing around (actually currently skirting around this) and for step 1, I am merging in my latest changes into one code base. The way I am currently doing this is to have the main Hex_Cfg.h file currently is simply a place holder where you define which one you want and I have separate header files for each of my configurations. Looks like:


I then have each of the Input Controllers, with #ifdef around if it is being used or not: Like: #ifdef USEPS2 or #ifdef USESERIAL ... Currently the code base has the controller code for: PS2, Serial (using the old Powerpod Serial test interface), and Arbotix Commander 2 (Real simple but limited XBee Controller). Next will be to merge in my DIY XBee stuff, probably also including the ability to send debug stuff to the PC...

So far I have only merged in the SSC-32 support, will soon merge in some other Controllers for Servos, in particular Arduino Mega running servos directly, Chipkit Max32/Uno32 running servos, AX12...

Only the CHR-3 cfg file has been updated to allow multiple different processors, in particular it has Botboarduino, Arduino Mega using my Shield and Chipkit Max32 using my Shield. Currently I am testing it with the Max32 with SSC-32. Working well with Commander 2, currently debugging my PS2 controller support for Pic32s...

I now have a few of my projects up on github, including this one: BBDE_SSC32_PS2 (which is now a poor name for it). But warning, this is a WIP and which configuration is the currently selected one, depends on what I was last testing when I decide to upload... Note: I have not updated Lynxmotions Github accounts with any of these changes as I am not sure yet, if they are going to continue using Github nor what process they would like to use before things show up there or are updated there.

Once I make this pass through, I will try extracting some of these source files and generate libraries and then create several small projects that include just what they need.

That is all for now
Kurt

I am not sure if anyone is interested or not, but I have started playing around with this some more. I have done what I mentioned in the previous post and turned a bunch of the .CPP files into .h files, that get included into the main sketch. This allows me to pass in options and the like to adjust how the functions get compiled.

What I have done was to create a create several directories that would live in the Libraries folder (either directly where you installed the Arduino, or where your sketchbook lives). The main library is called Phoenix. In here is a couple of header files: Phoenix.h and Phoenix_Code.h. It also has several sub-directories with example projects like(THex_PS2_SSC32 which have default configurations for different robots). Other Libraries include:
Phoenix_Input_PS2, Phoenix_Input_Serial, Phoenix_Input_Commander - The input controllers I have so far
Phoenix_Driver_SSC32, Phoenx_Driver_AX12 - The Servo Drivers I have so far.

I have several of these projects compiling now. I will soon start testing them out on my different robots.

Note: Each of my test Phoenix robots, have a second file as part of them: Hex_Cfg.h which has the complete configuration information for the robot as well as Program Options. I am still toying with extracting a bunch of this out again probably to the main Phoenix library, where you can simply include things like: Phoenix_CFG.h which has all of the default stuff for a Phoenix, likewise for CHR3... That way the configuration stuff per example project would be rather small and probably simply a list of options that maybe override the main stuff...

Thoughts?
Kurt

Hi Kurt,

I am very interested. Someday I would like to retrofit my 4DOF T-Hex with a BotBoarduino and begin refreshing what little I know about C programming. (I first started programming in C on a Commodore 64 which probably predated half the members on this forum.) You can probably see why I know so little about C.

"Thoughts?" You know me well enough to know that's not going to happen. If I were capable of formulating cogent thoughts, I wouldn't be in this hobby. I barely reached a general understanding of the project you outlined in your message. Nobody wants your progress guided by anything I might say.

Nonetheless, I am really interested in your project as chance to learn something. What time tommorow will you have everything finished?

Thank you,

_________________
Ted, RoboTed
Never quite finishing means never having to admit failure!

will need to dig in that..

_________________
Eric Nantel
Qc Canada

Always liked Robot... Now i am learning to make some...! Wonderfull...

Hi Kurt,

You could take a look at how the MultiWii Arduino code is setup.

It supports lots of hardware and is quite easy to configure for your specific setup.

--Aaron

Count me in for testing the Phoenix code for RC // please add PPM in as its used on the MultiWii code for the quad copters, it works really really well to read 8 channels.

_________________
Is the warranty voided yet? ... and why not?

Thanks Aaron,

The difficult part with configuration stuff, is to make it easy for one configuration, but at the same time make it such that you can have multiple robots all sharing the same code and having it compile the libraries with options specific to each robot. So far the having the libraries be mainly header files appears to be working...

Will migrate my RC version over soon. I did have one of my robots working earlier with RC input. Don't have an 8 input version right now, but did have it working for 6 channel Hitec.

I am sort-of torn here, on my own personal priorities. Robot Dude earlier indicated that he wants(wanted) to have options for all of their Hex robots to be shipped with Botboarduino, so I have been trying to have a PS2 version of the different robots as that has been their main input device. I have done some testing on chr-3, thr-4 (T-hex 4dof legs), T-Hex and another not to be named. I have not done any testing yet with Phoenix (mine still has Arc32 in it), nor A-Pod (don't have one).

As for Input devices, I personally like using our DIY remote control, as it gives us tons of flexibility. Lately I have been having fun with the Arbotix Robot Commander that also uses XBees. I like it as anyone can buy one, but it is very limited, has no user feedback...). As I mentioned I have also played some with the RC code, which works a lot easier than with BB2... So will provide one for it. It is not my preferred input method as you have to move RC receiver from bot to bot and no bi-directional communications. I also have a version with Serial input that was compatible with old Powerpod program.

I am also interested in getting to run on other Arduino processors. I have it running on my Arduino Mega Shield, now with or without SSC-32 using my ServoEx library. Still some tweaks need to happen as servos do twitch, but that has to do with how Servo library works and if anyone turns off interrupts... I also have the code working for Chipkit Max32/Uno32 (Pic32 running at 80mhz). Still need to implement the ServoEx library for this platform.

I have included an updated set of libraries and examples in the zip file.

Kurt