I agree, cubsats are a wonderful way, for college students even, to tinker with space(-adjacent) tech.
I have used CubeSats in LEO to make amateur radio contacts. AMSAT is trying to get one to MEO/HEO. New cubesats are being released frequently. Not all RPi based and usually custom PCBs. You can buy desk based CubeSats for STEM
Use LoRa in the slowest and most reliable mode as radio link. Write software to plan your tours, firmware updates over super limited bandwidth (delta updates are a must), transfer telemetry (buy a few sensors from ali) or even pictures. Autonomous driving? Yes why not.
Bonus 1: build a small PCB with a solar panel and charging circuit. That doubles the horror.
Bonus 2: Place it into your families garden that is at least 1km away.
Lots of very hard challenges to tackle for even super experienced programmers.
It's even a nice group project for an university lab. If you have to connect a real debugger to get your bot running again your team lost.
vodou•1h ago
jdiez17•1h ago
vodou•43m ago
jdiez17•32m ago
Resets etc. are common, most likely caused by software bugs. This is more or less assumed as a fact of life; software for space applications is often as stateless as possible, and when it’s required you’d implement frequent state checkpoints, redundant data storage, etc. These are all common practices that you’d do anyway, it doesn’t make a huge difference if the software is running on a rad-hard microcontroller or off the shelf Linux processor - although (IMO) there are many benefits to the latter (and some downsides as well.) Assuming a base level of reliability, of course - you don’t want your OBC/PDH to overheat or reboot every 5 minutes.
Sanzig•37m ago
Yes, a Raspberry Pi isn't radiation hardened, but in LEO (say around 400-500 km) the radiation environment isn't that severe. Total ionizing dose is not a problem. High energy particles causing single event effects are an issue, but these can be addressed with design mitigations: a window watchdog timer to reset the Pi, multiple copies of flight software on different flash ICs to switch between if one copy is corrupted, latchup detection circuits, etc. None of these mitigations require expensive space qualified hardware to reasonably address.
The usual issues I see in academic CubeSats are mostly programmatic. These things are usually built by students, and generally speaking a CubeSat project is just a bit too long (3-4 years design and build + 1-2 years operations) to have good continuity of personnel, you usually have nobody left at the end there since the beginning except the principal investigator and maybe a couple PhD students.
And since everyone is very green (for many students, this is their first serious multidisciplinary development effort) people are bound to make mistakes. Now, that's a good thing, the whole point is learning. The problem is that extensive testing is usually neglected on academic CubeSats, either because of time pressure to meet a launch date or the team simply doesn't know how to test effectively. So, they'll launch it, and it'll be DOA on orbit since nobody did a fully integrated test campaign.
NoiseBert69•20m ago
It's all about the learning experience and evolution of these projects. Mistakes must happen.. but learning from them should take place too.
verzali•2m ago