> The hardware is built around a stackable 10×10cm compute module with two ARM Cortex-A55 SBCs — one for ROS 2 navigation/EKF localisation, one dedicated to vision/YOLO inference — connected via a single ethernet cable.
I will preface this by saying that I have nothing against ARM per se, that my employer/team supported a good chunk of the work for making ROS 2 actually work on arm64, and that there is some good hardware out there.
I really don't understand why startups and research projects keep using weird ARM SBCs for their robots. The best of these SBCs is still vastly shittier in terms of software support and stability than any random Chinese Intel ADL-N box. The only reasons to use (weird) ARM SBCs in robots are that either (1) you are using a Jetson for Jetson things (i.e. Nvidia libraries), or (2) you have a product which requires serious cost optimization to be produced at a large scale. Otherwise you are just committing yourselves and your users/customers to a future of terrible-to-nonexistent support and adding significantly to the amount of work you need to bring up the new system and port existing tools to it.
schaefer 1 days ago [-]
> The only reasons to use ARM SBCs in robots are...
Obviously, anyone can have there own opinion on this.
I work in robotics, we are quite happy with our A53 and M4. Though, we use a SOM, not a SBC, if you feel like splitting hairs.
cpgxiii 1 days ago [-]
You probably aren't using some weird SOM, though. There is a bit of an unstated exception of "unless said SBC/SOM has specific hardware that is necessary/particularly valuable for your product/project". For example, if you need GMSL you are probably not going to be picking Intel, even though ADL-N and the bigger processors support MIPI, simply because no one else does and the documentation/support for it is basically nonexistent. Designs with closely-coupled A/M/R cores, or CPU/MCU/FPGA hybrids like Zynq would be others.
But generally projects which are choosing some random SBC aren't using any of these features, and are just suffering the pain/imposing it on their users for no good reason.
schaefer 23 hours ago [-]
again, just an oppinion, but it feels really weird to hear you find "exception after exception", when the net result that you've ruled out more real world robotics projects on ARM than likely exist on x86 that you're suggesting should be the "norm".
you've ruled out the entire NXP ecosystem, the entire Nvidia Jetson ecosystem, the entire AMD/FPGA/Zynq ecosystem, even perfectly good options like beagle-board .... who else?
incidentally, you've also ruled out this project - as they are using an M7 microcontroller to meet their hard-real-time timing constraints...
adrian_b 12 hours ago [-]
The other poster had said nothing about microcontrollers, e.g. about the various MCU models based on Cortex-M cores.
Some things are best done with a microcontroller, and those are not suitable for being done with a general-purpose CPU either based on Intel/AMD or on Cortex-A cores. Actually there are many projects that mistakenly use something like a Raspberry Pi instead of a better and cheaper implementation with a microcontroller, e.g. one based on Cortex-M7 or its successor, Cortex-M85.
The other poster said that where you do not want a microcontroller, but you want to run a standard operating system, e.g. Linux, then the best choice is much more frequently a SBC with an Intel Alder Lake N or Twin Lake CPU, as these not only have a better performance per dollar than the ARM-based SBCs, but they also avoid any software problems and future maintainability problems.
Unfortunately, during the last few months the price of Intel-based SBCs has been affected by the fact that most of them do not have soldered memory but they use one SODIMM memory module. While you can buy an Intel Alder Lake N based SBC for $100, buying today a SODIMM for it may cost as much or more, depending on the amount of memory with which you are content.
The ARM SBCs that come with soldered LPDDR memory have initially been less affected by the price hikes, though now even for them the prices are rising.
cpgxiii 21 hours ago [-]
I think you're missing my point entirely. If your project needs specific hardware, you have to use that specific hardware (the obvious examples of which would be Jetsons or Zynq/Zynq-like or something ASIL-D or something that tightly couples "A"/M/R cores together, or you are stuck using a SoC from Qualcomm for cell connectivity). There are a lot of projects that do fall into that category.
There are also a (much smaller) number of projects that will legitimately see the kind of scale of production that justifies aggressive cost optimization for the compute platform, either in terms of designing their own around a SoC or picking some SBC/SoM that they can get a good deal on, where the significant additional up-front engineering cost is outweighed by the production savings (and where the desire/need to keep a fixed platform means the often limited platform support from the vendor is less restrictive).
But a large number of robotics projects (basically everything in the research sphere) - this one very much included - just need "some computer" for general-purpose use. They are already separating realtime control onto a separate microcontroller board. For these projects, it is almost always committing a "premature pessimization" of picking some weird SBC. You are signing up for worse CPU and GPU performance, stability, and development future for very little reward.
Sabrees 1 days ago [-]
If you can send me an open hardware Intel, or Jetson I'd happily use it.
Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)
cpgxiii 1 days ago [-]
There are a variety of x86 products with Coreboot support, if what you are looking for is firmware openness. If what you are looking for is PCB design openness, the options are much fewer, but at that point you are probably optimizing for an overly niche objective.
> Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)
I appreciate the idea, but this is essentially saying "this project will prioritize a specific choice of one (core) piece of hardware to the detriment of everything else, users included". Approximately none of your potential users are going to benefit from the "openness" of the SBC versus that of a more broadly-supported platform (I say "openness" because the reality of SBCs is that actually finding a usefully performant one that is completely blob-free is almost impossible). Open hardware means very little if it isn't running an upstream kernel and userland.
Sabrees 1 days ago [-]
The software does explicitly support Jetson for example, and I'm sure the stack would run on Intel if you want it to.
The Mainline kernel for this particular board is _almost_ there 6.20 or so I expect. Armbian support is good.
Neywiny 1 days ago [-]
Framework? Maybe?
Sabrees 1 days ago [-]
Framweork have done the best they can within the confines of Intel licensing, still a long way from being able to fabricate it though
In a few years we'll all be using more open RISCV stuff of course.
adrian_b 12 hours ago [-]
The South-Korean Hardkernel ODROID H4 models are open hardware. There is no need to send one to you, as you can order one yourself from their on-line shop or from local shops.
You get their schematics/PCB documentation and their BIOS has features that are missing in most mini-PCs and laptops with Alder Lake N/Twin Lake, e.g. you can enable in-band ECC for the memory. You can choose various variants of the SBC and you can buy cheaply various accessories, e.g. several case variants and additional peripheral interfaces. Those ODROID H4 SBCs are also correctly designed for cooling inside a box like that used in this project, because the PCB is attached to a big heatsink and you can attach the heatsink directly to an aluminum wall from inside the box, ensuring good thermal contact with pads or grease, so that the electronics will be cooled well.
Most technical information can be found in their Korean site, but there is a UK distributor (though the prices appear greatly inflated here; so much that it might be cheaper to buy from South Korea, depending on shipping costs and applicable taxes):
Also the Chinese Radxa has a Raspberry Pi sized SBC with an Intel N100, which is open hardware, with complete schematics/PCB documentation (but unlike ODROID H4, which has excellent cooling and it can be used without a fan, it is unclear how easy is to cool the Radxa SBC).
Moreover, unlike for many Intel/AMD CPUs, which no longer have public documentation, for Alder Lake N Intel still provides public datasheets, which contain e.g. the thousands of control registers for the on-chip peripherals. Most ARM Cortex-A based CPUs are undocumented, with few exceptions like Rockchip RK3588 and the very expensive NVDIA Orin/Thor (or the obsolete Xavier). All Cortex-A based CPUs have secret boot loaders, so you can never be certain that your programs really run on bare metal, as the CPU vendor can implement the equivalent of the Intel System Management Mode, where the proprietary vendor firmware can take control from your own operating system whenever it wants.
There are somewhat more ARM-based SBCs than Intel-based SBCs that are open hardware, but there are also plenty of undocumented ARM SBCs that are much worse from this PoV than the Intel/AMD based computers, where at least the IBM PC standards and the later standards pushed by Intel, e.g. ACPI/UEFI, apply. The Allwinner CPU used in this robot has almost non-existent documentation, in comparison with Intel Alder Lake N, so it is much farther from "open hardware".
You have mentioned the NVIDIA Jetson modules, which are based on Thor/Orin/Xavier. Those have excellent documentation, but you have to register at NVIDIA, for a free account, in order to access it. The documentation is not the problem with them, but the fact that they are greatly overpriced, like almost anything made by NVIDIA. Unless your application critically depends on some feature provided by NVIDIA, for which no acceptable alternatives exist, choosing Jetson is a very bad decision, because the alternatives are usually both better and cheaper.
The SBCs based on Cortex-A55 are the cheapest for the purpose of running Linux that still have a decent performance and they may be sufficient for many applications.
However, the SBCs based on either Intel Alder Lake N or on ARM Cortex-A7x cores are in a completely different class of performance, so they are more future-proof as they can enable the implementation of applications that were not taken into consideration in the beginning. Moreover, as pointed by the other poster, none of the Cortex-A55 SBCs implements any kind of standard, so migration to any different SBC may require significant work, unlike with the Intel/AMD SBCs, which are mostly interchangeable.
The Intel Alder Lake N/Twin Lake cores (Gracemont cores) have a performance similar to the ARM Cortex-A78 cores, which for now can be found only in few SBCs, which use Qualcomm, Mediatek or NVIDIA CPUs. The Cortex-A76 cores, which are used in Rockchip 3588 and in the latest Raspberry Pi, have a speed of only around 2/3 of the Gracemont/Cortex-A78 speed, at the same clock frequency.
Cortex-A55 cores are many times slower than any of these bigger cores. A single Intel SBC (or Cortex-A7x based SBC), can replace both Cortex-A55 SBCs of this design, at about the same cost, improving the cooling and probably lowering the power consumption, while also providing a significant performance headroom for future extensions.
While using 1 Cortex-A55 SBC for minimum cost may make sense, using 2 is a definite mistake, as they should be replaced by 1 better SBC.
I have mentioned the open-hardware Intel-based ODROID H4. The same company makes several models of ARM-based SBCs, which I would trust much more in an outdoors robot, than the choice done in the parent article, because the cooling behavior of all of them is carefully tested and reported on their site, and because it is a company that has been around for many years, demonstrating reliable hardware. Avaota provides much less information about their product than Hardkernel, i.e. they only give schematics/PCB information, without any information about power consumption, and especially about thermal behavior, which is essential in a robot application.
lorenzohess 1 days ago [-]
Looks great for a prototype. Has any modeling, simulation, or analysis been done of its off-road performance, i.e. mobility, GO/NOGO, motive efficiency, maneuverability on deformable terrain? This is critical for agricultural applications.
Has any stress analysis been done on the frame? Looks to me like it could use a couple more triangles to reinforce those rectangles.
Have you designed a skid-steering controller for it? Off-road skid steering can be quite variable obviously depending on terrain properties.
Sabrees 1 days ago [-]
Rosys (a middleware layer https://github.com/zauberzeug/rosys) has rosys.driving.Odometer and rosys.driving.Steerer it's essentially a differential drive kinematic model.
Hoping RTK dual-F9P moving-base setup (M4 in the roadmap) largely sidesteps the worst of this — NAV-RELPOSNED gives us a real heading vector independent of wheel odometry, and the robot_localisation EKF can weight RTK heavily and odometry lightly when GNSS quality is good.
The frame will almost certainly need more triangles
defrost 23 hours ago [-]
Australia's been working with various types of robotics in agriculture since 1980 at least [1], these days, for open field work there are several families of solution in developmental progress.
One leading contender is SwarmFarm Robotics, based out of Queensland.
For interest, here's a recent opinion / demonstration from an unassociated Australian farmer considering a purchase.
The farm is Tom’s Brook, a grain farm located in Esperance in Western Australia. It’s a family operated business growing a mixture of Wheat, Barley and Canola on 4500 hectares (11 200 Acres). Sizewise is pretty much bang on the average W.Australian grain acerage.
The unit pair in action here, autonomous tractor pulling intelligent boom spray, has had 10,000 acres of operation prior to this customer demonstration.
Runs at about 13 hectares per hour, max speed 10 km/hour.
Advantages of "intelligence" during operation are reduced spray usage (basic green on dirt detection, and green shape on mixed green patterns) and weather patience (happy to sit idle until wind and humidity are optimal)
70 odd Comments include feedback from other farmers already using such agribots, eg:
Just rolled over 12,000 hrs on our swarmbot. 4 years, 3000hr a year, doesn't get into the shed much.
The first 12 minutes are Vendor + Farmer discussing bot in action, remaining eight minutes is farmer and hands discussing pros and cons.
I wonder how good is the cooling of the stacked "robot brain".
It would be nice to see some temperatures in relevant points, when the computer is stress tested in the closed waterproof case and a hot ambient.
The Cortex-A55 based CPU has low power consumption, but it is not negligible and without a heatsink it may overheat and throttle.
Moreover, in a closed box, one may need some means to transfer the heat from the stacked electronics to the aluminum walls of the box. Finding suitable means may be more complex for this design, because of the curious choice of using 2 weak SBCs instead of 1 good SBC, so there are 2 sets of CPU + memories that must be cooled.
From the provided pictures, I cannot see how the electronics would be cooled well enough, especially when working outdoors during a hot day.
sgillen 1 days ago [-]
Very cool! shameless self promotion but check out greenwave-monitor[1] for the 'Diagnostics TUI'. I'll get it into the buildfarm soon.
What's your payload?
Where are the seeds?
How are they deposited?
Recommend going to a farm right now to see how this works in production. For the most part, you can autonomously sow using GPS. But the farmer just rides along.
Sabrees 1 days ago [-]
Payload is whatever you (or your startup) want it to be.
For me personally mechanical between row weeding is step one, then laser in-row weeding.
I live on a farm, I have sold salad commercially, these are largely tools I already use and own, just moved about by motors rather than muscles.
This is a smaller scale thing than arable. We're talking a step up from manual horticulture (which is actually what still feeds much of the world)
gaudystead 22 hours ago [-]
I'm not sure how much more work is currently being done on a project I'd heard about in the past, but you might be interested in seeing if you can collaborate/learn from Open Source Ecology:
Wow nice to see the website has been updated in 2025. I followed it for years but it seemed to not get much updates.
Folks might also be interested in the Precious Plastic community which has a global network of "microfactories" built around a set of open-source machines made for recycling and reusing plastics
Your discord link doesn't seem to work. One basic question: As a hardware noob, where do I start? Maybe having a minimal getting started guide could really help.
Nevertheless, the initiative looks cool!
dylan604 1 days ago [-]
From a video somewhere in the page: "The aim is to make food production more sustainable and efficient" yet requires a web app. I'd hope that you can run the server side on a local machine and not require cloud connectivity.
Sabrees 1 days ago [-]
The web app runs locally from the robot. No cloud. Once we reach autonomy (still some way away) you shouldn't have to use that much either.
Sabrees 1 days ago [-]
Quite interested in running robot<>robot and robot<>Farm comms over https://reticulum.network/ but that's a side project off a side project..
MoonWalk 1 days ago [-]
Great name, if nothing else!
Sabrees 1 days ago [-]
Thanks, bit conflicted about it TBH, it's primarily/initially a weeding robot, although I do dream of expanding it to do harvesting, and yes potentially sowing too down the line.
I sometimes help out at a hobby vineyard of 0.7 hectare; weeding in the row is a lot of manual labour. Your platform seems like a good fit. I like tinkering and robotics, what kind of price point are you aiming for?
Sabrees 1 days ago [-]
As cheap as possible, and no cheaper than that.
In my head it's £3-£5k, so by the time it's useful probably a bit more than that.
falkenstein 1 days ago [-]
a simple ride on mower with a diy inter row disc (basically just a belt and pulley with a spring) may be enough. probably just get sonebody with a tractor and inter row disc weeder to do the job for you.
TGower 1 days ago [-]
What's the plan for using an engraving laser in open air without blinding a neighbor? Does the bot fully roll over the target area before firing or something?
Sabrees 1 days ago [-]
TBC, just trying to get the platform and mechanical weeding working for now
rrr_oh_man 1 days ago [-]
A joke that's whooshing over my head?
Sabrees 1 days ago [-]
A robot that Sows seeds..
rrr_oh_man 1 days ago [-]
Aaaaaargh.
(╯°□°)╯︵ ┻━┻
Thank you.
dheera 1 days ago [-]
I highly encourage you to go visit farms sooner rather than later, especially during the rainy seasons and winter when farmers are really at work preparing for the next season. The kind of conditions robots need to deal with in that environment is no joke.
I also notice you're using the BNO055 -- if you need an C++ I2C ROS driver for it I wrote one (https://github.com/dheera/ros-imu-bno055). I think the one in the ROS apt-get repository is written in Python but they claimed the package name before I did
Sabrees 1 days ago [-]
Good advice on farms. I do live on a farm, so somewhat familiar with mud! Many of the worst problems are caused by moving 20ton tractors around IMHO, one of the problems small scale ag robotics may help with.
Will check out your Bno055 currently using the upstream one in Lizard
I'd be pleasantly surprised if DJI had done anything open source, Ardupilot is pretty capable of course. I really want to automate the time consuming labour parts of horticulture, for me that's mostly weeding and to a lesser extent harvesting.
abraae 1 days ago [-]
This is the future, good luck to you
umairnadeem123 17 hours ago [-]
[dead]
pixelsub 1 days ago [-]
[dead]
Rendered at 22:54:30 GMT+0000 (Coordinated Universal Time) with Vercel.
I will preface this by saying that I have nothing against ARM per se, that my employer/team supported a good chunk of the work for making ROS 2 actually work on arm64, and that there is some good hardware out there.
I really don't understand why startups and research projects keep using weird ARM SBCs for their robots. The best of these SBCs is still vastly shittier in terms of software support and stability than any random Chinese Intel ADL-N box. The only reasons to use (weird) ARM SBCs in robots are that either (1) you are using a Jetson for Jetson things (i.e. Nvidia libraries), or (2) you have a product which requires serious cost optimization to be produced at a large scale. Otherwise you are just committing yourselves and your users/customers to a future of terrible-to-nonexistent support and adding significantly to the amount of work you need to bring up the new system and port existing tools to it.
Obviously, anyone can have there own opinion on this. I work in robotics, we are quite happy with our A53 and M4. Though, we use a SOM, not a SBC, if you feel like splitting hairs.
But generally projects which are choosing some random SBC aren't using any of these features, and are just suffering the pain/imposing it on their users for no good reason.
you've ruled out the entire NXP ecosystem, the entire Nvidia Jetson ecosystem, the entire AMD/FPGA/Zynq ecosystem, even perfectly good options like beagle-board .... who else?
incidentally, you've also ruled out this project - as they are using an M7 microcontroller to meet their hard-real-time timing constraints...
Some things are best done with a microcontroller, and those are not suitable for being done with a general-purpose CPU either based on Intel/AMD or on Cortex-A cores. Actually there are many projects that mistakenly use something like a Raspberry Pi instead of a better and cheaper implementation with a microcontroller, e.g. one based on Cortex-M7 or its successor, Cortex-M85.
The other poster said that where you do not want a microcontroller, but you want to run a standard operating system, e.g. Linux, then the best choice is much more frequently a SBC with an Intel Alder Lake N or Twin Lake CPU, as these not only have a better performance per dollar than the ARM-based SBCs, but they also avoid any software problems and future maintainability problems.
Unfortunately, during the last few months the price of Intel-based SBCs has been affected by the fact that most of them do not have soldered memory but they use one SODIMM memory module. While you can buy an Intel Alder Lake N based SBC for $100, buying today a SODIMM for it may cost as much or more, depending on the amount of memory with which you are content.
The ARM SBCs that come with soldered LPDDR memory have initially been less affected by the price hikes, though now even for them the prices are rising.
There are also a (much smaller) number of projects that will legitimately see the kind of scale of production that justifies aggressive cost optimization for the compute platform, either in terms of designing their own around a SoC or picking some SBC/SoM that they can get a good deal on, where the significant additional up-front engineering cost is outweighed by the production savings (and where the desire/need to keep a fixed platform means the often limited platform support from the vendor is less restrictive).
But a large number of robotics projects (basically everything in the research sphere) - this one very much included - just need "some computer" for general-purpose use. They are already separating realtime control onto a separate microcontroller board. For these projects, it is almost always committing a "premature pessimization" of picking some weird SBC. You are signing up for worse CPU and GPU performance, stability, and development future for very little reward.
Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)
> Part of the point of this for me is to see what's possible with open hardware (down to chip level at least)
I appreciate the idea, but this is essentially saying "this project will prioritize a specific choice of one (core) piece of hardware to the detriment of everything else, users included". Approximately none of your potential users are going to benefit from the "openness" of the SBC versus that of a more broadly-supported platform (I say "openness" because the reality of SBCs is that actually finding a usefully performant one that is completely blob-free is almost impossible). Open hardware means very little if it isn't running an upstream kernel and userland.
The Mainline kernel for this particular board is _almost_ there 6.20 or so I expect. Armbian support is good.
https://github.com/FrameworkComputer/Framework-Laptop-13/tre...
In a few years we'll all be using more open RISCV stuff of course.
You get their schematics/PCB documentation and their BIOS has features that are missing in most mini-PCs and laptops with Alder Lake N/Twin Lake, e.g. you can enable in-band ECC for the memory. You can choose various variants of the SBC and you can buy cheaply various accessories, e.g. several case variants and additional peripheral interfaces. Those ODROID H4 SBCs are also correctly designed for cooling inside a box like that used in this project, because the PCB is attached to a big heatsink and you can attach the heatsink directly to an aluminum wall from inside the box, ensuring good thermal contact with pads or grease, so that the electronics will be cooled well.
Most technical information can be found in their Korean site, but there is a UK distributor (though the prices appear greatly inflated here; so much that it might be cheaper to buy from South Korea, depending on shipping costs and applicable taxes):
https://www.odroid.co.uk/
Also the Chinese Radxa has a Raspberry Pi sized SBC with an Intel N100, which is open hardware, with complete schematics/PCB documentation (but unlike ODROID H4, which has excellent cooling and it can be used without a fan, it is unclear how easy is to cool the Radxa SBC).
Moreover, unlike for many Intel/AMD CPUs, which no longer have public documentation, for Alder Lake N Intel still provides public datasheets, which contain e.g. the thousands of control registers for the on-chip peripherals. Most ARM Cortex-A based CPUs are undocumented, with few exceptions like Rockchip RK3588 and the very expensive NVDIA Orin/Thor (or the obsolete Xavier). All Cortex-A based CPUs have secret boot loaders, so you can never be certain that your programs really run on bare metal, as the CPU vendor can implement the equivalent of the Intel System Management Mode, where the proprietary vendor firmware can take control from your own operating system whenever it wants.
There are somewhat more ARM-based SBCs than Intel-based SBCs that are open hardware, but there are also plenty of undocumented ARM SBCs that are much worse from this PoV than the Intel/AMD based computers, where at least the IBM PC standards and the later standards pushed by Intel, e.g. ACPI/UEFI, apply. The Allwinner CPU used in this robot has almost non-existent documentation, in comparison with Intel Alder Lake N, so it is much farther from "open hardware".
You have mentioned the NVIDIA Jetson modules, which are based on Thor/Orin/Xavier. Those have excellent documentation, but you have to register at NVIDIA, for a free account, in order to access it. The documentation is not the problem with them, but the fact that they are greatly overpriced, like almost anything made by NVIDIA. Unless your application critically depends on some feature provided by NVIDIA, for which no acceptable alternatives exist, choosing Jetson is a very bad decision, because the alternatives are usually both better and cheaper.
The SBCs based on Cortex-A55 are the cheapest for the purpose of running Linux that still have a decent performance and they may be sufficient for many applications.
However, the SBCs based on either Intel Alder Lake N or on ARM Cortex-A7x cores are in a completely different class of performance, so they are more future-proof as they can enable the implementation of applications that were not taken into consideration in the beginning. Moreover, as pointed by the other poster, none of the Cortex-A55 SBCs implements any kind of standard, so migration to any different SBC may require significant work, unlike with the Intel/AMD SBCs, which are mostly interchangeable.
The Intel Alder Lake N/Twin Lake cores (Gracemont cores) have a performance similar to the ARM Cortex-A78 cores, which for now can be found only in few SBCs, which use Qualcomm, Mediatek or NVIDIA CPUs. The Cortex-A76 cores, which are used in Rockchip 3588 and in the latest Raspberry Pi, have a speed of only around 2/3 of the Gracemont/Cortex-A78 speed, at the same clock frequency.
Cortex-A55 cores are many times slower than any of these bigger cores. A single Intel SBC (or Cortex-A7x based SBC), can replace both Cortex-A55 SBCs of this design, at about the same cost, improving the cooling and probably lowering the power consumption, while also providing a significant performance headroom for future extensions.
While using 1 Cortex-A55 SBC for minimum cost may make sense, using 2 is a definite mistake, as they should be replaced by 1 better SBC.
I have mentioned the open-hardware Intel-based ODROID H4. The same company makes several models of ARM-based SBCs, which I would trust much more in an outdoors robot, than the choice done in the parent article, because the cooling behavior of all of them is carefully tested and reported on their site, and because it is a company that has been around for many years, demonstrating reliable hardware. Avaota provides much less information about their product than Hardkernel, i.e. they only give schematics/PCB information, without any information about power consumption, and especially about thermal behavior, which is essential in a robot application.
Has any stress analysis been done on the frame? Looks to me like it could use a couple more triangles to reinforce those rectangles.
Have you designed a skid-steering controller for it? Off-road skid steering can be quite variable obviously depending on terrain properties.
Hoping RTK dual-F9P moving-base setup (M4 in the roadmap) largely sidesteps the worst of this — NAV-RELPOSNED gives us a real heading vector independent of wheel odometry, and the robot_localisation EKF can weight RTK heavily and odometry lightly when GNSS quality is good.
The frame will almost certainly need more triangles
One leading contender is SwarmFarm Robotics, based out of Queensland.
* https://advance.qld.gov.au/innovation-in-queensland/innovati...
* https://www.swarmfarm.com/
For interest, here's a recent opinion / demonstration from an unassociated Australian farmer considering a purchase.
The farm is Tom’s Brook, a grain farm located in Esperance in Western Australia. It’s a family operated business growing a mixture of Wheat, Barley and Canola on 4500 hectares (11 200 Acres). Sizewise is pretty much bang on the average W.Australian grain acerage.
Seeing a Swarm Bot in Action (20 min) - https://www.youtube.com/watch?v=ljEKN7CsjnM
The unit pair in action here, autonomous tractor pulling intelligent boom spray, has had 10,000 acres of operation prior to this customer demonstration.
Unloaded weight ~ 3.5 metric tonne, loaded approx 5 tonne.
Runs at about 13 hectares per hour, max speed 10 km/hour.
Advantages of "intelligence" during operation are reduced spray usage (basic green on dirt detection, and green shape on mixed green patterns) and weather patience (happy to sit idle until wind and humidity are optimal)
70 odd Comments include feedback from other farmers already using such agribots, eg:
The first 12 minutes are Vendor + Farmer discussing bot in action, remaining eight minutes is farmer and hands discussing pros and cons.--
[1] Robot Sheep Shearing (1985) https://www.youtube.com/watch?v=6ZAh2zv7TMM
It would be nice to see some temperatures in relevant points, when the computer is stress tested in the closed waterproof case and a hot ambient.
The Cortex-A55 based CPU has low power consumption, but it is not negligible and without a heatsink it may overheat and throttle.
Moreover, in a closed box, one may need some means to transfer the heat from the stacked electronics to the aluminum walls of the box. Finding suitable means may be more complex for this design, because of the curious choice of using 2 weak SBCs instead of 1 good SBC, so there are 2 sets of CPU + memories that must be cooled.
From the provided pictures, I cannot see how the electronics would be cooled well enough, especially when working outdoors during a hot day.
[1] https://github.com/NVIDIA-ISAAC-ROS/greenwave_monitor
Recommend going to a farm right now to see how this works in production. For the most part, you can autonomously sow using GPS. But the farmer just rides along.
For me personally mechanical between row weeding is step one, then laser in-row weeding.
1. These on some linear actuators: https://www.getearthquake.com/products/fusion-drill-powered-... (they work surprisingly well)
2. Beyond that for in-row weeding a engraving laser on a Delta: https://github.com/Agroecology-Lab/Open-Weeding-Delta/tree/m...
Or if I'm feeling rich by then this third party weeder looks pretty good https://github.com/Laudando-Associates-LLC/LASER
3. For Seeding my salad crop https://reagtools.co.uk/collections/jang
4. Harvesting my salad crop https://reagtools.co.uk/products/quick-cut-greens-harvester
I live on a farm, I have sold salad commercially, these are largely tools I already use and own, just moved about by motors rather than muscles.
This is a smaller scale thing than arable. We're talking a step up from manual horticulture (which is actually what still feeds much of the world)
https://www.opensourceecology.org/
Folks might also be interested in the Precious Plastic community which has a global network of "microfactories" built around a set of open-source machines made for recycling and reusing plastics
https://www.preciousplastic.com/
https://community.preciousplastic.com/map
Also as far as fundamental machines go, this 2d printer is expected to come out later this year
https://www.opentools.studio/
Nevertheless, the initiative looks cool!
Strapping something like the Jang P6 to it is probably feasible https://reagtools.co.uk/collections/jang
For the harvester it would be a bolt on for https://reagtools.co.uk/products/quick-cut-greens-harvester or maybe https://reagtools.co.uk/products/babyleaf-harvester-80cm (I grow green salads)
Beyond that for in-row weeding a engraving laser on a Delta: https://github.com/Agroecology-Lab/Open-Weeding-Delta/tree/m...
Or if I'm feeling rich by then this third party weeder looks pretty good https://github.com/Laudando-Associates-LLC/LASER
In my head it's £3-£5k, so by the time it's useful probably a bit more than that.
(╯°□°)╯︵ ┻━┻
Thank you.
I also notice you're using the BNO055 -- if you need an C++ I2C ROS driver for it I wrote one (https://github.com/dheera/ros-imu-bno055). I think the one in the ROS apt-get repository is written in Python but they claimed the package name before I did
Will check out your Bno055 currently using the upstream one in Lizard
https://github.com/zauberzeug/lizard/blob/main/main/modules/... https://github.com/zauberzeug/lizard/blob/main/main/modules/...
Any review of that welcome too of course.
or some automated green house with open source designs.
love the name sowbot.
I did sketch out a slightly more 'professionalised' version, but haven't built it yet https://github.com/samuk/IoT-Greenhouse-Temperature-and-Irri...
I'd be pleasantly surprised if DJI had done anything open source, Ardupilot is pretty capable of course. I really want to automate the time consuming labour parts of horticulture, for me that's mostly weeding and to a lesser extent harvesting.