@keno-san if that's a direct copy-and-paste, double-check whether that comma wants to be there.

@Gero Effectively, yes. The point is to avoid needing to measure or specify torque or rotation at each joint, because we've not got the hardware, and the servos will have a fair manufacturing variability anyway. So instead measure what we can, which is the acceleration from the legs as a unit, and say that because mass is defined as 1 in some convenient unit, F=ma means that force is numerically just the acceleration, in some equally convenient unit. How do we know the leg is in contact with the ground? I actually don't know if the MPU6050 is fast enough to do this, but if you assume we've got a hopping gait working, with the mass bobbing up and down, alternating between ballistic and contact periods, then you know that if you're in a ballistic phase and moving downwards, but you're accelerating upwards, then there must be contact with the ground. If you've got enough data coming out of the accelerometer, you don't need additional sensors to tell you that. And once you've spotted you're in contact with the ground, if you know which two feet you've extended, you can use the gyro data to tell you which one hit first, and when the second one lands. I think. There's a whole lot of sufficiently-advanced-handwaved-magic processing of the accelerometer data here, I know, but I *think* it's doable in principle as long as the data requirements and the speed that things are happening at are within the limitations of what we can squeeze out of the MPU.

@Gero I had a minor brainwave in the shower this morning. I think we can get away without needing to calculate the torque at each motor. There's a function I wrote early on `setLeg(index, length, shoulderAngle)` which does the trig to figure out where to put the foot so that the given leg is at a certain radius and angle from the shoulder joint. It's some fairly trivial trig, but it's made much simpler if you define the length of the fully extended leg to be 1; all the motors care about is the angle, after all. That got me thinking: how about defining everything in terms of Nybble-body-units? They all map linearly to whatever scale system you want, but the advantage is that if you define Nybble's mass as 1.0Nybbles, then the torque in the motors is whatever is necessary to produce a given upwards acceleration against gravity. You can measure that, and as long as it's a reasonably sane function of the change in requested leg length, you don't need to know what's going on behind the scenes. Treat the whole leg as a black box actuator (or rather, all four and divide down, I guess), and it devolves to being a calibration problem using the MPU6050 rather than trying to get a hold of the actual rotational frequency. Rather than giving you the torque at each joint, that would give you a net force at each shoulder, which I *think* might be easier to deal with. It'll fall down if you need to care about the inertia of the leg independently of the body, but I don't think we need to? Does that make sense, or am I barking up a tree that's not a tree?

That's where I got to - servos being in the middle really doesn't help. I'm trying to put together some resistive pads to attach to the feet so you can measure the down-force, that would at least give you something to work with. The other place to look would be getting at the motor current *somehow*. I'll take a look at the python, thanks for that. I'm not getting as much time on this as I'd like, but we'll get there 😀

To answer your question about feedback control, all I've done as a sort of proof of concept to show anything was possible at all is to take the gravity vector and use it to change leg lengths, in a very approximate way - Nybble balances on a tilting book up to a good 30 degrees off-horizontal just by using the components of the gravity vector away from vertical along the x and y axes *directly* as error signals, you don't even need to do any trig. Just a gain factor of about 0.05 so the movements aren't too violent. That does limit the speed he can react at, so it's shonky as hell, but like I say - proof of concept :-)

I'm still working on it, but aiming at a Raibert-style trot. The lack of shoulder roll, direct torque control, or foot sensors makes it a bit of a challenge, so I'm having to go back to basics a little and work some of the maths out from first principles. The good thing about this sort of gait is that the calculations are really simple. The execution time is dominated by waiting for IO on the nyboard, you don't need very much CPU grunt at all. I'm sure it *could* be done on the biboard, but I actually prefer having a linux distro mounted on Nybble for a number of reasons, not least that I'm far more comfortable there and if I do want to strap a camera on too, I know exactly what I'm doing hardware and software-wise. Boot time is the one downside, but once I've got something that's worth packaging up I've got buildroot as an option. I'm also quite keen to give erlang a try at some point, and I don't think BEAM's been ported to ESP32.

With that in place it works for me - although the distance readings aren't particularly accurate, they do respond to me waving my hand around. Nybble can see! 😁

@D_C_E My wiring is slightly different (also on a v0_2), but I suspect I might just have solved the same problem. I'm going VCC->D8, TRIGGER->D9, ECHO->D10 so my pins are the same order as on the SR04. I found that there's nothing in the code to tell it that the VCC pin should be an output. I needed to add this, and call it from setup(): #define ULTRA_VCC 8 void ultraSetup(){ pinMode(ULTRA_VCC, OUTPUT); digitalWrite(ULTRA_VCC, HIGH); pinMode(TRIGGER, OUTPUT); pinMode(ECHO, INPUT); }

Oh, nice. I had a go at squeezing freertos in there for pretty much the same reason, but there's not enough ram to do anything useful.

I've got to say, I'm a newly minted massive fan of the 3A+ for this sort of application. So much less bulk than the B, and the idea of running an erlang controller process is extremely tempting. So far it seems safe to have a power supply plugged into the Pi and to have the main battery coming and going, which answers a worry I had early on. I haven't figured out how to trigger a nyboard reset from the pi yet, though, and that would be extremely convenient.

I'm using one of these: https://www.amazon.co.uk/gp/product/B00I8N88O6/ref=ppx_yo_dt_b_search_asin_image?ie=UTF8&psc=1 As far as I can tell that's equivalent to batteries that people say are working in the report thread, it should be good for 30A or so. That being said, I've not actually checked the voltage while Nybble's running. I've only got multimeters, unfortunately, no oscilloscope to hand (yet... although maybe this is the excuse I need) My worry with adding a second battery is that there just isn't quite enough ground clearance if I double them up, but it would at least tell me if that's what's going on.

[Errno 13] could not open port /dev/tty50 That is unlikely to be the right serial port filename. It looks like you've mistaken a capital 'S' for a '5'.

@Rongzhong Li Could over-voltage do this as well? I accidentally bought some 11.1V 3-cell LiPo's instead of 7.4V 2-cells, and I'm getting this behaviour with a raspi 3A+ plugged in to a V0_2. It seems to work fine without the pi, though - controlling via the remote without the pi plugged in all works like you'd expect.