I just subscribed! I am really enjoying your channel so far! If you don't mind me asking, what are the three small copper looking rectangular blocks next to the ferrite beads on the board?
Very stable control! You are using your pi3hat, which does not have a magnetometer, right? Is it sufficient for the yaw calculation to use the gyro value of the Z axis or have you also installed a magnetometer and fused the sensors?
First change the `id.id` configuration for each servo using tview. Following the procedure here: github.com/mjbots/moteus/blob/main/docs/reference.md#idid you first change it, then immediately restart tview with the new id in order to issue the `conf write`. Note, this must be done with a CAN-FD interface that is compatible with tview, just like for calibration. Then, in your Arduino script, just assign unique IDs to each of the devices like in the BasicControl example: github.com/mjbots/moteus-arduino/blob/121db53dd9ff38d493652082b6ad0dd8edc963aa/examples/BasicControl/BasicControl.ino#L33
When you command motion or run the GUI? "terrible" audible noise is likely a result of inappropriate PID tuning. devkits should come decently well tuned out of the box. Are you using a devkit or some other motor?
@@awesjosh devkit! maybe 'terrible' is pretty subjective, I ended up recording it ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-HQof8PDN030.html, does this seem normal? maybe a bit hard to tell. Anyhow, I am using the stop function so I can work without being irritated, but I hope I'm not running this thing at too high of voltage and increasing the chances of a problem.
That seems like a normal volume level for the tuning that comes with devkits by default. What voltage are you operating at? There are several knobs you can use to decrease audible noise. 1. lower the `servo.pid_position.kd` gain 2. calibrate with a lower bandwidth 3. set a non-zero `servo.velocity_threshold` While I'm happy to support here, YT comments are relatively high latency. If you would like quicker turn around, hop into the mjbots Discord: discord.gg/W4hUpBb
@@awesjosh ok glad to hear it sounds about right. I haven't touched the default voltage or calibration values. I'm considering this issue closed, thanks for your help!
I largely only work in 6061. There, 0.005" is pretty easy. Tighter is possible, but requires patience and sometimes creativity. I've done plenty of features that are toleranced to 0.001", but you can't do that with every possible feature.
This is great, do you also have a list of motor recommendations for your controllers, like for example for a linear system. I will make a purchasing decision for my department in the company but I realise its so hard to find a supplier that recommends example applications and motors
moteus only supports rotating PMSM motors. It supports a wide range of them that have compatible current limits and voltage limits, so there is not a recommended motor list. If you would like some help seeing if something would work, you can email info@mjbots.com, or join the mjbots Discord and ask in the #moteus channel: discord.gg/W4hUpBb
You may be able to use the CAN-FD controller built in to the teensy, but it still requires an external transceiver as the system in the teensy only operates at logic levels. Also, the moteus Arduino library will only work currently with the MCP2517FD and you would have to modify it to work with the teensy's built in controller.
I like the arbor press been used while the entire 3D printed part flex :P This is truly some impressive work! I would rather do a PCB re-spin with added test point and not mess with this mechanism with side actuation. yeah I don't know why can't you use "cup" pogo pin for the XT30 and use the 3 small pads for the CAN next to J2?!?
One observed failure mode is the CAN PH3 connector having one or more pins not soldered. You could imagine switching to a vertical PH3 connector, however part of the advantage of this specific board is the low profile when assembled.
@@awesjosh good point! that is a failure you hope the fab house would detect for you 😅 but that seems like a other fun project to create a visual inspection with the pi and chatgpt vision API!?!
Hey, I currently only know about arduino and am able to do control motors, relays, pair with bluetooth, work with sensors, motor drivers, servos and all that stuff. I've made a few helpful projects using it like 'smart' wheelchair and agriculture robot. But that's about it. All of them I've coded myself. I came across videos of James Bruton, your channel and many more. I was wondering, how can I get on that level where I can make my own 3d models on some 3d software, all that kinematics stuff. How do I develop the mechanics for it? Code for the balancing of Bipedal or Quadrupled robots. How do I use Computer Vision to control robots? I searched youtube for it but must of the videos are too small to explain the code and the structure. By that I mean, the logic and the thought process behind it. There is just the 3d files and the code. That wouldn't be innovating from a learner's perspective I think. There must be online courses I enroll do to achieve this. What are those? I couldn't understand which kind of course would be suitable for me. Please guide me.
I don't have much to offer you on that front. For robotics, I was largely self taught, and just kept grabbing projects that were a little bit harder than what I had done before.
An excellent design/build. Appreciate you taking time to explain your thought process and detail the build. Looking forward to seeing how it evolves as you learn and experiment. That hoverbot has a fun factor, I'd expect you probably already have ideas as to future mods.
Unfortunately, I'm not really set up to give that kind of tutorial. If you google for "how to measure current with an oscilloscope", you can find many resources, including this article from tektronix: www.tek.com/en/blog/how-can-an-oscilloscope-measure-current
I believe if you change the walking pattern to trottle it could achieve greater speeds! However i can't stress enough how impressive is this work. Lovin it!
I have to disagree with putting solder in the cup before putting the wire in. This makes it so that if the solder in the cup ever hardens, it makes it nearly impossible to put the wire fully in the cup after that.
@@awesjosh I end up building something like that into almost every board I make, so it makes a lot of sense to have that as a stand-alone unit 🙂 Those who haven't struggled with power management might wonder why they'd need to spend money on a glorified power switch; I think it's up to us who have stubbed our toes to explain why ...
moteus uses a pll filter on the hall effect sensors for commutation purposes, and that is the reported velocity that was used for the outer velocity control loop. The bandwidth of that filter was somewhere between 50-100Hz, so it doesn't do much at low speed with the coarse resolution of the hall encoders.
Thank you! I do similar project and for now use the similar control approach but with some differences ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-LMvEsF9Y2AY.htmlsi=PAa4gED8A2Uu-Ezu In the future I'm going to ustilize mpc for increasing the stability and the robot's speed
Cool! Thanks for sharing! As you can see from my video, you don't need to go to MPC to get significantly improved results. Probably the easiest ways to improve your system would be to see if the structure of your control laws can be improved (or perhaps copy the ones here), and the second would be to ensure your attitude and attitude rate solution are operating well and with a sufficiently high bandwidth. It could also be that your tuning is just sub-optimal. Are you using integrative terms anywhere (you probably shouldn't)?
Thank you for recommendations! Yes, I use integrative terms both in attitude loop and in velocity control loop. I have some suspicious about imu. It outputs data only with 100hz. Probably if I replace IMU to better one, the whole system will be more stable.
I'm not sure an integrative term for attitude is useful, certainly this robot does not use one. A feedforward term is probably a lot more valuable there if a plain PD is insufficient. While a 100Hz IMU update rate is borderline feasible, there are lots of things that could potentially make it problematic. That could be if you are just using pitch and not pitch rate, or if the IMU has a software configured low-pass filter, or if it is poorly mounted, or a host of other things. This robot uses a 400Hz update IMU for instance with a 200Hz onboard filter, uses the pitch rate in addition to the pitch, and is known to work well at up to that rate.
Thanks for another interesting project! Question: can the pi3hat be used with a raspberry pi 5? Wouldn't think there would be a problem - but would like to check.
Nice to hear from you Karl! This was one of those projects where making the video and explaining it was 4x the work of actually building the thing, so it is great to see it appreciated!
in the example at the end 1.5 was a fault because the range was set to -1 to 1. however after you power down completely, will it still remember that it was at fault? while its on its recording how much the position has changed and knows the position went beyon the bounds. but will it still be at fault after cycling the power?
Faults are cleared by sending a stop command, in tview that would be: d stop Power cycling will also work, but with the devkit you will need to remove power from the PSU for some time before it discharges completely. Also, don't hesitate to join and ask questions in the mjbots Discord, it is a lot easier to get support there than in youtube comments! discord.gg/W4hUpBb
Thanks! Not much other info or video yet, but @mjbotsrs on x/twitter does have a video with a few new cuts. The control is just an inner pitch PID loop using the pi3hat ARS, and then an outer PID loop that controls velocity through selecting pitch.
Very cool! Impressive specs. I love that we all use XT30 connectors! The only thing it misses is an Ethernet connection. Absolutely phenomenal that it's all open source!
Yeah, standard ethernet connectors are very large for many of the applications moteus is used in, besides that since the micro mjbots has standardized on doesn't have an ethernet controller it would require either an external controller or a switch to a different micro. ethersweep is looking cool, keep up the good work! If you ever need performance beyond what steppers can provide, moteus is there for you!
Do you offer brushless out runner drivers for smaller diameter pancake motors? Like a 1803 motor? Would love to drive small robot parts (like in animatronics) in place of noisy traditional servos.
