chrisb

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.

[0] https://en.wikipedia.org/wiki/Active_disturbance_rejection_c... (although this isn't a very useful reference if you want the implementation maths!)

The linked article is misrepresented.

Two points regarding blade recycling techniques taken straight from the top of the article:

- Cement co-processing and chemical dissolution are primary viable methods, yielding $27.57/ton and $199.71/ton returns respectively.

- Chemical recycling achieves top circularity (PCI=0.7) and notable carbon reduction (−0.475 t CO₂/ton).

Chemical recycling is not yet ready for industrial use; cement co-processing is.

Many years ago, a moderately complete interpreted .NET runtime - https://github.com/chrisdunelm/DotNetAnywhere

This was long before .NET Core, and was designed to allow C# to be used on highly limited platforms

Nice to meet an SRC investor :)

Yes, it was all very sad the way SRC ended.

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!

https://spring-agriculture.com/

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.

The article isn't completely clear; but hr-in-select is standardized [0] - and it definitely works in the Firefox v122.0 I'm browsing with.

[0] https://html.spec.whatwg.org/multipage/form-elements.html#th... (see the "Content model" line)

The subsequent prequel "A deepness in the sky" is also well worth a read.

This claim of grid overload is false.

See [0] for the UK grid operator's view on this, also includes a few numbers relevant to the US grid.

[0] https://www.nationalgrid.com/stories/journey-to-net-zero/ele...

My anecdotal experience...

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 :)

I live just a few miles to the North. Nice to see a few other ~Dorking locals here :)

Interesting paper here on e-prop which is a biologically plausible alternative to backprop: https://www.biorxiv.org/content/10.1101/738385v3

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:

energy = 1,000,000,000 (mass) * 100 (height) * 10 (gravity) = 1,000,000,000,000 Joules

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.

Which is many times more than the current global annual concrete production of 10,000,000,000 tons (ref: http://www.columbia.edu/cu/civileng/meyer/publications/publi...)

Towards the end of the article, it suggests dissipationless power lines as an application.

Whether "dissipationless" is equivalent to "superconducting" I'm not sure; but it sounds the same to me ;)

Interactive version of this map showing fishing activity: http://globalfishingwatch.org/map/

"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."

Curious. All other reports I've read state that AMD CPUs are not vulnerable.

I probably won't get around to doing this.

But someone else is very welcome to do so :)

Sadly DotNetAnywhere definitely isn't ready for production, and by the sounds of it Blazor is not either (I'm not involved in Blazor).

It's possible some of the other DNA forks mentioned here may be more suitable for production, I'm not sure.

I wrote an CIL-to-JS translator too:

https://github.com/chrisdunelm/DotNetWebToolkit

It's not complete, certainly not usable for anything remotely real, but could handle quite a bit of C#. And was fun to work on :)

My memory is a little vague...

But I'm fairly sure the hardest part to implement was the support for generic types/methods. It made all the code that handles types way more complex (as expected I suppose!), and there's definitely a bug or two remaining. Correctly handling open/closed generic types and construction of types from generic arguments was painful. It didn't help that I initially implemented only non-generic type support, then had to hack generics into it. Were I to start again I'd implement the whole thing in a generic-first way.

The design of classes/structs and they they interact with generics is nice. And the `constained` IL prefix is a really neat optimization to avoid boxing. The use of type-agnostic CIL instructions (e.g. `add` can work on int, float, ...) is also a nice touch.

JIT literally stands for "Just In Time". It doesn't say what it's actually doing just-in-time ;) So (in my opinion) JIT.c is correct. It's translating CIL opcodes to dna-internal opcodes, which it does just-in-time just before a method is executed for the first time. The reason it does this at all is because there are many things to resolve when working from CIL that it's much better to do just once rather than every time a method is executed. A simple example is method references, which are by name in CIL, but are a simple pointer in dna-internal opcodes.

I'm the original author of DotNetAnywhere.

For all its flaws (and there are quite a few) it was a very interesting learning exercise, and it worked better than I ever really expected ;)

I don't really intend to ever do any more work on it, especially now that there are open source "real" implementations. But it's been nice to see it used in Blazor :)

If you have any questions about it, please ask.

Reducing the browser window size fixed the glitching for me (Chrome, MacBook Pro).

Agreed about the hope for our species.

As a species and as individuals we're capable of such astounding accomplishments like this; yet also capable of outstandingly in(s)ane idiocy.

How can society be arranged/evolved to encourage the former, and limit the latter? Is such a thing possible? Desirable?

The lack of societal optimization, or even moving towards the optimal, frustrates me!

This is factually wrong; rare earth elements are not required for batteries.

Rare earth elements are cerium (Ce), dysprosium (Dy), erbium (Er), europium (Eu), gadolinium (Gd), holmium (Ho), lanthanum (La), lutetium (Lu), neodymium (Nd), praseodymium (Pr), promethium (Pm), samarium (Sm), scandium (Sc), terbium (Tb), thulium (Tm), ytterbium (Yb) and yttrium (Y) (https://en.wikipedia.org/wiki/Rare-earth_element)

Lithium batteries generally require elements such as: Lithium, graphite (carbon), Nickel, Cobalt, Manganese, Aluminium, Oxygen.

None of these are rare earth minerals, and production of most of these elements is not concentrated in China. See https://electrek.co/2016/11/01/breakdown-raw-materials-tesla...

The powerful permanent magnets used in some EVs do require rare earth elements (e.g. neodymium), but many EV motors don't require permanent magnets at all. E.g. Tesla uses an induction motor (no permanent magnet required); whereas the Nissan Leaf does use permanent magnets (assuming https://en.wikipedia.org/wiki/Electric_vehicle#Electric_moto... is correct).

Making Arena93 full-screen (within Windows93) hard-crashed my Mac! (MacOS 10.12.4, using Chrome 58)

And if you set num=0 then it returns the normal "did not match any documents" page: https://www.google.com/search?num=0&q=temperature+london

Which seems like it could be used to fool someone into thinking there really are no results for a subject.

Or to pretend Google search is broken ;)

There's an interesting view on that here: http://worrydream.com/ClimateChange/