This isn’t directly Ardupilot related but I thought people here would have good experience and ideas related to interfaces for controlling pretty much anything that moves Currently, I’m controlling a 2-wheel robot with a super simple web-based interface that I can access via my phone - I just move my finger around on a gray square to control the two separate motors. However, the experience isn’t great.
So if my finger is in the upper left then the left motor is full forward etc. The code behind this is very simple but it’s actually not a great way to control the robot. So I’m looking for alternative ideas and suggestions?
The main issue is that it tends to spin around wildly - like a cheap remote control toy. You’re going full left one second and then you’re spinning full right when all you really wanted to do was correct the left spin and move forward.
A fix for this I guess would be to introduce some kind of expo element to moving left and right, i.e. movements near the center wouldn’t result in such dramatic changes as currently.
But maybe there are altogether better alternative designs for controlling the robot? Maybe a good source of ideas would be the controls used in racing games on phones.
So if you’ve got any cool ideas or simple tweaks that would improve the driving experience I’d really appreciate your input.
Thanks By the way, this is the kind of robot I’m controlling:
Thanks for the followup @ppoirier. The robot that I have is indeed a Pololu Romi. And I’m using their server.py interface.
I’d already seen DrGFreeman’s python library for autonomous driving functionality (line following etc.).
I wasn’t really looking for pointers to existing code. I just thought that with a little work one could do better than the simple web UI that Pololu provide for the Romi (which works great as an easy to understand starting point).
So I was just looking for ideas for a better interface design - I’m happy to do the implementation myself. E.g. one could use device orientation detection for left and right, i.e. hold the phone with both hands in landscape orientation and tilt it left and right while using one or other thumb to control acceleration/reverse.
It was suggestions on the high level human interaction that I was hoping for or suggestions (like introducing expo) that might improve the user experience.
@ppoirier - I thought about your answer a bit more. Sorry, if I misunderstood and that what you were driving at was that I can’t really hope to achieve good control, irrespective of the user interface involved (sticks on a TX or UI elements on a smartphone touchscreen), unless I first introduce closed loop motor control? I’m new to this area and just getting to grips with everything that’s involved.
This recent ArduRover related blog entry looks like it might be a great starting point for investigating more sophisticated control (although the described setup, while using ArduRover, does not use encoders).
If you are looking for a ‘‘brain’’ transplant, the use of an appropriate Flight Controler could be an option.
There is still a lot of development in this branch and any contribution is welcome.
I’m actually planning to put encoders on it in the next few weeks. The current flight controller I’m using (Kakute F4) doesn’t have enough pins for the encoder inputs, so I’ll be changing out the controller for a Pixhawk.
@ppoirier - thanks for the link I have a tendency to go down rabbit holes - the flight controller “brain” transplant looks like a fun rabbit hole but it’s probably too much for my current project, so your link is exactly what I should be looking at.
@stephendade - I was just about to ask if you’d looked at adding encoders, but you beat me to it In your blog post, you say one needs “4 spare AUX ports” for this. Why four? In the Romi user guide in the section on quadrature encoders they need just 4 pins (only 2 of which need to be interrupt capable) for the two encoders.
Is it that you can only use the RX line on each UART for input? Is it impossible to use the TX lines as GPIO input lines? If I’m reading the F4 datasheet correctly (which I’m probably not) then all the UART pins can be used as plain GPIO pins.
I see that the Kakute F7 has more UARTs. Is this enough? If so I’m happy to sponsor purchasing one for your development - I’d be very interested in seeing work done in this form factor rather than a Pixhawk.
The decision as to what function is assigned to each pin is decided at compile time. To change a pin assignment, you would have to edit the hwdef file for the board, then re-compile the code and upload that to the board.
There were some conversations at the Ardupilot Developer’s conference about making pin assignments configurable in the parameters. So that may be a future feature, if a there’s a developer happy to take on that task.
Looking at the hwdef for the Kakute F7, it’s easiest to sacrifice the LED and Buzzer pins for 2x additional outputs. So 8 outputs total - 4x for PWM out and 4x for RPM measurement.
So definitely doable (at least in the software - it’s not something I’ve tested in hardware), but would mean a custom firmware build.
Again you’re too quick for me - I’d been googling to see if I was misinterpreting the term “AUX port” - and indeed I was. I was reading it as meaning a UART, i.e. two pins, rather than just meaning a single available pin.
So it doesn’t sound like handling the encoders is possible with a cheap F4/F7 flight controller without custom firmware Just out of interest why is it easier to sacrifice the LED and buzzer pins on the F7, can’t one just use the two pins of e.g. UART7?
Peter Hall introduced those lines to the Kakute F7 hwdef.dat file in commit 26a6ccc. I asked him about them - I hope he doesn’t mind me quoting him, he said:
The buzzer pin was very easy to add as it already uses a timer channel, so it was just a case of removing the buzzer functionality and giving the pwm. The led pin is not used by anything on Ardupilot currently so it seemed like the obvious choice.
I did play about will using a UART pin but getting that to work broke some of the other pwm pins. I’m sure there are other combinations that will work, its just a case of working out all the timers.
I would guess for reading encoder output this shouldn’t be an issue - as far as I understand, you wouldn’t need timers (which you’d need for PWM output), instead one needs to have two interrupt lines available (you only need two if you use the XORing setup that Pololu use on their Romi 32U4 control board).
Currently, I’m controlling a 2-wheel robot with a super simple web-based interface that I can access via my phone - I just move my finger around on a gray square to control the two separate motors. However, the experience isn’t great.
Just out of interest why is it easier to sacrifice the LED and buzzer pins on the F7, can’t one just use the two pins of e.g. UART7?