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.
Sorry I thought I responded earlier to this, but probably started message and forgot to send
Again hope everyone is doing well and having some fun (and staying safe)
For now I sort of lost steam and put all of this stuff on hold.
Was curious about the follow on to LSS and your new smart servos. The EM=1 stuff looked interesting as it feels very much like a follow on to the old LSS stuff and the SSC-32.
As mentioned could probably get things to work with EM=1 and have host do the interpolation.
Glad you are coming up with a ROS2 solution. Will continue to follow on to see your progress.
Some reason I have difficulties with the idea that there are no messages which become corrupted when using EM=0 when run at 50hz for days, but I was seeing a significant number of them with EM=1 at low number of messages per seconds (like only a few). But weirder things have happened.
Again it is all going well, and I have continued to monitor this thread.
Again hope everyone is doing well and having some fun (and staying safe)
You too of course! Fingers crossed that the healthcare system will return to something more ānormalā and Omicron will be less virulent so we can return to something more ānormalā.
The EM=1 stuff looked interesting as it feels very much like a follow on to the old LSS stuff and the SSC-32.
Indeed, though the firmware team has been on other priority projects. Hopefully everyoneās servos have been updated to the latest experimental firmware via the LSS Config interface.
When it comes to EM1, weāll need to review how customers expect it to behave (especially if many signals are being received before it reaches the first position which it received).
Colin has been sending videos to update us privately but hope heāll share more of his progress here.