Hi all, I’m Alfred, an embedded systems student at FUT Minna, Nigeria. I built this companion controller prototype during my internship at LET Innovations. It’s an Arduino Mega 2560 in C++ that does current monitoring (INA219 over I2C), ultrasonic proximity sensing with a buzzer alarm, and a servo payload release. I simulated it in Proteus and modelled the airframe in 3D. [Add here if it’s been tested on real hardware, or say it’s simulation-only so far.]
Repo: GitHub - alfredoeinsteino2024/drone-companion-controller: An Arduino Mega 2560-based drone companion controller and payload release subsystem featuring real-time INA219 current telemetry, HC-SR04 proximity sensing, and automated emergency alert patterns simulated in Proteus VSM. · GitHub
Feedback I’d value: a better payload-release trigger than a current threshold, converting the blocking delays to non-blocking timing, and what to test before moving from simulation to hardware.
I’m now looking for a paid internship or junior firmware/embedded role (remote). If you know teams that take student contributors, I’d appreciate a pointer.
The non-blocking timing question is the one I’d tackle first, since the INA219 sampling and buzzer patterns will fight each other once you drop delay() calls; a simple millis()-based scheduler per subsystem usually covers it. For payload release, a current threshold is fragile because load varies with charge state and temperature, so consider a microswitch or optical sensor confirming the payload actually left. Before real hardware, I’d bench-test each module separately, check your I2C pull-ups and shared 5V rail under servo stall current, and verify the ultrasonic readings aren’t corrupted by motor noise.
The point about the shared 5V rail under servo stall current is worth emphasizing—the Mega’s onboard regulator can’t supply that reliably, so a separate buck converter for the servo and a common ground would be safer. On the payload trigger, a microswitch also gives you a definitive state for logging rather than an inferred one. For the millis() scheduler, start with one timestamp per subsystem and a small state enum for the buzzer pattern; that structure scales better than chained if/else checks. Bench-testing the ultrasonic sensor with the motors running is probably the most revealing test before powering the airframe.
The point about the servo stall current on the shared 5V rail is worth stressing: on a Mega the onboard regulator won’t cope, so bench-test with a separate supply before trusting any INA219 readings. For the payload trigger, a microswitch confirming release is more robust than current sensing, but you could also use it to gate your buzzer patterns via the millis() scheduler. For the ultrasonic noise, try averaging a few samples and discarding outliers rather than single reads.