I use an MT6701 magnetic rotary sensor mounted on the motor shaft, running in AB[Z] mode. This is used to measure the angle of the motor, and generate the correct PWM signals for the three motor coils. My inner current-control loop runs at 15kHz, using a PI controller.
For a robotic BLDC motor velocity control application, I moved to using a linear ADRC (Active Disturbance Rejection Control) [0] controller. It is not much more complex to implement that a PID, but at least in my context it handles changing real-world environmental conditions with a correctness which I could not achieve with a PID however much I tried to tune it.
Still uses a PID for BLDC motor coil current control, as this control loop is much more predictable.
Currently using the proportional part only from a PID for position control, but this may change in the future.
Coincidentally, we're based fairly close to where they operated. We are in touch with some of the people that used to be involved with SRC, and have been able to learn from some of their experiences. There is agreement that the UK can be difficult for this kind of startup, but also about the importance of the product area.
My knowledge of ROS is a couple of years out of date, but primarily that reproducible testing and simulation, with precise time/clock management, which is essential for a reliable product, was very difficult in ROS.
I also felt the ROS build system more convoluted than necessary; and seemed rather brittle - it was too easy to break it with OS or other updates.
We found that many off-the-shelf ROS nodes didn't do quite what we wanted, and ended up spending much more time than expected rewriting code that we expected we wouldn't need to. It is quicker, and we end up with less & more maintainable code, by writing it ourselves.
I expect this could have been resolved, but when testing ROS we also ended up using more compute resources on-robot than we expected.
Using our own system allows us to build exactly what we require, which has become more important as our system gets larger and more complex; and means integrations into other systems (including testing) are easier.
Before we started building we considered many different designs, including legs. However, it introduces significant extra mechanical and control complexity, with more complex failure modes - e.g. one leg gets stuck in the mud; it also would be more expensive to build.
So we decided to stick with wheels, at least for this product iteration!
Autonomous robotics for sustainable agriculture. Based in the south of the UK. Prototypes of an autonomous mechanical farm-scale weeding robot currently beginning real-world testing. Still a huge amount of work to do though.
Hardware and software developed fairly much from scratch, not using ROS (for not entirely crazy reasons...); everything written in Rust which I find well suited to this application area.
The robot is built using off-the-shelf components and 3d-printed custom parts, so build cost is surprisingly low, and iterations are fast (well, for hardware dev).
On robot compute is a couple of Raspberry Pi 5s.
Currently using the RPi AI Kit for image recognition, ie Hailo 8[L] accelerators.
Not currently using any advanced robotics VLA-type AI models, but soon looking to experiment with some of it, initially in simulation.
Feel free to get in touch if you'd like to talk :) Contact details in my HN profile, and on our website.
These are apparently not large EV-type rechargeable lithium batteries, as I immediately assumed.
From the article: "Aricell makes lithium primary batteries for sensors and radio communication devices". A "primary battery" is non-rechargeable; and given the use-cases mentioned I expect each individual battery is fairly small.
Of course, when there are 10s of 1000s of them together that's still a lot of energy to burn.