Beside the additional two servos (ST1) I mentioned earlier I’m good to go.
Thanks! 
Thanks @dialfonzo,
I should be good to go. Unless there is some remote control you want me to try out that uses Bluetooth or XBess or…
I spend a lot of my time in the weeds like this
Thanks again
I have decided to join as well and I am going to (with my limited budget) invest in the gear. I have not ordered the brackets to keep the cost low. The servos themselves took a fair amount from my budget. I would try and print the brackets using the 3D printer. That might take a bit of time though but hoping to work with you all and contribute to this project in any way possible.
Thanks and Regards,
@madmax
3 Likes
@madmax Welcome aboard! RobotShop will be providing several of the missing “core” components including the body panels, feet and Teensy (with Kurte’s breakout). The 3D printed design will have the same layout and dimensions.
2 Likes
@dialfonzo @cbenson (@zenta @xan) and others,
I know that some have had issues with the current Servo library working with the T4.x.
If so you might try, my branch, that is associated with a currently open Pull Request I did last year:
It probably could still have other enhancements made, (Note I did update it slightly yesterday to remove code that would never execute (and another compiler warning)…
The Commit comments:
Reduce compiler warnings
This code change started off to reduce the number of compiler warnings
building with this library produced, especially when used on a non AVR
based
systems such as the Teensy. In my case a Teensy 4 and 4.1The first change was to change all of the methods that had arguments
which passed strings as: char *
This causes warnings on systems if you pass in a string, such as all of
the helper functions do.
There was simple fix to convert these parameters to: const char *There were also issues of using sscanf in the read functions, whenever
you had a conversion element like %d or %u and you did not pass
In a full size int. My first fix for this was to convert these
variables to either: int or unsigned int. But later I removed the usage
of sscanfLikewise some warnings were due to things like passing “\r” to a
function that wants only a char. Or likewise comparing a value to this
constant.
Which was easy fix.But then went a bit farther and converted the code to not use things
like sscanf, but instead simply parse the data as it came in without
having
To first read into a buffer. I also had the _s16 method simply call the
_str version and then parse the resulting string
Note: You can also simply try my branch associated with this PR:
2 Likes
I downloaded the branch and tested on my particular example. (query)
Doesn’t seems to solve it.
Note: I’m unsure of the real problem, is it lying in the library or the hardware but i think it’s more software related.
I will check some more. I should probably build a board the ones I am running on is an earlier version (actually) I did not order any of the ones you built, I had an earlier one with issue that the Teensy would not get any power from the battery and before you suggested I add the ability for discrete transistors instead of needing the sparkfun adapter.
I assume you edited the LSS_Query example to match the hardware.
That is mine starts off as:
#include <LSS.h>
// ID set to default LSS ID = 0
#define LSS_ID (1)
#define LSS_BAUD (250000)
// Create one LSS object
LSS myLSS = LSS(LSS_ID);
void setup()
{
// Initialize the LSS bus
LSS::initBus(Serial1, LSS_BAUD);
}
That is I have all of my servos running at Baud: 250000 Earlier I tried 500000 but did not find the servos reliable at that speed.
I set the ID to 1 as I renumbered all my servos.
And most important I set the initBus to Serial1 as that is pins 0 and 1 on Teensy boards. Serial is the USB port.
Different than like UNO where there is only one hardware port and pins 0 and 1 share it with the USB.
What i did is change the serial port to “Serial1” and nothing else since i’m using a default LSS at 115200 and id-0
But again, i get the “position” right but no other query. (and turning the servo by hands update the value)
Tried to isolate them one by one after even trying delays between queries.
Using the example HERE
That’s what i get, only the Position change. Everything else is at Zero:
If i’m cutting it down, for example, with only the “Temperature” here is what i get:
void loop()
{
// Header 1
Serial.println("\r\nQuerying servo…");// Get LSS position, speed, current, voltage, temperature
uint16_t temp = myLSS.getTemperature();// Header 2
Serial.println("\r\n\r\n---- LSS telemetry ----");// Display LSS position, speed, current, voltage, temperature
Serial.print("Temperature (1/10 C) = ");
Serial.println(temp);// Read LSS telemetry once per second
delay(1000);
}
1 Like
Not sure what is going on? I assume you have the servo powered up…
Do you have a logic analyzer to play with? (I don’t leave home without one )
I am running the same sketch, as I mentioned I changed the baud rate, Serial port and servo number as I don’t have a default servo (Maybe I should have one on hand)
But here is showing part of the query going on:
I have the probes setup at on a Tibia servos on the hexapod.
1 Like
@dialfonzo - When playing with this, with the hexapod, I tend to start of playing with my own sketches.
Like:
My test sketches for the LSS which includes initial port of Phoenix code.
But Just ran this one, for testing servos:
Some of the comments I see need to changed like not AX servos…
But for example in test run, It found my servos at the start:
For example is a start of a test run just now:
LSS Servo Test program
Search for all servos
1 - -316
2 - 374
3 - -532
4 - 203
5 - 591
6 - -172
7 - -730
8 - -354
9 - 31
10 - -260
11 - -21
12 - 90
13 - -137
14 - 138
15 - 57
16 - -90
17 - -91
18 - -4
Done
0 - All Servos off
1 - All Servos center
2 - Set Servo position [<Servo>] <Position> [<Time>]
3 - Set Servo Angle
4 - Get Servo Positions
5 - Find All Servos
9 - Print Servo Values
b - Baud <new baud>
t - Toggle track Servos
h - hold [<sn>]
f - free [<sn>]
r - Reboot [<sn>]
:
Cmd: 4
1:-316 866
2:374 859
3:-532 893
4:203 857
5:591 824
6:-172 878
7:-730 873
8:-354 883
9:32 810
10:-260 973
11:-21 910
12:90 886
13:-137 946
14:138 918
15:57 906
16:-90 936
17:-91 913
18:-4 971
0 - All Servos off
1 - All Servos center
2 - Set Servo position [<Servo>] <Position> [<Time>]
3 - Set Servo Angle
4 - Get Servo Positions
5 - Find All Servos
9 - Print Servo Values
b - Baud <new baud>
t - Toggle track Servos
h - hold [<sn>]
f - free [<sn>]
r - Reboot [<sn>]
:
Cmd: 9 1
Servo 1 values
Q - 1
QO - 0
QAR - 1800
QP - 1149
QD - -316
QWD - 0
QWR - 0
QS - 0
QSD - 600
QSR - 100
QLED - 0
QG - 0 failed(2)
QID - 1
QB - -12144
QFD - DIS
QMS - LSS-HS1
QN - (null) failed(2)
QF - 368
QV - 12190
QT - 401
QC - 0
QA - 0 failed(2)
QAS - 0
QAH - 2
QAA - 100
QAD - 100
QEM - 1
QLB - 0 failed(2)
Since the very first day I’ve had access to one… there’s something akin to a deep sadness inside me when I don’t have one within reasonable reach (like < 1 hour)…
Since I haven’t left home in ~13 months, that solve the issue for now… 
1 Like
I know the feeling! We have not been in any store or restaurant or … for over 13 months. Exceptions is we pick up our mail in town at our mailbox in town maybe a few times a week, usually before 6am with mask…
The other exception was we went in to a drug store 2 weeks ago for our first vaccine shot… And are scheduled in about a week for second one… Then a couple of weeks after that, we will probably start to venture out a little bit.
2 Likes
I was trying to get my Teensy 4.1 board setup with arduino IDE and the libraries installed to get started. I am using Arduino IDE 1.8.13 with the Lynxmotion_LSS library v1.3.1.
However, I am having an issue compiling the lss_querry example.
The error is
LSS_Query:22: error: no matching function for call to 'LSS::initBus(usb_serial_class&, int)'
LSS::initBus(Serial, LSS_BAUD);
^
In file included from C:\Users\PC\AppData\Local\Temp\arduino_modified_sketch_814274\LSS_Query.ino:10:0:
C:\Users\PC\Documents\Arduino\libraries\Lynxmotion_Smart_Servo_-LSS-\src/LSS.h:243:14: note: candidate: static void LSS::initBus(SoftwareSerial&, uint32_t)
static void initBus(SoftwareSerial & s, uint32_t baud);
^
C:\Users\PC\Documents\Arduino\libraries\Lynxmotion_Smart_Servo_-LSS-\src/LSS.h:243:14: note: no known conversion for argument 1 from 'usb_serial_class' to 'SoftwareSerial&'
C:\Users\PC\Documents\Arduino\libraries\Lynxmotion_Smart_Servo_-LSS-\src/LSS.h:245:14: note: candidate: static void LSS::initBus(HardwareSerial&, uint32_t)
static void initBus(HardwareSerial & s, uint32_t baud);
^
C:\Users\PC\Documents\Arduino\libraries\Lynxmotion_Smart_Servo_-LSS-\src/LSS.h:245:14: note: no known conversion for argument 1 from 'usb_serial_class' to 'HardwareSerial&'
no matching function for call to 'LSS::initBus(usb_serial_class&, int)'
Any help greatly appreciated.
I haven’t received my order yet but I thought I could at least get basic things ready.
Thanks and Regards,
@madmax
1 Like
That line needs to change to Serial1
On several Arduino AVR boards like UNO Serial is both USB and pins 0 and 1 as there is only one Hardware Serial port.
On Teensy there are several and USB is done Natively
So Serial -> USB
Serial1 is Hardware Serial on pins 0 and 1
There are actually something like 8 hardware Serial ports on the T4.1
1 Like
Hi @kurte @scharette
Thanks a lot for your help! Changing it to Serial1 does it. Is this something that should be changed upstream as well ?
There are a lot of warnings though that pop up. I will paste those later.
Thanks and Regards
@madmax
1 Like
@madmax and @scharette and …
As I mentioned yesterday on about posting 404 (not sure on how to read the posting numbers correctly.
About a year ago, I put a Pull Request to remove the warnings. As many of these warnings were real issues. Many of the difficulties were due to differences in sizes of variables and the like when going between 8 bit AVR processors like the Arduino Uno and 32 bit processors like Teensy 4.1, Again here is a link to my fork/branch associated with that Pull Request:
As for changing the Example sketches upstream. I know the difficulty with libraries like this is to handle the different platforms and this was setup originally set up for their shield and their other AVR board.
But as a minimum I would probably change things like:
#include <LSS.h>
// ID set to default LSS ID = 0
#define LSS_ID (1)
#define LSS_BAUD (250000)
// Create one LSS object
LSS myLSS = LSS(LSS_ID);
void setup()
{
// Initialize the LSS bus
LSS::initBus(Serial1, LSS_BAUD);
}
To be more like:
#include <LSS.h>
// ID set to default LSS ID = 0
#define LSS_ID (1)
#define LSS_SERIAL Serial1
#define LSS_BAUD (250000)
// Create one LSS object
LSS myLSS = LSS(LSS_ID);
void setup()
{
// Initialize the LSS bus
LSS::initBus(LSS_SERIAL , LSS_BAUD);
}
And/Or to Add a define in LSS.h: Something like: LSS_DefaultSerial
That is defined based on architecture.
For example Robotis with their Dynmaixel library Dynamixel2Arduino has in their sketches, things like:
// Please modify it to suit your hardware.
#if defined(ARDUINO_AVR_UNO) || defined(ARDUINO_AVR_MEGA2560) // When using DynamixelShield
#include <SoftwareSerial.h>
SoftwareSerial soft_serial(7, 8); // DYNAMIXELShield UART RX/TX
#define DXL_SERIAL Serial
#define DEBUG_SERIAL soft_serial
const uint8_t DXL_DIR_PIN = 2; // DYNAMIXEL Shield DIR PIN
#elif defined(ARDUINO_SAM_DUE) // When using DynamixelShield
#define DXL_SERIAL Serial
#define DEBUG_SERIAL SerialUSB
const uint8_t DXL_DIR_PIN = 2; // DYNAMIXEL Shield DIR PIN
#elif defined(ARDUINO_SAM_ZERO) // When using DynamixelShield
#define DXL_SERIAL Serial1
#define DEBUG_SERIAL SerialUSB
const uint8_t DXL_DIR_PIN = 2; // DYNAMIXEL Shield DIR PIN
#elif defined(ARDUINO_OpenCM904) // When using official ROBOTIS board with DXL circuit.
#define DXL_SERIAL Serial3 //OpenCM9.04 EXP Board's DXL port Serial. (Serial1 for the DXL port on the OpenCM 9.04 board)
#define DEBUG_SERIAL Serial
const uint8_t DXL_DIR_PIN = 22; //OpenCM9.04 EXP Board's DIR PIN. (28 for the DXL port on the OpenCM 9.04 board)
#elif defined(ARDUINO_OpenCR) // When using official ROBOTIS board with DXL circuit.
// For OpenCR, there is a DXL Power Enable pin, so you must initialize and control it.
// Reference link : https://github.com/ROBOTIS-GIT/OpenCR/blob/master/arduino/opencr_arduino/opencr/libraries/DynamixelSDK/src/dynamixel_sdk/port_handler_arduino.cpp#L78
#define DXL_SERIAL Serial3
#define DEBUG_SERIAL Serial
const uint8_t DXL_DIR_PIN = 84; // OpenCR Board's DIR PIN.
#else // Other boards when using DynamixelShield
#define DXL_SERIAL Serial1
#define DEBUG_SERIAL Serial
const uint8_t DXL_DIR_PIN = 2; // DYNAMIXEL Shield DIR PIN
#endif
Which I may tend to want to be not so in your face, but it lets you know and it automatically chooses the correct Serial ports for both what to output to Servos as well as which Serial port to use to output Debug messages.
With my beginning port of the Phoenix code I have the defines in a header file in this case Hex_Cfg.h which if I were building for multiple architectures, I would expand on more.
Hope that helps
1 Like
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.
Great ideas! 
@kurte @xan @zenta @madmax @dialfonzo @scharette
Since the team is getting to the point of creating / adapting code, it’s important to have a common / shared account:
https://github.com/lynxmotionbeta/SES-V2-Hexapod-Beta
For those not yet added, please send a private message here with your account and we’ll add you ASAP.
2 Likes
Thanks @cbenson.
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…
Probably enough questions for now 