-
You Reply: Hi aklepo2
I noticed a similar behavior with my setting as well. Specifically, two algorithms face recog and one of the object recogs draw a lot of power. If the Husky is powered by a single source, eg the serial port connection via the microcontroller, depending on the situation, it does reboot!
I eliminated my problem by powering the Husky via its USB port using a power brick at 5V and plenty of mAh. No problems at all any more!
Hope it helps.
-
You Reply: Hi cep96,
A quick check of the two programs you have mentioned indicates speed differences in the Serial interface:
- ASCIITable example is set to run the Serial port at 9600 baud in line 24: Serial.begin(9600);
- Get_Started example is set to run the Serial port at 115200 baud in line 31: Serial.begin(115200);
If, as you mentioned, you ran both without any changes, then most likely the Serial Monitor speed settings are not set correctly. Try setting them to the same speed and see if it is any better.
-
You Reply: Hi,
I noticed the proportional font use during my testing. I also counted 30 y-pixels after a bunch of tests, vertically. X position ending point is impossible without a lot of experimenting. While you say that the font size is 18 pixels, anything displayed comes with a black background frame around it. The size of that is 30 pixels high, varying in x direction.
Here is my suggestion:
Instead of just returning the OK code, return the x and y displacement af the end of the text block displayed (the black box). This will allow the user to immediately concatenate more text at the proper place on the screen: same line or next line.
-
You Reply: - learn 3 new objects and instead of default IDs have my own custom IDs instead.
You can do this manually by pushing buttons on the unit, or programmatically by using the command
-
You Reply: Looking forward to be able to integrate models from:
eg: Teachable Machine: https://teachablemachine.withgoogle.com/
-
You Reply: The issue is NOT whether the codes work fine or not !
1. Same remote controller used in MakeCode and MIND+ produce different IR codes.
Since the library is by DFROBOT, I am asking why there is a difference.
2. In MakeCode, an IR code for button "1" produces code 122. However, when this code is used in the program IF statement, one must code: "IF message = 22" instead of 122. Why ?
3. In MIND+, IR codes are 3 digits, and the IF statements also use 3 digits. Why the difference from MakeCode?
Below are two programs, one for each IDE. Try it before guaranteeing the codes work OK !
MAKECODE:
Code: Select all/**
* Even though the IR message received has the codes 122 and 190 for number 1 and 9 respectively, the IF comparisons have to be for 22 and 90 for it to work!
*
* Checking for 122 and 190 does NOT work.
*/
maqueen.IR_callbackUser(function (message) {
serial.writeLine("" + message)
if (message == 22) {
basic.showString("1")
}
if (message == 90) {
basic.showString("9")
}
})
serial.redirectToUSB()
serial.writeLine("Port ready")
MIND+:
Code: Select all/**
* IR message received has the codes 151 and 165 for number 1 and 9 respectively. The IF comparisons have to be for 151 and 165, NOT LIKE THE MakeCode!
*/
#include <DFRobot_IRremote_dal.h>
DFROBOT_IRremote_Receive remote(16);
void onIRReceive(uint8_t data_IR)
{
Serial.println(data_IR);
if ((data_IR == 151)) {
Serial.println("1");
}
if ((data_IR == 165)) {
Serial.println("9");
}
}
void setup() {
Serial.begin(9600);
Serial.println("PORT Ready");
remote.begin();
remote.setCallback(onIRReceive);
}
void loop() {
}
-
You Reply: Code below is what I used. It'll display the Serial Data back to the Serial Window to demonstrate the issue.
Simply select a Line Termination option, eg: LINE FEED and SEND a character, eg:A.
ASCII 65 followed by 10 will be sent.
Then select NO LINE TERMINATION and SEND again.
Previous terminators will be sent out again, instead of NONE.
Code: Select all#include <Microbit_Matrix.h>
double mind_n_df_SerData;
void setup() {
Serial.begin(115200);
Serial.println("PORT Ready @ 115200...");
}
void loop() {
while (!(Serial.available())) {
}
mind_n_df_SerData = Serial.read();
MMatrix.print(mind_n_df_SerData);
Serial.println(mind_n_df_SerData);
}

-
You Reply: OK. That has temporarily solved the problem!
However, since MIND+ is SCRATCH3 based and there is such problem in S3, you guys have injected a problem into the language switching portion of the code. Would it not be better for you to fix the problem than make the user go through language selection acrobatics to make your code initialize properly ?
-
You Reply: Hi Ghica,
I am not in DFRobot Team or anything, but I wanted to provide this as an option to your problem:
BLE on micro:bit indeed does take a lot of space for what little it provides. One can easily do without it buy using a normal HC05/06 type bluetooth card.
Since you are already indicating that you would like to do away with the IR sensor, meaning you can reuse those pins, as well as the UltraSonic sensor pins (if you do not need them) for the TX/RX pins that will be needed for BT IO.
Using the HC05 type BT card, one does not need BLE extension and simply can use the Serial IO to exchange bluetooth messages and commands.
Hope this helps with your project and demonstration.
-
You Reply: @ BOTTIN Michael
I am after the same i2c address info to make use of the Maqueen in a different coding environment. I do not understand why the i2c address is being kept a secret. I can understand the schematics being proprietary.
Here is what I have done: I pinged the board with 0-127 i2c address range trying to read the registers. I got responses from address 25 and 30 (decimal). These are not the 0x10 (16) that is used in the code of i2c driver code on gitHub. However, I was not able to establish comms with the i2c as well.
DFRobot should disclose their 2c address and register use, so those who want can code their own version of the motor controls. Not everyone is interested in being locked down to block coding only. And this will also open up the kit for more advanced uses.
-
You Reply: @elloco999
While the Maqueen does not have any sensors to enable exact 90/180/360 turns, the micro:bit you are using to drive it does have a COMPASS capability, that will provide some level of support. It will not be the exact 90/180/360 precision that you are looking for, but it might help alleviate the problem.
micro:bit COMPASS returns a reading of 0-359 degrees, 0 being North, and in a clockwise rotation.
If you use this reading value and manipulate it a bit with the MATH functions, you can arrive at an approximation of the four cardinal direction. Here is a code sample is JS to do that:
Code: Select allwhile (true) {
compRead = input.compassHeading()
dir = Math.round(Math.map(compRead, 0, 359, 1, 4))
basic.showNumber(dir)
basic.pause(100)
}
Paramaters "1,4" indicate the number of direction points you want: N/E/S/W
You could change that to "1,8" and obtain in-between directions, if you want: meaning the 45 deg turn points.
If you copy and paste the JS code into the JS programming mode, and then switch to the Block programming mode, you 'll get the corresponding blocks.
The example displays the direction calculated on the LED screen. However you can take the DIR variable and do whatever you want with it.
Hope this will help you a bit. -
You Reply: @dawsonseibold
You are not alone with that problem. I had a similar experience using the Maqueen Kit. It worked for a few weeks and then one of the sensors started giving erroneous readings, making the line following impossible.
While the kit quality is pretty good, its pre-built structure makes replacing simple parts like the IR sensor impossible. I guess that is the price to pay for a quick to use kit that cannot be modified.
-
You Reply: @leftenan_ika
While you wait for DFRobot to "check on things!", here is some information that I hope will be useful:
In order to determine a T junction direction resolution, one needs at least three, ultimately 5 Sensors:
- 3 Sensor model:
- one in the middle to sense the road
- one to the left to detect LEFT branches
- and one to the right to detect the RIGHT branches
5 Sensor Model:
- one in the middle to sense the road, positioned slightly behind the other four
- two to the left and two to the right for detecting road deviations and turns
Take a look at these pictures to understand what the issue is:
3 Sensor Model:

5 Sensor Model:

As such, it is impossible to code to T junction decisions with the standard Maqueen kit. It only has two IR sensors meant for following a path, and detecting deviations from it.
You need to locate a more advanced model that has the additional sensors. -
You Reply: Two weeks and no reply !!!!
-
You Reply: two weeks and no reply at all !!!!!
-
You Reply: COMPASS works OK when micro:bit is used alone.
However I am using the micro:bit as mounted on your DFROBOT Maqueen Car.
There, maybe because of the orientation of the micro:bit, the Compass readings are way off.