Since I started using the 'servo' function in my buwizz 3.0 pro with PU L motors, there were some issues that became more and more problematic as time progressed. These are the issues:

When calibrating, after getting readings for both sides, I lands off center.

When I enter the 'drive' mode, it sometimes steers on it's own and doesn't return to center. This can also happen In the middle of a drive, as if the center was shifted as far to one side as possible.

Doesn't fully return to center. When I release the steering, on one side it works normally and on the other it only does half the way to the center. 

In this topic I'm looking for similar occurrences of other people, and ideas. On how to fix these issues.

Maybe check if your centre position is at 90* physically? Thats usually a good practice. The other thing I'd recommend is doing more testing using another control solution, perhaps the fault isn't with the software.

What do you mean but beating at 90° physically? Also, my steering mechanisms don't always turn 90° untill end stop. And what other control solutions are there? I don't own a gaming controller.

Just now, NV Lego technic said:

What do you mean but beating at 90° physically? Also, my steering mechanisms don't always turn 90° untill end stop. And what other control solutions are there? I don't own a gaming controller.

The axles cross pointing to the 4 surrounding holes, if that makes any more sense.. As for your steering systems not turning 90 till end stop, that's probably fine. If you don't own a game controller then I'm not aware of any other options, sorry.

I have tried setting it up like that, issues are always as bad as the are.

If I got it correctly the calibration should lead to the PWM algorithms finding the correct stopping points on each side and should map the position to the range of the controller / the virtual input range (-100% to 0 to +100%).

As I am no satisfied customer of Fortronik, my personal opinion may go into the direction of them possibly not offering the best product in regards of their software stack - but it may be my very singular experience which is kind of the same but other: Setup of connection and other stuff should work better, sometimes one feels just "betrayed" by the software doing things "on its own" which may drives at least me crazy very often...

But to think in solutions instead of complaining:

• I would doublecheck if both endpoints have the exact distances or if they may bend from the pressure of the calibration attempt (possible solution: The amount of power for the calibration can be set between high/medium/soft - putting it to lower values may result in less bending & more resulting accuracy)
• The "suddenly going off center / doing crazy things" I can't really explain from my perspective, I have just an idea of the PWM signal getting another value and the buwizz software may missread it as "centered already" - because PWM signals of their exact position need much rpm for this to work, theory here is: too less rpm for the position-recognition ever being able to work in a sharp and precise way.

Hope that somehow helps, possibly others may have better tipps, fingers crossed for getting your issues solved!

Best regards

Disclaimer: I am not electrician nor do I have deep knowledge there, but from what I understood of PWM, the calculation of the position can be done with the different phases which are creating the impuls(es) for the motor to turn. That all is done in a pulsed way of setting the signals - as I am an IT person: may it be for some reason one or more pulses may be eating because of real-time passing as the controller board may be still busy with working on the commands of the last cycle possbily leading to "skipping a pulse" in consequence and creating the "sudden" offset in center?

That may be a question for @Toastie or @oracid - sorry for mentioning you both, can one of you help me out here to say if this theory may be total bs?! If one can, thanks in advance (I think both of you should have plenty of experience with PWM..)! 

Edited July 17, 2024Jul 17 by aFrInaTi0n

You mean that I should increase the centering speed in the center steer settings? Thanks for advice!

2 hours ago, aFrInaTi0n said:

sorry for mentioning you both

Hey, no problem!!! Asking tough questions like this one is a) rather refreshing to me and b) one of the more relevant reasons for the existence of an educated, well maintained forum that Eurobricks is.

As I have hardly ever worked with servos, nor do I have a BuWizz and such, but believe in knowing their principle of operation of servos, I have multiple questions :D

What is the feedback mechanism in the servo motor(s) used with the BuWizz device? Are these PUp tacho motors? These are not servo motors but rather motors delivering a digital signal back to a controller (e.g., BuWizz) mainly for PID rotation control (constant speed of the controlled axle) as well as pulse counting control for reaching exact stopping destinations, which is what you want to accomplish, right?

When using the BuWizz in that "servo mode", does the motor rotate at constant rpm (no load) to the final destination, and then suddenly stops? Or does it do that smoothly? In other words, does it slowly accelerate, then rotates at constant rpm, then decelerates and stops at the final position? Again, with no load, just freely running.

Now when using PUp motors, you have a fairly high resolution for one 360° rotation; the RCX rotation sensor had 16 steps per turn (https://www.philohome.com/sensors/legorot.htm) I believe PUp motors have a much better resolution; in this reference 1° (https://bricks.stackexchange.com/questions/16395/difference-between-the-simple-medium-linear-motor-45303-and-the-medium-line). 

You are absolutely right: The higher the rotation resolution, the better are the results. When the controller has to do many other things than paying attention to the numbers (clicks of the rotation sensor), then things go easily out of control. I have no clue, though, how much intelligence is inside the PUp motors in this regard. Do they just feed back pulses? Do they process the pulses? I believe @Philo knows so much more on these issues!

We'll see, the forum has been summoned

All the best,
Thorsten

   

 

The performance was significantly better with original Lego software. Maybe there's something up with internal sensors of the Buwizz unit. 

With mechanisms I've tested, there's usually between 90 and 180° of rotation between end stops. The servo mode means that a motor with a rotation sensor is calibrated, and then it should find a center between those 2 end stops. With Buwizz, it sometimes misses the center, bringing it more towards one side. And sometimes, the center is shifted all the way towards one side for no reason and behaves like it's always been that way.

@Toastie time marker -> may be helpful for a person which is more into pcbs and functions of components than me...

edit: but not sure how much of the electronics of the old & original servo motors may be related to the PU L Motors, as the difference is PWM vs old non-PWM? Just realized that possibility in that second.. :o

edit 2: mixed two threads and had wrong, non fitting content in here -> deleted... seems like thinking is not my strength today... *sigh

Edited July 17, 2024Jul 17 by aFrInaTi0n

56 minutes ago, aFrInaTi0n said:

functions of components

Well, this seems to be a copper-type rail he is cleaning, providing continuity to other parts of the servo rather than providing a proportional response to the angle, as a potentiometer would.

Oh, I just realized that this is a LEGO PF servo motor - there is zero intelligence in the PF receivers other than providing PWM signals from power levels 1 to 7, if I am not mistaken. So all the "work" is done inside the servo motor electronics.

When you go to PoweredUp tacho motors, all you get is a signal back from the motor - and I believe it is clicks/rotation or something the hall sensors provide. From that info, the controller has to do all the (PWM control) work.

So when the BuWizz glitches when using LEGO tacho motors like the PUp L motor, it appears to me that there is something wrong in the software/firmware of the controller. Again, I learned that the hard way, when I programmed PID control into the RCX. The 16/revolution resolution (hey, does that sound nice or what?) was sometimes causing some "spikes"; but moreover, the BuWizz has to do so many more things/second when running wild off-grid competitions, as a train requires.

Just gussing here, others may know much more!

Best,
Thorsten

Edited July 17, 2024Jul 17 by Toastie

8 hours ago, Toastie said:

something wrong in the software/firmware of the controller. 

Exactly.

13 hours ago, aFrInaTi0n said:

old & original servo motors may be related to the PU L Motors

I watched that video again (as I don't have PF servos); at 0:54 you clearly see that 0°/90°/180° are hardware "coded" into the motor as the copper "trace" is cut at these positions. I also believe in seeing a potentiometer at 0:57 in the front part of the servo, lying in the little bowl. So this seems to be a classical DC servo motor, where the PWM signature is translated inside the motor's electronics to the corresponding power feed to the motor.

A PUp L motor does not have all these "servo things" (dedicated electronics, no software), all the smart stuff has to be done with firmware/software, per PUp data communication motor <-> "hub" = controller. And I believe this is where things can definitely go wrong. The resolution of the encoder inside in PUp tacho motors is 1° = 360 clicks per full revolution = 180 clicks per half circle. This is a rather "fine grid" and calculations of the "error" between set point = position of the (software) dial and the actual position of the (calibrated) motor, are done by the hub's firmware.

For a tacho motor (which is not primarily intended to function as a servo) calibration is of course necessary, because it does not know "where it is" when it is powered on, in contrast to a hardware servo, as it has the potentiometer telling it, where it is ... As far as I know, there is no hardware "zero" position, I may be wrong though.

So yes, this erroneous behavior of the PUp L motor on the BuWizzes using servo mode seems to be a firmware/software problem.

Best,
Thorsten 

Edited July 18, 2024Jul 18 by Toastie

15 hours ago, NV Lego technic said:

With Buwizz, it sometimes misses the center, bringing it more towards one side.

Ah - which could simply mean, that the hub missed some of the "clicks" from the motor when rotating. Phew, accurately getting each click is a rather tough task, particularly when so many clicks are coming in! Such errors easily build up; when the controller believes the motor is at the 90° (center) position, but it actually is not (caused by these missed pulses from the hall sensors and motor power was still delivered by the hub until it believes, the motor is at the 90° position) then the next steering command all the way to an end stop in the direction of previous error will certainly introduce the next error, because the motor is at a final hard stop, but the logic inside the hub is not ...  This should result in some interesting behavior (OK, others find disastrous ).

Well, don't use a tacho motor for a servo task - or use really fast and reliable electronics combined with smart software, when using a tacho as servo motor.

So does this erroneous behavior happen with the LEGO hubs as well, when tacho motors serve as servos?

Best,
Thorsten

Edited July 18, 2024Jul 18 by Toastie

16 hours ago, NV Lego technic said:

The performance was significantly better with original Lego software

This.

1 minute ago, NV Lego technic said:

This.

Oh, sorry, missed that. But this "not going back accurately to 90°" thing still does happen to some extent?

Best,
Thorsten

When you turn the slider to one side, it goes back normally, and when you turn it to the other side, it stops about halfway to the center.

So LEGO hubs have principally comparable problems, right? It is worse with BuWizz, but essentally using a PUp L motor (tacho motor) as servo is not necessarily the best solution; it would have been much better to have real PUp servo motors, isn't it?

Best,
Thorsten

No. With Lego hubs it performs flawlessly, and any unwanted steering is due to mechanical backlash.

Ooops, then the BuWizz is the sole problem, good to know.

Thank you for clarifying!

Best,
Thorsten

Edited July 18, 2024Jul 18 by Toastie

That's why I named it Buwizz software problems and not PU motor problems.

7 minutes ago, NV Lego technic said:

That's why I named it Buwizz software problems and not PU motor problems.

Those who can read have a clear advantage ...

I am very impressed by all this posts, thank you @Toastie.
For my part, my skills in Buwizz, Lego servos and smartphone remote are zero.
I only use RC remote and servos, controlled by Arduino.
Sorry.

Sometimes when my buwizz controller seems to be 'misbehaving' it comes down to a bad plug/contact. Generally with the PU plugs I have to use the safety pin method a few times a year. 

Edited July 20, 2024Jul 20 by shroomzofdoom
The

What is the safety pin method?