gyenesvi Posted March 31 Posted March 31 Hi! A question to those who have already used the Lego Wireless Protocol to control Lego PoweredUp hubs. As far as I understand, PU motors have two positions. An absolute angle relative to an external fixed zero point (the point marked on angular motors), between -180 and 180 degrees, and a position relative to a preset value, which starts out as 0 when the hub is turned on or when the motor is connected to the hub and can remember multiple complete turns (not limited to 180 or 360 degrees). It is possible to query these values from the motors as sensor inputs (corresponding to 'POS' and 'APOS' input modes, APOS being the angle, and POS being the position relative to the preset), and I can confirm these work as intended, I get the absolute angle correctly, and I get 0 for the relative position on startup, and they change appropriately as the motor rotates. In the protocol, there's an output command called GotoAbsolutePosition. I'd expect by the name that it moves to a specific absolute angle, but instead it seems to move to a specific position relative to the preset value. My question is how to move the motor to a specific absolute angle? I know that I could use the preset to set it to the angle at startup, and then just use GotoAbsolutePosition, but for that I need to do querying/setting of motor modes/values, which I want to avoid on startup (also, I want to be able to switch output modes while having the motor input query set to a fixed more). Ideally, it should be possible to do this without switching modes and altering the preset value, since the motor does know its absolute angle internally (as confirmed by the querying). Does anyone know what commands achieve this? It should be similar to all other output commands, without requiring any querying. Thanks! BTW, if you think this question has a higher chance to be answered on another part of the forum, please let me know! Quote
vascolp Posted March 31 Posted March 31 If that is possible, you could skip initial callibrations in, for instance, steering, insn't it? But I think all lego models have an initial callibration step.... Maybe if you rotate the motor while it is desconnected it can't keep track of its current position? Just guessing... Perhaps @Pybrickscould help us about that? 6 minutes ago, vascolp said: If that is possible, you could skip initial callibrations in, for instance, steering, insn't it? But I think all lego models have an initial callibration step.... Ah, forget about callibration, callibration is there because when we build it we don´t need to care with motor position, any position will do. Quote
gyenesvi Posted April 1 Author Posted April 1 10 hours ago, vascolp said: Maybe if you rotate the motor while it is desconnected it can't keep track of its current position? Just guessing... The motors do keep track of their absolute angular position, as I confirmed with the queries (even right after startup of the hub, I get a nonzero value if the shaft is rotated). 10 hours ago, vascolp said: Perhaps @Pybrickscould help us about that? I'm not sure Pybricks itself is relevant here, as this depends on the original firmware, but sure, the developers might have some knowledge about his. In fact, I'm curious how this works in Pybricks as well, because the separation of absolute angle and accumulated angle is not clear for me in Pybricks either. Reading the docs of Pybricks, it seems also there's only one method for moving to a specific angle (motor.run_target), even though it is possible to reset the relative position to the absolute one, so there exists a separation between the two. As far as I understand, this moves to the accumulated target relative to the preset value. So why is there no way to move to the absolute angle? And also it seems there's no explicit way of querying the absolute angle? @Pybricks? 10 hours ago, vascolp said: Ah, forget about callibration, callibration is there because when we build it we don´t need to care with motor position, any position will do. Yes, calibration isn't necessary if you build the model properly, that's exactly one possible use of this piece of info. It is possible to solve the problem by querying the angle on startup, resetting the relative position to the angle and then controlling the motor with relative position, but that sounds cumbersome and unnecessary (doing the querying properly is more complicated to implement due to asynchronous programming than actually controlling the motor). Quote
gyenesvi Posted April 2 Author Posted April 2 Looking at how the Buwizz 3 protocol works also confirms that this should be technically possible given the motor hardware. In the Buwizz protocol, one only needs to set the output mode (power / speed / relative position / absolute position) and then set the output value. It is possible to preset the relative position, but it is not required in order to control the absolute position (i.e. works without it, exactly what I'd like to achieve with the Lego hub as well). Furthermore, the Buwizz protocol allows separate setting of a reference value both for relative position and speed, while the Lego protocol only allows setting a reference value for the relative position. I guess these reference values are probably stored by the firmware itself, and not an inherent property of the hardware; the inherent property is the absolute position. I wonder why the @Pybricks firmware chose an API similar to the Lego firmware (tying the angular movement to the relative position), instead of something similar to the Buwizz 3 firmware (allowing independent movement wrt relative and absolute position)? Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.