The new group command is working awesome! I can push the limit to 100Hz control loop with 18 servos!! I am querying position, current (amps) and velocity (PCV), and then sending position. On the humanoid I had to split the 18 servos across 3 separate buses just to get near 30Hz so big improvement!
Here is a logic capture zoomed out with ~11 loop iterations. I am using group command and SLOT timing. The top blue is the PCV query, each red block is all 18 servos responding in sequence.
Here is a zoomed in view of one loop iteration. You can see one blue block which is requesting PCV using #254QD0QC0QS and then another command afterwards setting each servo to Limp (but could be a target position). You then see each servo responding in the red blocks below in their respective slot.
I’m not getting any errors event at 100Hz but I’ve since backed down to 50Hz just because I dont need that high an update rate. I rewrote the Ros2 controls plugin which is why this took so long. Since the servos are doing all the work of timing replies all the complexity of my LSS library is gone (trying to get fast updates) so my cpu usage on the ros2 controls plugin dropped from about 40% down to 1%. Now I just set a 50 or 100Hz timer in software, each tick I send the broadcast and action and read the serial buffers for the previous reply results.
This is on a new firmware release with a fix that was causing some servos to reply to late but it seems stable now.
I’m updating some of my other Ros nodes so hoping to have some actual video to show this week.
That seems to be great news! Really appreciate the thorough testing! We’ve been trying to replicate on our end and suspect that the older generation servos may be causing our issue.
I have the robot moving through direct manipulation of the limbs and base in RViz2, and I have it working with trajectories as well. So I am working in python now to compute walking algorithms and send them to the robot like Trajectory Builder does in this video.
@cmackenzie Excellent to see an update here! Guessing you’ve already informed @madmax ? If not…
Very nice model - looks like the real thing, and don’t see any / much lag between the virtual model and the real robot.
So as you said at the end of the video… on to the walking?
Fantastic!! That is amazing… super cool ! I have the c code for walking @cmackenzie that I had used on mine. I am very much tempted to see if that can be ported. I will message you regarding this. I think we should have a catch up soon.
@kurte - Ok i know what i did wrong that that time. Last Friday i had another modification to do and update on Arduino library manager. Seems like the last time i didn’t updated the tag inside the library so it was not picked up.
Happy Holidays & New Year! @cmackenzie has been advancing with ROS 2 and has/will involve @madmax. The latest firmware update (under Experimental) seems to be working well. Hopefully video updates will be posted soon.
There was a previous idea about using a PS4, which offers additional input (four left and four right buttons), and instead of a three position switch on each side, there are two way switches. A PS5 controller seems very similar to a PS4.
Colin did additional testing with the latest experimental firmware and found no errors. It may be best to proceed using EM0 for the moment while our developers explore improving EM1. Colin can explain what he’s doing more.
Are you using any of the timed moves and the like or are you sending out servo packets as fast as possible?
I am not using EM1 at all. I really like how EM0 mode works and I can get the higher level controllers in ros2_controls to plan motion more wholly and since my end goal is robot compliance I need the EM1 motion control disabled. My current control loop is 18 servos at 50Hz and 1Mbps serial and setting position and effort, and reading position, velocity and current (effort). I’ve run it for weeks 24/7 and I don’t see any errors. I’ve run the loop up to 100Hz and verified in the Saleae that it’s good. I moved back to 50Hz because I had other bottlenecks in my ros2 code making 100Hz useless…but even those are gone now so buckle up Ms. Daisy! This is a far cry from the previous per-servo request/response but it does mean constraints on how the multi-servo requests are sent.
Maybe give EM0 a try. You might even be able to get extra smoothness by doing your own motion. My motion is smooth atm. Orocos KDL (C++ lib) does all the IK, and most of the motion planning for me.
Great to hear @cbenson! I was thinking I’d need to make one myself. Here is what I already had compiled for my wish list.
Based on Compute Module 4 (to keep the it small and light but I also think it depends on availability of Computer Modules now)
powerful enough switching regulator to power the Rpi from a 12v battery
Lipo Battery charging circuit
Teensy-like ARM32 (probably just a header mount)
Fan PWM for RPi chipset
RPi power button (momentary)
RPi doesnt have a clean way to shut down…so if a hard-break power switch or pulling the battery will only lead to corruption of SD card fast
Small 0.96" OLED or so (bootup status, robot state, etc)
…and last but not least…a low-cost CPLD based device for signal routing! This would be used to provide logic-level switching between 3v and 5v but primarily be to interface peripherals between the RPI (or teensy), especially the LSS ports. So like the LSS Adapter board it would have about 6 LSS ports but they are not connected together. Instead each of the LSS ports goes to the CPLD. The 4 serial ports of the RPi4 would also go to the CPLD, as would the Teensy. Now the RPi can set a register on the CPLD to determine where each LSS port is connected, you can connect all LSS ports into a single serial port, or connect some LSS ports to dedicated serial ports on the RPI or the Teensy instead. It could also route a dedicated RPi serial to a single LSS port for non-LSS stuff like a serial GPS.
The XC9572 CPLD is one I’ve used a number of times, it’s cheap at about $1.70 in quantity and easy to program. I feel like there is probably cheaper and more recent CPLDs out there though. FPGA could work too, but I feel this feature is more suited to simpler CPLDs than a FPGA. I can help here to create the Verilog code to program the device and write the linux driver to configure the routing.
)
