Since the pixels should light up when the acceleration is above or below the threshold, then shouldn’t the handle_feedback_function use acceleration data instead of gyro data. We tried the code the way it is and the drone does not light up appropriately. Here is our changed code which makes the drone do the appropriate thing.
def handle_attitude_feedback():
accel_x, accel_y, accel_z = get_data(ACCEL)
# Reset pixels each cycle
pixels.off()
# Provide visual feedback based on the direction of the roll
Great question! You’re absolutely right that the Dip Detector should be using accelerometer (ACCEL) data to detect tilt — and looking at your code, you’ve got the right idea!
It sounds like you may have started from the previous objective’s code (“Charting Your Attitude”), which uses GYRO data for charting roll rate. The Dip Detector objective transitions to using ACCEL instead, since the accelerometer directly measures the direction of gravity and gives you a clean tilt reading.
The starter code for the Dip Detector objective in the CodeTrek should already have get_data(ACCEL, wait=False) in balance_monitor_task, and it passes that data into handle_attitude_feedback(sensor_data) as a parameter. So the intended pattern looks like:
def handle_attitude_feedback(data):
accel_x, accel_y, accel_z = data
pixels.off()
if accel_y > TILT_THRESHOLD:
for i in RIGHT_PIXELS:
pixels.set(i, RED)
elif accel_y < -TILT_THRESHOLD:
for i in LEFT_PIXELS:
pixels.set(i, RED)
def balance_monitor_task():
sensor_data = get_data(ACCEL, wait=False)
if sensor_data:
handle_attitude_feedback(sensor_data)
Notice the function takes a data parameter — balance_monitor_task reads the ACCEL data and hands it off to handle_attitude_feedback. This is the “separation of concerns” pattern the lesson talks about: one function gathers data, the other acts on it.
Your version works too since you’re reading ACCEL directly inside the handler — the end result is the same! Just a slightly different structure than the lesson intended.
If you got to this point by building on the previous objective’s code rather than the CodeTrek starter, that might explain the GYRO mix-up. Try clicking the CodeTrek steps for this objective to see the intended starting code.
Thanks for sharing that screenshot! That’s really helpful for understanding what you’re seeing.
That’s interesting — the starter code in the lesson content repository for the Dip Detector objective does use ACCEL, not GYRO. So there might be something going on with how the code is displaying on your end, or it could be a deployment sync issue.
A couple of things that might explain it:
If you built on your code from the previous objective (“Charting Your Attitude”), that one does use GYRO — so the GYRO reference could have carried over from there
It’s also possible there’s a caching issue in CodeSpace showing you stale starter code
Either way, you’re absolutely right that the Dip Detector should use ACCEL data — so your instinct to change it was spot on. Nice work catching that!
I’m tagging the team so they can take a look at the screenshot and investigate whether there’s a display or sync issue on the CodeSpace side.
