Refactoring and Setup for my Arduino Phoenix projects

Lynxmotion Legged Robots
1

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:

#define USE_CONTROL_PS2
#define USE_SERVO_DRIVER_SSC32
#include <Phoenix_Core.h>
#include <Phoenix_Input.h>
#include <Phoenix_ServoDriver.h>
void setup() {
  PhoenixSetup();
};

void loop() {
  PhoenixLoop();
}

Thoughts? Suggestions?
Kurt

2

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

3

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?

4

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

5

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

6

Sometimes i see a build file.

Alan KM6VV

7

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…

8

Nope: there are a lot more details in: 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 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

9

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:

#define PHOENIX_MAIN  // Some definition that says to generate the code as part of this source file
#include "Phoenix_Config.h"  // here is where you may define all of the options... Maybe split into parts, some from library, that has dimensions...???  Could be inline here...
#include <Phoenix_Core.h>
#include <Phoenix_Input_PS2.h>
#include <Phoenix_Servos_SSC32.h>

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

10

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:

[code]#ifndef HEX_CFG_H
#define HEX_CFG_H

// Only include one of these configurations!
#include “Hex_Cfg_Chr3.h”
//#include “Hex_Cfg_Thr4.h”
//#include “Hex_Cfg_THex3.h”
#endif
[/code]

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

11

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
PhoenixInParts.zip (98.6 KB)

12

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? :stuck_out_tongue:

Thank you, :smiley:

13

will need to dig in that… :slight_smile:

14

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.

15

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
PhoenixInParts.zip (127 KB)

16

Started playing with RC version again and remembered that again this is where you again run into configuration issues with Arduinos. That is I wish to use the Pin Change interrupt to capture the RC information. If my memory is correct the Atmega 328 all IO pins have this interrupt capability and this is split up over three actual interrupts (up to 8 IO pins on one such interrupt). Software Serial also makes use of Pin Change Interrupts and it blindly defines it’s own interrupt handler for all three interrupts. So if you try to define your own handler you end up with duplicate Interrupt vectors… I got around this my first time around by moving the SSC-32 to the hardware serial port, but this usually leaves you having to unplug this cable each time you wish to program your board and you don’t have the USB to output debug information to…

Ideally it would be nice to be able to configure SoftwareSerial for this project to say: don’t use this interrupt or only use this interrupt… But…

Oh Well back to reality…

Kurt

17

Maybe you could daisy-chain the interrupt you intend to use?

Alan KM6VV

18

Thanks Alan,

Yep, there are obvious ways to fix things like this and I am not the first one to run into this one… Example:

code.google.com/p/arduino-pinchangeint/wiki/Bugs

Their suggestion is that, you copy the Software Serial library to somewhere else like MySoftwareLibrary and remove the code for the interrupt you want to use… Which I have done in the past, but I personally think that approach sort-of sucks…

I need to double confirm this, but I believe that the interrupt vectors live in program space and not in data space, otherwise I could do like I have done before of having the code of a new library query the interrupt vector and if there is one hold onto it and insert your own on to it and if the interrupt is not yours, pass it on down the line…

As for PinChangeInt code(code.google.com/p/arduino-pincha … wiki/Usage), they allow you to configure it as they put all of their code into the header file. This is one of the place I found this approach and gave me the idea for the Phoenix code… However I should also note, I am not using their code as I mucked it up to hopefully make it work across my boards (Atmega328-Arduino, Atmega644P-Arbotix and Atmega1280-Megas), My code uses the Pin information that was added into the build 1.0.x (Arduino\hardware\arduino\variants\standard\pins_arduino.h) or similar depending on which board is selected…

Enough whining :laughing: for now will simply run with SSC-32 on the hardware serial port :stuck_out_tongue: and maybe leave this for an exercise for the reader…

Kurt

19

As I mentioned in another thread, I now have all of the code up on github\kurte

As a another diversion, recently I ordered some new boards from Basic Micro, in particular I ordered one of their DaVinci boards which is an Arduino Duemilanove compatible board that has the standard Lynxmotion/Basic Micro forum factor. With this I also purchased an Orion shield, which has 32 IO pins with 3 pin headers. 24 of these IO pins are controlled by the H8 processor onboard. This is more or less a Arc32 on a shield… After working out a few issues, I added a first pass Orion Servo driver for the Phoenix Arduino code base and now have my CH3-R hex robot, the one built from spare parts, running on this configuration. Still lots to be done over time, like can move a lot more of the code to the Orion shield as you have a 32 bit processor that runs faster, has more memory, than the Arduino board…

I did a very quick and very dirty video showing that it works… Again still more stuff to work on, but…

Again this is a real poor video :blush: Like all of mine! :blush:

This code relies on Updating the code on the Orion and Libraries that I received from Basic Micro… But I did put my current (non Basic Micro) files up on Github

Kurt

20

Very cool indeed. I actually really like how it seems to “hesitate” which makes it more life-like.