Comments: micro:bot Kit Experiment Guide
Looking for answers to technical questions?
We welcome your comments and suggestions below. However, if you are looking for solutions to technical questions please see our Technical Assistance page.
If you've found an issue with this tutorial content, please send us your feedback!
From the Technical Assistance pages:
There is also one other possibility - that your USB => micro-USB cable may not be an actual DATA cable.
If you have a phone charger cable that plugs into a USB jack for power, it may not have all four/five wires attached!
What you will see is the micro:bit light up and appear to be working, but it does not actually appear on your system. If this is the case, swap out the USB cable with one you absolutely KNOW is a data-cable, like from a USB optical media device.
Is there a micro:bot library for micropython?
I don't think so, that might be a fun project, though. ;) I'm sure there's plenty of potential cross pollination with Adafruit projects and CircuitPython, and I assume projects coming from Great Britain and the BBC. I, for one, am going to look around, or, if short on time, buy a RedBot board, which is, after all, what I would expect SparkFun to concentrate their efforts on. They are not really a software company, after all, and it would be a bit counterproductive to work on micro:bit while they are distributing RedBot kits.
Member #1272652 said:
Well. . . . .
They do sell the micro:bit and a number of interesting add-ons for it, so maybe this isn't so far fetched after all?
Another thought: Most of their stuff is covered by a Creative Commons-type license, so it might be possible to get source code from their GitHub repo, (if they have one), do something creative and create a pull request.
I'm already researching how to do that for the moto:bit extensions for MakeCode, since they are so abysmal at present.
I believe the moto:bit uses the same chip as the Qwiic motor driver, which has a Python pacakge. Unfortunately, it isn't a circuitpython or micropython package. I haven't messed around with the micro:bit enough to know if it would work, since it hasn't been optimized for microcontrollers, but let us know if it works.
I'm not a python programmer, (yet!), so I might be talking nonsense here, but is it necessary? Aren't you able to control the micro:bit with the python libraries that already exist for the micro:bit? If that is true, can't you control the micro:bot board in the same way?
My apologies if I am not understanding something here.
Jim "JR"
I just received my Micro:bot Kit 12 February 2021 V2.0. I followed instruction for putting the kit together. I made sure the motor wires were as shown in the instructions. Today, the program compiled! Thank you! However, I reduced the motor example in the guide to just one task: move "left" motor. motor "forward" move "right" motor. motor "forward" the Result is: left motor wheel goes forward and the Right motor goes in reverse. The simple answer is to switch the red and black power wires from the Right motor the opposite from the instruction. But, I was wondering if something else might be wrong or maybe when preparing "makecode" Micro:bit V2 for compliance, something inadvertently got changed? Thank you
Suggestion: Because the robot kit is called the "micro:bot" there should be a link to the extensions called "micro:bot" At the very least there should be an alias linking "micro:bot" to "moto:bit".
Why?
I suspect that many people will remember that the robot is named the "micro:bot" - less will remember that the extension is named after a specific circuit board. At least I get confused every time I try to use the robot with Make Code and have to look it up.
An additional point, the vast majority of robot kits (that result in a moving, active robot) - as opposed to robot boards, (that can be made into robotic devices with the addition of additional parts) - are named after the kit instead of the circuit board.
Since you sell both - the board and the kit, maybe it should be listed under both names?
What say ye?
Jim "JR"
makecode library search yields no motor-bit
The full and proper name is "moto:bit"
Type in "moto" and click on the magnifying glass on the right-hand side of the search box. It's like the third or fourth extension returned.
I bought four of these for a kid's robotics class; I've put one together to get started, and am unable to get the motors running.
The stop/run motors switch is functional (continuity check), the batteries are fresh, the micro:bit works. Even when I put a motors on/run for a bit, motors off in a start block, no joy. It's not clear to me how to debug this (new to micro:bit, not new to embedded systems and robotics).
Any clues?
If you are using the example in Experiment 1 of this kit, the motors should run after pressing the button A on the micro:bit due to the condition statement. If you have not already, try checking in with our technical assistance team.
any examples with the i2c port?
We're having the issue, don't seem to be getting power from the batteries to the moto:bit. When plugged into our Mac and press the A button on the test script, it just makes a faint beep, no motor movement.
Attaching batteries directly to the motors proved they are working but not via the moto:bit and the micro:bit isn't getting power via batteries either, only works when USB'd to Mac. Help?
Hi there, it sounds like you are looking for technical assistance. Please use the link in the banner above, to get started with posting a topic in our forums. Our technical support team will do their best to assist you.
I just noticed this comment when updating the tutorial, there are some packages made for certain I2C sensors. Check out the latest tutorials tagged with micro:bit. The gator:UV, gator:RTC, gator:environment, and gator:particle are I2C sensors that can be used with makeCode.
Nice!
One more thing. It would help if the comments only appeared on the experiment page they are referring to.
Wait, what? First the experiment is supposed to be about using the accelerometer to detect a bump, then it's about speeding up when going up a hill, then it turns out the actual code just detects a tap on the robot to start it moving. I think this experiment needs a rewrite.