I don’t think pasting the warnings will really do much. As @kurte said, this has already been looked at. There are so many Arduino platforms that I’m not surprised no one tried that one at the time. Actually, I think the Teensy 4.1 didn’t even exist when the library was released
Those are some good ideas. I think I’d go with a proper default in the library header for different platforms and then also add a undef/redef (that is commented by default) in the examples to allow easy access to changing it, too.
This would most certainly be a good improvement on that front.
I feel like that is probably the main pain point of this library: it never really was tested on 32-bit platforms at all.
To be fair though, it does not specify any support for 32-bit platforms explicitly!
Maybe you should separate the pull request into some smaller, more specific groups of corrections (as-is it is something like 1150 lines of changes total, a bit much for non-software people to review). I did notice it include more than just the warning in the PR so that could be placed separately, too.
Question, how do you prefer these github beta projects to work? And what types of things would you like to see up here?
Sorry I know that some of these questions may have obvious answers, but I will ask anyway, things like:
Mechanics:
Should each of us typically all work out of the same fork? Or should we instead fork it, work on a new feature or fix. I typically create a new branch for this, when happy then do Pull Request back to the main one?
If we go with Pull Requests, should we all just do the merge our self into the main/master or if we are changing others code should we ask them to do the merge? Or do you have a Software Wizard there in some cases that you would to review the changes?
Do you have/want more than one standard branch: For example with Robotis stuff, often they have the master/main branch for the latest working version, and then they have/had another branch, like Working in their case Develop where all of the new stuff went.
My guess answers are: To fork the code: Push up our own changes and for most things merge in our own stuff. If however we are significantly changing some existing code, either at least give a heads up or ask the other review and merge.
What:
If we are fixing/enhancing existing libraries like: your servo library, should these fixes/enhances, be submitted as Pull Requests to the main library, like: LSS_Library_Arduino? Again I running off of my own branch of this which removed the compiler warnings. Some of which were probably breaking the functionality on 32 bit platforms. PR - Issued last May.
Or should we for example: add the code from that library into this new github project, that hopefully at some point you will release back to the main github project?
Test Sketches - I have some of my bits and pieces I use at times, for my own testing up at:
Things like a simple Servo test program:
Which has been adapted through several different servos and processors… Looks like my comments need to change…
Or specific purpose one, that simply changed the baud rate of all of the servos:
And a couple versions of the Phoenix Hexapod code (still using fixed code math), that one that I had limping along using Trossen Robotics Commander for input.
Another one I was working on, was a USB Host one which will use PS3 and/or PS4 controllers… Note I am more likely to work on this version as everyone should be able to easily get these types of controllers… Arbotix Commanders are probably no longer made and rather limited. More on this later if interested…
But the question will be, what should go up on this github? Note: These two versions of Phoenix stuff, still more or less work off a similar organization to the old Phoenix code that @xan started long ago. Where there is main code, Class for Servo driver, and class for input device…
For a long time, I was set up to do this with one github project:
Note: all or at least most of the code was in header files, as to allow you to use configuration data, which Arduino makes difficult with libraries. So for example these two sketches were setup by copy of the library files, but I renamed each of the headers (to start with a _ in file name…) Makes it easier for those working in Arduino IDE or the like to see all of the code. Again more if people are interested…
Side note: Most of the times these days, I do most of my editing and building using Sublime Text (in my case version 4). I often setup project files, so I can see the sources of the different libraries I wish to see… A few of us have also setup some batch scripts and the like for sublimetext, that allow us to configure a build for a specific Teensy, what speed, what USB device… and it saves a file in that folder, that then within sublimetext you do the build command and this script uses the Arduino build to do the actual build. If there are any errors or warning, it tries to show you in the text (hitting F4 goes to next one…). We then have it setup with a different Terminal program (TyCommander) which has some nice features over the Arduino Serial Monitor… Again more if interested…
That is some long post! …But quite informative. Sorry I am new to this (Not github ) but this project. I do like a few ideas that you have thrown in
Branches for different features while having the main master branch always working and in good shape with features being merged to master
The LSS Library code can be copied here because it is good that the libraries etc. that we need, the source of that is in the same folder(git hub repo in this case). The upstream Arduino library can always be merged with the changes from here. I guess having the library changes available for us quickly in the same place is better than having to wait for the Arduino library to be updated.
There are can be further directories for the electronics i.e. schematics / PCBs developed for this projects. Any 3d models which are open source.
If there is a ROS integration then there can be folder for all the ROS related contents.
I guess I am thinking that anything related to this hexapod should be in one place and not too many projects lying all over.
So may be I am thinking something like
lynxmotionbeta/SES-V2-Hexapod-Beta --> Main directory
|
|–Electronics
|–ROS
|–Teensy
|–Something else
@kurte Not obvious at all actually and questions and feedback are always welcome.
@xan@zenta Any preferences? We can keep this first repo Teensy-specific if you all prefer.
The Lynxmotion BETA GitHub differs from the Lynxmotion (public) GitHub in that BETA developers are invited and given specific access. Once the hexapod project is finished, the completed code would be placed on the regular Lynxmotion GitHub page and linked to from the Wiki. The BETA will still be around for continued development beyond the official release of the platform.
First and foremost, let’s get the robot walking. Migrating the Phoenix code seems like a great start, though the Teensy seems powerful enough to able to work with the equations rather than predetermined coordinates, which would likely help significantly with terrain adaptation (and cliff detection?) using the current sensors.
Colin has been “chained” to the humanoid until it’s up and running but is really eager to get started on the Hexapod and ROS 2.0, so a separate repo can be created for that once people are ready to start.
The original Phoenix code was written for an atom basic which was way more limited. The Phoenix code already has onboard calculation but they are fixed point instead of floating point. With the Teensy we could switch to floating point (or any other value time which allows decimals.)
Teensy/Arduino also allows OO-coding, this also allows us to create a way better architecture then we could with the old tools. I think this should be a good place to start and re-design the architecture to the latest standards.
Collaboration
I always think it is good to have something in place which makes collaboration easier. Kurt already shared his thoughts about branching/merging/(buildable) check-ins which is very good to agree upon.
When we all going to work in the same source we should also agree/align on topics as IDE (I’m using VS Code with PlatformIO), product owner, software architecture, hardware variations, functions, etc.
I need to confess that I am a bit skeptical about having one shared solution. Multiple people will have own way of work and architecture. Without having an overall design, structure and product owner, I’m not sure if this will work.
I was thinking of developing modules in my own Git and making them public once they are stable. But maybe I’m just too skeptical and just need to see how if this will work or not.
Edit: Maybe we could define modules to be made and create an owner of each module… Just thinking out loud…
I think that is a great idea and that resonates with my thinking as well
Yes … completely agree… I Love VS Code so no issues there.
I was thinking about this as well while reading your post… This makes perfect sense but is quite tricky as to who will do what but I did agree in all honesty. We just have to make sure people are not blocked for longer periods.
Some thought
However, before we dive into the writing the software bit should we not have the kinematics and the mechanics of this robot sorted in equations and theory I mean. I am not so well aware with the Phoenix code and its axis orientation but should we not get the basics sorted. May be have all the joints etc. annotated with Denavit Hartenberg kinematic notations and other such equations ready (written down with some diagrams somewhere) ?
I don’t know whether this is already done so apologies if I am stating the obvious. Does Phoenix code already follow this ? I have in the past looked at the Phoenix code and tried to understand the axis orientations from the Excel sheet but I was confused and came up with my own.
The key for other people to also pick this up is to have good documentation in place. I think the theory matters as much as the practical.
Exciting! Everyone participating here has been added to the BETA GitHub. This is a group project with really skilled people - there will be different perspectives and opinions, but at least for the MVP we can try to go with a consensus vote which will include programmers and non-programmers. Once the points in the MVP have been accomplished, anyone is welcome to create branches and follow their original ideas which the group may not have chosen to pursue.
With the Teensy we could switch to floating point (or any other value time which allows decimals.)
PJRC seems to do well in maintaining and producing previous generation boards, but there’s a good chance the next iteration (Teensy 5.0?) might not be pin compatible with the 4.0. Just a consideration since when Basic Micro stopped producing their Basic Atoms, a fairly big changeover to Arduino was needed, which in this case would require slightly updating (and testing) the code.
When we all going to work in the same source we should also agree/align on topics as IDE (I’m using VS Code with PlatformIO) {…}
There are two main types of customer for this type of platform: one who sees it as an advanced toy and is happy to use sample code to remotely control it, and the other more of a “researcher” (can be a hobbyist or enthusiast too) who wants to delve deeper and customize it. This second customer might choose instead to buy only the servos and develop a similar robot using them, and hope the sample code will work with their choice of MCU, which can be Arduino-compatible.
As such, is there a chance that moving away from the Arduino IDE might have the effect of this second type of customer second guessing if they have the skills and knowledge to work with the platform (i.e. “fear of the unknown”)? It seems preferable that the final result be Arduino IDE compatible and explained as such.
{…} product owner, software architecture, hardware variations, functions, etc. {…} Without having an overall design, structure and product owner, I’m not sure if this will work. I was thinking of developing modules in my own Git and making them public once they are stable.
Agreed that restricting individuals from pursuing ideas and interests might impact their motivation, but we need to keep in mind the objective is to release code which is easy to understand, well documented and versatile.
The following seem to be good objectives for a “Minimum Viable Product” (MVP). Are there any others worth including?
Optimization & modernization of the walking algorithm (ex. floating point math)
Validation of the hardware / mechanical design
Terrain adaptation using current sensing
Controller input selection
Documentation (within the code specifically as RobotShop staff will add documentation on the Wiki)
The approach to each point can be broken down and discussed, like for the first point:
A) Redesign of the architecture (& which standards?)
B) Using Object-Oriented Programming?
C) Choice of IDE
D) Use of modules
E) …
Our CEO would love to see just how fast this robot can walk.
Note: Yes the current Phoenix Arduino code is still using fixed point math. I have/had a version that was converted to floating point. But there were areas of code that was not working with it. At one point I believe @zenta had/has a version that uses floating point. I believe he then redid the ideas of walking gaits and the like… Which I think would be a nice starting point if he is happy with it and wanting to share it.
As for For Object Orientated and latest standards that could be almost anything. The Phoenix code I am talking about that is up in github is setup using classes. Things like:
class InputController {
public:
virtual void Init(void);
virtual void ControlInput(void);
virtual void AllowControllerInterrupts(boolean fAllow);
#ifdef OPT_TERMINAL_MONITOR_IC // Allow Input controller to define stuff as well
void ShowTerminalCommandList(void);
boolean ProcessTerminalCommand(byte *psz, byte bLen);
#endif
private:
}
And there are different implementations for this class, ones like PS2, or Arbotix Commander with XBee…
There is also a class defined for ServoDriver, which I did not make all of these implementations using virtual functions, which at times I thought about going back and doing so. Potentially making these pure virtual classes.
This is not to say that this code base has not become convoluted and parts rethought and functionality be refactored. I am all for someone taking this up, including doing it all fresh.
As for Standards, this is a real tricky one. Some people believe that all code like this should be written using C++ STL. Personally I totally shy away from this on Microcontrollers. Others believe that on Microcontrollers, one should never use malloc or New, that everything should be statically defined. I am not in either of these camps.
I am an old dog who tends to avoid new tricks That is I tend to shy away from newer C++ links like templates and Lambda functions…
As for Architecture for this I see at least two main Software setups that over time I believe RobotShop may want to embrace:
a) Arduino setup - which mortals can understand - Like a new version of the Phoenix like code base…
b) Higher level like ROS2 - Which I personally believe is beyond the majority of hobbyist, but is a great stepping stone toward higher end things like, Autonomous, Vision, …
At this point I am thinking a) at least to start off with.
I believe b) in many cases may require having a ROS export employed or a real dedicated hobbyist who still has more hair to pull out than I have left
For me, I sort of believe in the Arduino Standard. That is all of the code should be able to be built using Arduino IDE. That is not to say that I believe everyone should use the Arduino IDE Editor to write the code. I do from time to to time, but most of the time I do most all of my editing in SublimeText. I also have it setup to be able to invoke the same stuff as the Arduino IDE, so it removes any compatibility issues. There are several ways that I know of that people using Teensy build their code:
Some of them are mentioned up on an unofficial Teensy Wiki:
But again will work along with the different members.
No Idea what a Teensy 5 will be. There will be another T4.x based on IMXRT1170 which is dual core…
However I most likely wont be in the same foot pattern as current Teensy boards, as chip is bigger plus there is lots of discussions on how to make more of the pins on this chip available… No idea of when this will come out.
It shouldn’t be difficult to convert the maths to floating point, right ? I guess that would a be a very good start. Here is a video for my hex.
On that one I am using AVR ATMEGA32(No arduino). It also implements a software based Pwm to control all the 18 servos. There is no servo control board. I use float for all the lengths, IK calculations etc. The is no control loop there possibly would add it using another timer but there is no sensing etc. on that. It is a dumb walker.
I have no problems with OOP but I am not sure if OOP is embraced by all. What do the majority of people (customers ) use ? I am a firmware engineer so it is mostly C for me. I may be completely wrong on this.
BTW I got my first shipment of the servos and the LSS adapter board !! Excited!!!
Yep should not be that much of an issue, to convert. As I mentioned I did that several years ago, just never went through and debugged it…
@xan and/or @zenta and/or @madmax, if one of you would like to take the lead on this on the software it would be great! These days I am more interested in the nuts and bolts and trying to facilitate things, and would enjoy helping out where I can.
Not sure if any of this will be interesting or not:
But thought I would maybe, mention a few things about what I have sort of limping along:
I was only part way through trying to map buttons and the like: It is also setup to slightly use my one version of the T4.1 board that also has a socket for an Adafruit ST7735 or in this case ST7789 display.
The code is setup, that when a controller is not connected and active (hitting PS button on PS3), it cycles through all of the servos setting different colors on the LEDs. I did that for fun and also reminds me that power is still on as I killed several batteries in past:
Note: the legs do move, and the like, I have it on startup to move slowly to starting position and the likewise when you hit the PS button again to put it into idle mode.
But again if one of you wish to completely redo everything that is great!
@xan - you asked about coordinates and the like. It still is in the same ones as your earlier code. Another option would be to convert everything to the ROS modal. There are more details about this up on ROS including(https://www.ros.org/reps/rep-0103.html)
A lot of the code I have seen work in quaternion and radians…
Just finished reading through all latest posts to get updated, so I’m not going to quote to much.
When it comes to Github I’m still a noob. My coding skills are limited compared to @kurte and @xan.
I’m using Visual Studio 2019 IDE with VisualMicro.
I agree we should agree on the basics. Like standard Cartesian axes XYZ, instead of XZY… We did talk about this many years ago but never ended up changing it. @Xan, what are you thinking or what are your plans about the code? Totally new structure I guess. How much of the Phoenix core do you plan to use?
I’m still using mostly of the formulas and float math. But I’ve written my own gait algorithm, still inside the phoenix main file. And it looks messy. A much better structure would be nice.
Yes, I can share it. Not willing to post it global since it look messy and require some explanations and I don’t want to spend time on support if random people start using it.
Still full of bugs, what can we expect its a code for bugs… Any suggestion where I best can post it?
I’ll try to explain the basics of function:
The gait algorithm is based on using the balance mode to make the hexapod move. Only during the swing phase the leg are controlled by the gait algorithm. The moving legs (the legs on the ground) are coordinated by the calculations from the balance mode, which again are affected of the legs in swing phase.
Main rule for the gait algorithm: No neighbour legs can be lifted at the same time, ex: (LF and RF, or LF and LM).
Also the gait pattern are defined using gait phases instead of fixed number of steps, so it constantly calculate and estimate a variable called ESSP (Estimated Steps in Swing Phase). The number of steps can vary a lot (from min 60 to probably 1000), the main loop run at around 100Hz. So the estimated number of steps changes depending on leg lift height, speed and during terrain walking. Overall there is a gait phase counter (0 - 59) that keep track of the overall gait phase.
This probably look familiar:
Btw, how is the appropriate way to post snippets of code?
So when moving from one gait phase to another the algorithm makes the transition seamless by simply following the main rule. In addition to prevent extreme cases I’m using some simple routines that avoid the legs to crash into each other (AntiLegColision) and also keep track of position limits mainly checking if the IK solution is valid, I think Xan already made that but we didn’t use it. Very convenient if the leg tries to step outside a steep cliff or a hole, it simply lifts the leg up and tries again.
I recently posted a video demonstrating different gait patterns and smooth transistions.
Like I said there are still some issues and bugs, especially when it comes to terrain walking.
I figure this could be placed in the (closed/invite only) beta repo (maybe in a folder? depends what structure is used) so that it is not “in the wild” just yet
I hope you don’t mind I added the tags to your post. just precede it with [ code] and follow the block by [/ code] (without the extra space, of course! )
That’s pretty cool. I wonder how much the current sensing and modifiers to motion like CL & CH may be helpful here for cases where it happens anyway (or with the environment).
That’s definitely a good idea!
I guess this is where leveraging better hardware (like the T4.1 has) can allow us some leeway on trading efficiency (just a bit ) for a clearer code/algorithm structure (and hopefully simpler to follow/maintain/etc.) for this new Phoenix-based implementation.
Thanks for this explanation. I’ve never really thought about it all that much before. This is quite helpful!
Thanks for your feedback.
I’ll need to figure out how or where to post the code there, do I just upload the code? Would be useful to have a folder of some sort.
Any tip?
If you use Windows I can recommend github desktop. It is quite easy to use and you can access repositories and upload code etc. If you use Linux then normal command line is perfect(I use this). I have used github desktop in the past and it makes it very easy. No need to remember any git magic
Why not create a folder called as zenta_magic and put your code in there ?
That is I tend to shy away from newer C++ links like templates and Lambda functions…
