I’d say make a folder in the repo for each contributor.
In those contributor folders, they can make new subfolders for each project they work on.
When working on a subfoler, make a new branch to keep things separate (one branch (or more, i.e.: one for each group of updates) <> one project subfolder updates).
This method/process would probably keep things clean without too much overhead.
@kurte your message are amazing. I mentioned this earlier but I am always waiting for you to reply. I know that I am always going to learn something new from it… 
and I am never disappointed.
That seems very handy.
Wow that is nice!!
Interesting information and good to know this!! Actually, I had attempted a serial PWM controller(purely software based) without using any external chip. I don’t know how but I stumbled upon an article for the original article where Michael Dvorsky wrote about the SSC in the circuit
cellar magazine March 2006 issue it was titled Low-Cost Serial Servo Controller
Nice! I did this on my hexapod. Directly talks to the servos with PWM. Software PWM based on the 16 bit timer. LSS are something else though. Really like those!
Thar is really impressive!!!
Well you could take this up a notch and have group subscriber id which can basically be the id of individual servo within a group and then you can get a group to respond to queries. That might have a use somewhere.
I do love them actually. But I am surprised you have not mentioned the LED’s. I think that was genius, whoever thought of that. Its so damn awesome… gives an extra error detection if a servo malfunctioning or behaving weird. I can easily see a code which is continuously monitoring current for each servo and blinking when it jumps high than usual. Such a treat for visual inspection. Other wise you have to hook up a bunch of leds with some and have some coded values for error detection and keep referring the code or hook it to a serial port with messages coming out… RGB LED are great addition i must say to these LSS, gives them a character as well!
That does sound good. I like that !
Thanks,
I will start off that way.
At some point assuming we start to have a reasonably functional Hexapod code base, It would be great to have a main directory, like setup, where there is hopefully building up a cohesive set of code that will work well with whatever configuration(s) that Lynxmotion is considering selling. If/when we get to that state, I personally more or less follow the stuff like:
That’s pretty strongly opinionated and I don’t get it because you like the Arduino standard. Ros2 is like what Arduino brought to the table - an easy to use and standardized build environment for a large ecosystem of freely available code components. It’s an IPC library like protobuf that works with a large library of components you can use - for free. Sure some components can be complex (it’s robotics after all), some can suck, but so can arduino ones…I wouldn’t blame Arduino. I can write nodes in a few lines of code in python or C++ and get down too nitty gritty. I don’t feel Lynxmotion needs to hire an expert.
I think both of these opinions strongly indicate the value in having multiple concurrent projects that appeal to different groups of people! 
I’m so glad we all get to share in this and enjoy these discussions! Lots of fun to be had now and in the foreseeable future! 
Also, the LSS have an advanced mode that combines the best of the smart world (serial comms) with PWM-type control!
If you set the motion controller to mode 0 (i.e.: EM0), you now have a way to control the servo that is quite different.
In some cases with high variance in torque this can give both more control on motion but also reduce stuff like jerkiness at end points and motions where torque changes dramatically (such as changing between working against vs working with gravity).
In this mode, by default, the LSS will replay a command internally when it receives it. So if your LSS is at position 0 (QD=0) and you send D900, it will internally replay D900 (kinda like when you send a PWM indicating a +90° on a RC servomotor) until it reaches that position. By default, the LSS in this mode has an exponential weighted moving average (you can read more here & here) added to the input which produces, effectively, an S-curve style motion on the cheap, allowing you to have smooth starts and stop while also moving fast in between. You may have to tweak your AS and AH value to change how stiff the motions are based on what you are doing (you should be doing this anyway for complex motions! )
Alternatively, you can turn off this “motion engine” and/or tweak the depth of the the EWMA. If I remember correctly, the motion engine playback at a rate of 1:4 with the control loop, so that would make it play at exactly 20 ms (used to be ±1-2 ms of jitter but I think the staggered scheduling of the tasks removed that completely now), just like a typical RC servomotors.
If you change the dept of the EWMA you can increase or reduce the “smoothing” effect. I recommend only using odd values for best results. If you set it to 0 you can turn it off, too. Be prepared for rough motion though if you do that! I think the default value is 5.
As for the motion engine itself, when it is turned off the LSS will not go to the sent position on the first command. Instead, you’ll have to send a new position regularly until the LSS makes it to that position. How fast you send those positions (and their relative delta) will determine how fast the servo will reach your final position. This allows for a huge amount of flexibility in motion.
In all of the EM=0 cases if you send positions faster than the running rate of the application of motion (i.e.: once per 20 ms), only the latest value will apply the next time the LSS is ready to apply a new position command to its internal control system. See the example below:
This has been discussed before many times, especially with @cmackenzie. I think the main show stopped on this front is that the TX and RX lines are set to their respective roles (on each LSS TX is a buffered output and RX is a buffered input). After those discussions, I think the conclusion was that there was no simple way for the LSS to read the status of the TX line. Therefore, this makes it really difficult to coordinate two or more LSS to coordinate responding on the bus. Timing can be used, but then you’ll need good safety margins since all LSS will have variance in clock timing & etc. The larger safeguards in timing will make this about as efficient or less than reading each individually at high speed ( with 0 risk of collision if done properly, see @cmackenzie 's work on that it is very impressive! ).
That being said, it is still not completely impossible but most likely not trivial at all… 
If only there was one extra pin to read TX output (on the buffer side). Unfortunately, reading the line status when not outputting (on the common bus) is not possible due to the buffer that prevents line contention. A tough problem with the current electronics, so to speak.
I’m sure it would have many uses. Then again, the current software solutions aren’t much different and do a decent enough job that a full humanoid can be controlled in real time (with very tight control loops)!
I think I’d point the finger at @cbenson on that one probably… though I’m not 100% sure!
Totally the goal! It also makes the button menu quick to use and very user friendly once you get use to the concepts of how it works.
They really, really do!
To be honest… I kinda forgot… haha. Also, while this is not possible with the current firmware, please note that that RGB LED in the LSS is capable of at least 8 (or was it 16?) bit resolution on each of the color components individually (hardware wise/not µC CPU bound), anyway). This means that with a proper set of commands/API and some updates to the firmware, an LSS could, in theory, display at least a few thousand different colours on that LED and even transition between them smoothly enough! For now, I guess, it has 8 colours!
Sounds like a good way to get started without having a giant mess right off the bat!
I think whatever we choose (or change to, bound to happen as the code base grows!) is looked at carefully and refactored often as needed we’ll be fine. We don’t want to get stuck in repo “design paralysis” and never commit any code for months!
For now some bare bone basics to prevent major conflicts n the shared repo should be enough!
Those are pretty sensible ideas overall! 
Maybe the root folder should have a contributor’s guide and we can write some basics stuff (like the structure we want to use) for now and slowly add things together as we figure out how we want to contribute. I’d say lets keep it simple and grow as needed! We don’t have millions of contributors yet so no need to be too strict for now! Kinda “let it grow organically” while keeping a (refactoring) eye on it! 
Sorry, most of the experience I have done and seen is with ROS. I believe Ros2 has improved things a lot over ROS. And I expect that to continue. And I will get back into it hopefully not to far in the future.
But maybe it is just me, but when I look at Robotic products, and the like, I expect that different users may have different expectations and goals and as such their tolerance for learning curves and steps it takes to have things up and running.
Example currently shipping Hexapods by Trossen: I am not sure that it will be the same user base who purchase their low end about $1100 kit versus their higher end at about $6000, yes there will be people in all of the different camps on both price points.
That is there will be percentage who purchase one of them because it looks cool and they like the idea of controlling it using something like a game controller… Then there will be those who wish to then extend beyond that and get into higher level things that for example ROS2 gives you…
I know that they expect to sell the majority of the higher end ones to research places and the like and they expect that the majority of the lower end ones will go to hobbyist and they still direct users to the Phoenix code base, which I know they were recently verifying worked with their later version… And if you look at their WidowX page they are directing you to their ROS setup.
Likewise I wonder how many customers who purchase something like an Lynxmotion Rover like: http://www.lynxmotion.com/c-118-ps2-combo-kit.aspx
Are doing so to install ROS?
Again a real question for Lynxmotion (RobotShop) who are your target audiences.
Now hopefully over time, one can set up a version of code base where it is good at both. Sort of like some of the stuff I was playing with with the Turtlebot3… That is a lot of the Rover capabilities was done internal to the firmware for the OpenCR board. So you could actually run it around like a rover without the need to start up ROS.
There was then some interesting stuff with the Ros2Arduino setup that ROS (with Robotis) where the firmware could talk to other nodes through topics and the like. The last time I played with with the Robotis XEL setup, the nodes could talk through Ethernet… Which the T4.1 can do… But at the time the demos were setup where you sort of had to have an Ethernet switch on board or the like… Again lots of great stuff…
So again sorry about being too hard on ROS2… I was trying to make a joke about pulling my lack of hair out
I love the LEDs and I use them all the time for useful state information. Such as servos that are limp vs active, black if not under control and force feedback as well…oh so useful!
The EM0 mode is really nice that @scharette is talking about, especially when also used with the angular stiffness (rigidity) parameters and the Maximum Motor Duty. I highly recommend this mode if you are sending commands in a control loop
No worries, it’s good to have variety, no question, and I really look forward to seeing what you guys come up with. I dont want other people reading the thread to think Ros2 is hard though. It’s a complete rewrite from top to bottom and shares nothing but the first 3 letters…so ROS2 != ROS1. It sucks the whole ecosystem of modules have to be rewritten but it’s that different. I have a strong opinion against Ros1 too so…and wait, don’t you do your own Jacobians over there? You’re massively over-qualified for Ros2 lol…I’m still struggling with some of the math. I don’t need to but I still want to learn how it works under the hood and it fascinates me.
I’d be happy to put a Ros2 front-end on whatever you guys come up with so it opens up a world of sensors and vision, etc. There are no restrictions on your code to do so. If I can read joint angle state and send you speed/orientation/tilt, or what not then I can get it done. Just like adding a Rest API to a website.
Those LEDs are also super useful also for stuff like scanning the bus and identifying stuff (ex: LSS Config).
You are right, it is pretty sweet!
I’ll have to throw you more flowers too now! @cmackenzie
Also there are some nice functions to limit duty cycle in both direction (symmetrical and asymmetrical) that you can play with, too. @cmackenzie Can probably tell all of us more about how he uses those. Certainly something fun to play with!
I guess I need to see how to use that. seems quite useful. More learning… more fun!!
Thanks for all the information on this!!
I’ve answered so many questions on here about this stuff I think I’m going to just collect all of my answers about it and write a FAQ (blog post? pinned forum post? both? 
) or something!
The way I see it, when you have (specialized/not common) knowledge you have a fundamental responsibility to the rest of society in most situations to either:
)This is in part why I like all of you over here very much! Lets all make DIY/educational robotics better together! 
@bdaouas @cmackenzie @cbenson @dialfonzo @dickel @geraldinebc15 @kurte @madmax @tobar8th @xan @zenta (and many more… haha! can’t list everyone here or I think I’d hit the post size limit!)
I agree … In fact I forgot to mention this in my earlier post. I was going to ask whether this should go as a page on the wiki so it becomes a central place for everyone to refer to as they will refer the wiki first anyways.
Agreed!
Who gets to write the 500th post… oops sorry it was me… !! 
Hahaha! What a non-achievement!!!*** 
I have claimed the 512th post!
And the 64th!
It seems my power of 2 game is strong!
***: just to be 100% clear, this is ~totally~ meant as a joke!
hahah! @scharette Don’t worry I don’t get offended that easily
On the topic of controllers following seems quite cool and very useful…
Please have a look if you haven’t played with this, looks useful. Basically, it has a graphical editor online and it generates you a source code. The GUI is stored in the Arduino sketch. What happens next is you take a HC-05 Bluetooth module and connect it to your Arduino on a serial port (hardware or software ). It supports both and has few configuration options which allows you to use wifi as well. You get their app and install it on your phone. The GUI then gets uploaded over BT which is in your sketch and you can use your phone to control your BOT.
This seems fantastic. If you want an extra joystick, extra slider just edit your design online… Download the source. Integrate your code and you are ready to go.
I am trying this out now. Not sure what I would try this out on… May be a single servo would do for now…
I’ve learned the hard way a long time ago… it is better to be overly clear than not! Especially online… hahaha!
@kurte - Many thanks for the work on the Lynxmotion LSS Library and sorry for not having taken care of your PR before. Yesterday i merged and released, it is now available as 1.4.0 in Arduino IDE.
