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.
I own a Peugot iOn (rebadged Mitsubishi i-MiEV) manufactured in 2012, so it's 9 years old. I bought it second hand, and the service record shows it's needed zero maintenance (aside from tires). I have not needed to perform any maintenance in the ~2 years I've owned it.
I'm not in any way recommending this specific car (although it suits me perfectly); but it shows that even a fairly early electric car like this is 10-year capable. The only downside has been the expected gradual decrease in range.
I've also owned a Tesla Model 3 for 16 months, and it's been maintenance and trouble free. I'm not denying that some people have problems with them, however that's not been my experience, nor the experience of the two other people I know who own one.
I probably plan to keep the Tesla for many years, so hope my trouble-free motoring continues :)
The energy density really is abysmal, which is why the "lifting heavy things up" techinique of energy storage is essentially never discussed outside of pumped-storage.
The problem is the linear relationship between the mass, the height, and the stored energy: energy = mass * height * gravitational-acceleration.
gravitational-acceleration is fixed at the earth's surface to ~10m/s2
So taking an example of 1,000,000 tons lifted up 100 meters:
This looks like a lot, but really isn't. It's equal to ~278 MWh (megawatt hours), which means it can supply 278 MWs for one hour. 278 MWs is equivalent to one small power station.
Note that the largest pumped-storage power station in the UK, which is of course constrained by exactly the same E = mgh formula, Dinorwig (https://en.wikipedia.org/wiki/Dinorwig_Power_Station) stores ~9,000 MWh.
Another way to consider this is to calculate how much mass needs lifting 100m to supply the whole of a country for a day.
As a very crude estimate the UK requires an average of about 30,000MW of electrical energy. Over a day this equals 30,000,000,000 * 24 3,600,000 Joules = 2.510^18 Joules per day.
The mass required to be lifted up 100m to store this is 2.510^18 / (100 10) = 2.510^15 Kg = 2.510^12 tons = 2,500,000,000,000 tons.